Does telescope support any kind of buffer or cache in memory or disk ?

[m040601]

Hi first of all thank you for your work in this amazing tool. I love it. Very well thought. It's obviously the work of someone experienced with other power Unix tools.

Especially the care taken with the bindings, not forcing or imposing anything, catering to a large population of command line power users. And paying attention to conventions.

I'm planning to do a full detailed review of telescope and compare it to other gemini text/cli clients I've been testing in the last months.

I have one question that's been puzzling me since I've been checking your latest releases. I'm not a programmer so, understand if I'm missing something "obvious"

I'm also a power w3m user. When I load a couple of sites, and/or go back and forth betwenn many pages in the same site, w3m keeps them "cached" in memory or (if very big) as a temporrary tmp/gziped html file. Once the needed html is downloaded, the tcp connections / sockets to the server are closed. No need to keep them open. I love it.

If I dont close w3m, I could even turn off the Internet, and go back and forth, and read those pages offline. All my loaded tabs and buffers, load instatntly. When I quit w3m, of course all that is removed.

The important thing is that, once I've loaded the page, no more network request are made to the server. , if I go back and forth. It feels snappy , unlike the modern "bloated web", always and constatnly keeping a tcp connection open with the server. Same thing with other gemini clients, for example amfora.

But I've noticed in telescope, that if I visit a gemini site, browse some of its pages, and then want to go back and forth in the history, each time, there's a new network request to the server. So it's talking to the server again, to get the same page I got some minutes ago.

I know this, because I use "ss" (could be netstat, iftop, bandwhich, wireshark, etc) to monitor the sockets connections the program is making in realtime.

Is this normal ? Or is the cache/buffer mechanism not yet implemented ? If so is there any plans to do it ?

Thanks in advance and keep up the good work.

PS: I'm not talking about "cache", in the sense of communication between the client (telescope) and the server (gemini host). I know perfectly well that the gemini protocol does not support this.

[omar-polo]

Hello :)

Yep, you're right, at the moment telescope doesn't do caching. Moving forward and backward in the history always requires making a request.

I acknowledge that it isn't ideal, and it's frankly the thing that annoys me the most too. (this and the fact that it doesn't preserve the scrolling when going back to a previous page.)

The cache subsystem is one of the three major changes I'm planning thought (with the other two being the subscriptions and gempubs -- ``major'' in the sense that they'll require some internal refactoring) but I have no ETA for that.

[m040601]

So that explains it. Thank you for your reply.

it doesn't preserve the scrolling

Ahh ... that. I also intended to ask about that, but didnt want to sound to pushy or demanding.

It is anoying. As well as not "preserving" the last focused, highlighted, url, when back/forth scrolling. Amfora also doesnt do it.

30 year old w3m does all this marvelously, so you always "land" exactly, where you intended. So one gets spoiled.

If you want the opinion of a power command line user, regarding priorites, I think you should put these 2 at the top of your priorities.

• Cache
• Preserve scrolling/ focused link.

Top notch color management and bindings is of course essential for power command line users experience.

There are already many, and there will be much much more small little tools that you can combine the UNIX way, to manage your atom/rss feeds, gemini gemlogs, gemini gempubs and even gemini tinylogs.

So I would leave

• gempubs
• subscriptions

For later.

[m040601]

By the way.

Contrib Any form of contribution is appreciated, not only patches or bug reports. The contrib directory is for external things such as sample configuration files, themes, scripts and things like that.

Because you have your other mirrored repo page, https://git.omarpolo.com/telescope and home page /blog, https://telescope.omarpolo.com/

I was not even 100% sure, if you watch or listen to github. If I should open an issue on github, or send you an email. If you monitor pull request on github, or if you expect them to be submitted as paches by email, to https://git.omarpolo.com/telescope.

Only much later did I notice on your github profile:

...I use github for collaboration or mirroring.

Please add a line, to the README, explicitly specifying github.com as the place for patch submissions and "bug reports".

I might also have some comments/ideas or feedback I would like to give. Dont' want to "pollute" your issues list with that.

Consider opening up the "Discussions" page of github as venue for other things than "bug reports". It gives you a place to receive feedback from the community of non code submitting users. It's free, works wonderfully, see how qutebrowser makes a great use of it, https://github.com/qutebrowser/qutebrowser/discussions

[omar-polo]

it doesn't preserve the scrolling

Ahh ... that. I also intended to ask about that, but didnt want to sound to pushy or demanding.

No problem! Feel free open issues for what you think is missing. Grantend, it could be I'm already planning some or have a different opinion, but it's always nice to hear someone else and more often than not, some unknown (to me) details emerge when talking with others, and the project will benefit from that.

I know there are still lots of things that need to be implemented, I tagged the v0.5 after all and not a 1.0 for a reason.

It is anoying. As well as not "preserving" the last focused, highlighted, url, when back/forth scrolling. Amfora also doesnt do it.

30 year old w3m does all this marvelously, so you always "land" exactly, where you intended. So one gets spoiled.

Indeed!

I'm aiming to a similar level of care to the details. It takes time, but I like to think I could eventually, bit by bit, reach it.

Contrib Any form of contribution is appreciated, not only patches or bug reports. The contrib directory is for external things such as sample configuration files, themes, scripts and things like that.

Because you have your other synchronized repo page, https://git.omarpolo.com/telescope and home page /blog, https://telescope.omarpolo.com/

I was not even sure If I should open an issue on git hub, or send you an email.

I don't really mind. It's fine for me both via email, here on github or even on irc!

Please add a line, to the README, pointing to github issues as the place to submit "bug reports".

You're absolutely right, will do.

I might also have some comments/ideas or feedback I would like to give. Dont' want to "pollute" your issues list with that.

I don't mind if you open more issues like this. It may seems like "polluting", but in my opinion it's not the case. First of all it's informative for other users, and second we can use this issue to track the progress on the cache implementation ;)

Also consider opening up the "Discussions" page of github as venue for other things than "bug reports". It's free, works wonderfully, see how qutebrowser makes a great use of it, https://github.com/qutebrowser/qutebrowser/discussions

I don't really have any experience with this, and in part I fear that will cause some duplication with the issue tracker, but why don't try it?

[omar-polo]

Just a quick update. I've pushed the branch feature/cache which is a first draft of the cache implementation. It's not functional yet (there's only code to add a page to the cache), and is going to take a while still to reach a point where it'd be possible to merge it, but it's a start :)

[omar-polo]

So, five months later, here we are :)

The latest -main branch has a simple, in-memory, cache store for gemini and gopher pages. The cache is only used when navigating backward and forward in the history or when re-opening a closed tab. This should make its behavior not surprising, especially in the context of dynamically generated pages.

I kinda wanted to apologies for waiting this long before implementing a cache mechanism. The reason is that I tend to overthink a lot and I'm almost never happy; I struggled for a while about how I want to handle it, but I think I've finally found a way that I like.

At the moment the cache store is a simple in-memory store, a dictionary url => page to make it simple. This works fine and, while I still have to tweak it a bit (in particular as of now pages are never removed from the cache!) it's fine. The longer plan is to save the pages on the disk, so the cache will be persistent across sessions and it'll also allows to add all kind of interesting stuff (like searching content on the cached pages, or a fully-offline navigation, I think it'd be nice something like that.)

Over the next couple of days I'll probably tweak the remaining bits and complete this first cache implementation. I'm not sure when I want to tag the next version (there are still lots of stuff I'd like to add! :P) but it'll be present by then.

Cheers!

[m040601]

Great news ! Thanks for your effort, and specially, thanks for keeping this issue open, so that updates can be documented here. You can be sure that your users (at least me) keep following with attemtion Telescope development. Even without talking too much for weeks or months.

I kinda wanted to apologies for waiting this long before implementing a cache mechanism.

Please dont apology. I just want to make sure that my posts/questions are never interpreted as a "demand" or "expectations" to this project.

Actually, I'm the one who kind of feels embarassed. Since my first post, I wanted to continue giving you feedback on the user experience. Giving you immediate detailed feedback for each realeased version. So that you can immediate associate the changes you made with some user experience. Got lazy, didnt find time.

The most important one is that I noticed a significant boost and responsiveness in Telescope. I cant explain exactly, but the UI just felt more "snappy". Things "loaded" faster.

This was on the updated versions you released after Aug21. I cant remember if it was in September/October/November.

Cant say if it's the user interface alone more responsive, or even the network requests quicker. I testetd in my different terminals (linux console, fbterm, st, urxvt, under and without tmux. I even tryed to used "ss", "ifmon" and other network monitoring tools to check connection, ping times etc.

But at some point, it just felt more "snappy" going back and forth, loading pages, etc .

All this even Even without the caching mechanism.

I dont understand the changes you made in the code. And this is of course a subjective impression. But I just want to make sure you get this feedback.

I noticed this on the different platform builds I use, both ARM (raspberry) and x86 on Archlinux. It is also possible that it may be caused by some "compiling optimization" the telescope packagers for Archlinux have made. I dont know.

I tend to overthink a lot and I'm almost never happy; I struggled for a while about how I want to handle it,

Please continue to be and behave like this :-) . There is absolutely no rush for Telescope. This isnt Firefox.There is no shortage of gemini clients to choose from. And there is no "competition" to win among them. Just take whatever time it takes to use this as an opportunity to build the best damned gemini cli client. Just like the Lagrange guy does with his GUI client. A lot of thinkering and long term thinking.

The latest -main branch has a ....

We have 3 versions on Arch to choose from. I usually use the stable version released for Arch:

aur/telescope-git 0.6.1.r11.gd9b3105-1 (+1 0.03)
    w3m-like browser for Gemini.
aur/telescope-bin 0.5.2-1 (+1 0.03)
    w3m-like browser for Gemini.
aur/telescope 0.6.1-1 (+2 0.07) (Installed)
    w3m-like browser for Gemini.

But will try to find some time to test the git one, compared them and come back with some feedback.

PS: Note to self

• Remember to test and measure telescope cpu/mem consumption (btop, sysstat etc)

[omar-polo]

Please dont apology. I just want to make sure that my posts/questions are never interpreted as a "demand" or "expectations" to this project.

Yeah, I've phrased it without thinking too much. On almost every source file there's a "NO WARRANTY" in capslock, and I'm doing this as a hobby, so I don't have to apologize. I was just feeling a bit embarassed because it's wasn't an hard thing to do, and yet I've waited a lot before actually sitting down and write the damn thing. Now that there's a cache, I can't imagine using an older version without :D (especially for gopher' result pages!)

Actually, I'm the one who kind of feels embarassed.

Please don't. It's best when one does something because it's fun, not because he/she feels obligated to. I'm happy to receive feedbacks tho :P

The most important one is that I noticed a significant boost and responsiveness in Telescope. I cant explain exactly, but the UI just felt more "snappy". Things "loaded" faster.

This was on the updated versions you released after Aug21. I cant remember if it was in September/October/November.

I'm not sure, after the "big netcode refactoring" I haven't really touched the network code (gemini, gopher and finger are simple protocols after all!) Even if it's probably due to something else, I'm always happy when things are faster :D

P.S.: I've just released 0.7 -- which should hit AUR soon, andrea is really fast to update the packages!

[m040601]

The 0.8 release is named after "Le Scarpe Volanti" a song by Verdena.

New Features

• save and restore scroll position

Already tested this !!! Works wonderfully, great work, big improvement !!!

With this scrolling issue and with the simpe cache now working,

So, five months later, here we are :)

The latest -main branch has a simple, in-memory, cache store for gemini and gopher pages. The cache is only used when navigating backward and forward in the history or when re-opening a closed tab. ...ages.

I personally think one can close this github issue.

[omar-polo]

i agree, thanks again for the suggestions :)