I've been thinking lately about how I'd like to browse the web with
an interface similar to Gopher, mainly for the sake of fast
navigation using just the arrow keys, which I've always found too
clunky in text-based web browsers but works well in Gopher thanks
to the separation of navigational pages and text content.
A more complete description of my thinking is here: gopher://aussies.space/0/%7efreet/ideas/2022-01-19Web2Gopher.txt
On 2022-01-19, The Free Thinker <freet@aussies.space> wrote:
I've been thinking lately about how I'd like to browse the web with
an interface similar to Gopher, mainly for the sake of fast
navigation using just the arrow keys, which I've always found too
clunky in text-based web browsers but works well in Gopher thanks
to the separation of navigational pages and text content.
A more complete description of my thinking is here:
gopher://aussies.space/0/%7efreet/ideas/2022-01-19Web2Gopher.txt
Part of the linked gopher post mentions how navigating via links in lynx breaks page flow and can cause the reader to jump around the page,
missing content. I had similar problems with lynx, and this is the
primary reason I don't use it. I tried links for a little while before settling on elinks, which made it more clear than links did that there
are commands for scrolling the document independently of the position of links therein. Or maybe the version of links I tried then just didn't
have those commands? Regardless, links and elinks both address this lynx shortcoming.
They won't address any of the other problems you have (though elinks has
some rudimentary CSS support), but for text-based content (the kind of
thing that could've been served via gopher or gemini), these browsers
work well. elinks even has fully rebindable keys, so you can make it
work like vi/vim/less/rogue/every other Unix program. Its development
has stalled, sadly, but it does still build and run on modern machines. Beyond that, it can be configured to include support for a wide range of protocols.
On 2022-01-19, The Free Thinker <freet@aussies.space> wrote:
I've been thinking lately about how I'd like to browse the web with
an interface similar to Gopher, mainly for the sake of fast
navigation using just the arrow keys, which I've always found too
clunky in text-based web browsers but works well in Gopher thanks
to the separation of navigational pages and text content.
A more complete description of my thinking is here:
gopher://aussies.space/0/%7efreet/ideas/2022-01-19Web2Gopher.txt
They won't address any of the other problems you have (though elinks has
some rudimentary CSS support), but for text-based content (the kind of
thing that could've been served via gopher or gemini), these browsers
work well. elinks even has fully rebindable keys, so you can make it
work like vi/vim/less/rogue/every other Unix program. Its development
has stalled, sadly, but it does still build and run on modern machines. Beyond that, it can be configured to include support for a wide range of protocols.
My aim is really to find a convenient text-based way to browse
'mainstream' websites, like news websites, Ebay, etc. The sites
that ELinks really doesn't handle well.
On 1/20/22 21:06, The Free Thinker wrote:
My aim is really to find a convenient text-based way to browse
'mainstream' websites, like news websites, Ebay, etc. The sites
that ELinks really doesn't handle well.
RSS 2.0 and ATOM feeds have been my go-to for years. Thunderbird, Akgregator, Liferea, and QuiteRSS are some readers that come to mind.
I like Thunderbird because I can read all the feeds, usenet, and email
in one place with it.
If a website does not offer fulltext RSS feeds of new articles I don't bother with the site.
Social media sites (including YouTube) once had great RSS feed options
as standard fare.
RSS is not dead <rss@not.dead> wrote:
On 1/20/22 21:06, The Free Thinker wrote:
My aim is really to find a convenient text-based way to browse
'mainstream' websites, like news websites, Ebay, etc. The sites
that ELinks really doesn't handle well.
RSS 2.0 and ATOM feeds have been my go-to for years. Thunderbird,
Akgregator, Liferea, and QuiteRSS are some readers that come to mind.
Perhaps I should make better use of RSS. I have a few feeds set to
be forwarded to email for software update notifications and other
'event' type information.
I like Thunderbird because I can read all the feeds, usenet, and email
in one place with it.
If a website does not offer fulltext RSS feeds of new articles I don't
bother with the site.
Social media sites (including YouTube) once had great RSS feed options
as standard fare.
Actually YouTube still have feeds, at least if you craft the URLs
for them yourself. eg. https://www.youtube.com/feeds/videos.xml?user=FILMAUSTRALIA
I haven't found an RSS reader that likes them (mainly because I
focused on very lightweight readers and gave up pretty easily).
I refuse to use the new Javascript-based YouTube site because it
only works in Firefox/Chrome, so I've been using a script to
process the output from youtube-dl: gopher://aussies.space:70/9/%7efreet/scripts/ytb
To keep up with particular channels RSS feeds would be much quicker
than that is (youtube-dl is slow). However the problem with that is
the same as with using RSS for news, Ebay, etc.. I often read an
article, or view a video description, and see a link to another
article or video and want to view that. With RSS I then have to at
that point abandon my cosy text-based, keyboard navigation
friendly, RSS reader and switch to whatever web browser is needed
to view the link.
With my ytb script, I can not only see the latest updates to a
channel (and there are only four infrequently updated ones that I occasionally check when I have some internet data spare anyway),
but when I find a link to a YouTube video on a web page, or in the description of one of those videos, I can also fetch the
description, preview image, duration, and download link with that.
With news sites it's the same thing, even if they offer RSS and
include the full article there (unlikely), you have to switch
programs to view a link or search for older content.
Ebay does have email notifications for searches, which I use a lot
(though they do keep emailing me about the same damn
unwanted/over-priced items each time they get relisted for years
and years and years). But you only see a title and price, so again
it's just a gateway to their website, and no help for searching.
Sorry if that's a bit of a rant, but in short RSS doesn't quite
work for me, besides for those 'event' type notifications where
they only have importance to me at the current moment. I probably
could use it more, but it's not a route to fully solving the issues
that I have with navigating the web compared to Gopher.
Still I agree that it's very nice to have, and RSS feeds would no
doubt come in handy for developing parts of a Web2Gopher type
viewer system for many sites.
I'm a bit late but if I understand correctly you want an easy way to navigate the traditional web
but in a keyboard oriented manner, is that right?
Take a look at Nyxt, https://github.com/atlas-engineer/nyxt
It might have a bit of a learning courve and I don't use it myself because they're not building for macOS
which is my current OS.
But as a past Emacs user, I did gave it a try before and it looks great.
Jack <jacksonbenete@gmail.com> wrote:
I'm a bit late but if I understand correctly you want an easy way to navigate
the traditional web
but in a keyboard oriented manner, is that right?
Sort of. That problem alone is of course solved by various
text-mode browsers, but I specifically want to solve it by
presenting web pages like gopher menu and text items. Or as I said
before, maintaining "separation of navigational pages and text
content".
For example, the way _I_ would implement Gopherpedia would be that
instead of just wiping out all the internal links in a Wikipedia
page, they'd be listed in a gophermap, below a link to the page
text, links to categories the page is in, related pages, and the
list of extenal links from the bottom of the page.
In the text itself, where the inline links are used they would be
replaced with reference numbers like "[27]". This number would be
the line in the gophermap where that link is located. In the
original UMN Gopher client, you can enter the line number of a link
when viewing a gophermap, press enter, and it follows it. So,
following a link in the text is as easy as keys: "[Left Arrow],
[2], [7], [Enter]".
At the same time the key navigational links are quickly accessed by
returning to the gophermap with [Left Arrow], without having to
find them in relation to the page text and layout (the latter
usually being terribly broken with CSS-based sites like Wikipedia
when viewed in a text web browser).
So it's not simply navigating with the keyboard, it's navigating
content presented in a Gopher-like way with the keyboard.
Take a look at Nyxt, https://github.com/atlas-engineer/nyxt
It might have a bit of a learning courve and I don't use it myself because >> they're not building for macOS
which is my current OS.
But as a past Emacs user, I did gave it a try before and it looks great.
That looks like it might assign links to keys for similar
functionality to my reference tags idea, which is interesting. But
I really want the "separation of navigational pages and text
content" bit as well, because that is actually the thing I can
experience by browsing Gopher sites already, which I find makes keyboard-driven Gopher browsers usable where web browsers aren't
(for most websites).
Anyway what I was really curious about was whether other people,
with those here presumably including a lot of Gopher users, had
also observed that keyboard navigation was made easier by the
rigid structure imposed by that protocol. Gemini is kind-of
evidence that a large group think that's the worst part of
Gopher (besides lack of encryption) and so introduced inline
links, making Gemini similarly frustrating to the web for keyboard
navigation (though without CSS mess). But is there another silent
group who find Gopher's structure is actually better, like I do?
Given that nobody here seems to understand what I'm talking about
with keyboard navigation working better with Gopher than the web,
that means it probably is just me. That answers my question though,
and means if I do get around to implementing my own Web2Gopher
browser, proxy, or whatever, I won't put too much work into making
it easily extendable by others (expecting that most sites will need
specific treatment), because if nobody else really finds it useful
then that would just be a waste of time. Plus it kind-of hurts when
I put work into something like that (also documentation) expecting
a different reception.
Whether I actually ever find the time and energy to do it is
another matter anyway.
On 8 Apr 2022 at 22:38:48 GMT-3, "The Free Thinker" <The Free Thinker> wrote: Has been a while since last time I've browsed on gopher, and maybe thats why I'm not following very much.
Last time I was using some Emacs client, I don't even remember the name.
Jack <jacksonbenete@gmail.com> writes:
On 8 Apr 2022 at 22:38:48 GMT-3, "The Free Thinker" <The Free Thinker> wrote:
Has been a while since last time I've browsed on gopher, and maybe thats why >> I'm not following very much.
Last time I was using some Emacs client, I don't even remember the name.
https://web.archive.org/web/20220330113657if_/http://yeti.freeshell.org/tmp/20220124-165407__emacs__browsing_6_protocols.png
Elpher - finger, gopher, gemini
Eww - web
Dired - local files, (ftp and more via Tramp)
Telnet - guess what...
What about the telnet connection? Are those some old documents you're visiting or there are still new content being published (maybe even exclusively) via telnet for whatever reason?
https://ssd.jpl.nasa.gov/horizons/tutorial.html
telnet horizons.jpl.nasa.gov 6775
| Sysop: | deepend |
|---|---|
| Location: | Calgary, Alberta |
| Users: | 255 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 160:00:50 |
| Calls: | 1,725 |
| Calls today: | 5 |
| Files: | 4,107 |
| D/L today: |
12 files (9,998K bytes) |
| Messages: | 393,013 |
