From Newsgroup: comp.infosystems.gopher

Fellow gophers,

I recently discovered that UMN Gopher client has some rather odd
behaviour when deciding if it should truncate menu titles.

The RFC suggests they should be kept below 70 characters. I have always addhered to this and used 69 but I received a report, after adding the
date to the end of some lines, that my titles were now being truncated
when viewed on an 80 character display.

This didn't add up, quite literally, so I did a little investigation of
the source code. It seems 13 characters are reserved for the left info
margin. The margin can be less depending on the index number of the menu
item, this is a problem in itself. But following its calculation logic,
you have COLS - 13 resulting in the maxwidth. 80 - 13 = 67, so even
though my lines are addhering to the RFC, the client thinks they are too
long.

The irony is that truncated lines have the last two characters replaced
with '..'. Which actually overwrites the last two digits of the date. If
the accounting was correct, then it would remain untouched...

I wrote a phlog post about it here with more detail: gopher://gopher.icu/0/phlog/Computing/Display-lines-and-UMN-gopher.md

In the meantime I shortened my menu titles to 67 characters to stop the
phantom truncation. But as per the phlog post, I'm wondering what to do
about it...

Any helpful suggestions or guidance greatfully received.
--

IanJ

gopher://gopher.icu
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

I think the developer is assmuming that if its over 67 characters, its over
69 characters. I'd keep it at 69 characters, and point to the developers ignorance as cause of truncation.

On 2025-02-25, IanJ <SPAMian_jones_01@yahoo.co.uk.invalid> wrote:

Fellow gophers,

I recently discovered that UMN Gopher client has some rather odd
behaviour when deciding if it should truncate menu titles.

The RFC suggests they should be kept below 70 characters. I have always addhered to this and used 69 but I received a report, after adding the
date to the end of some lines, that my titles were now being truncated
when viewed on an 80 character display.

This didn't add up, quite literally, so I did a little investigation of
the source code. It seems 13 characters are reserved for the left info margin. The margin can be less depending on the index number of the menu item, this is a problem in itself. But following its calculation logic,
you have COLS - 13 resulting in the maxwidth. 80 - 13 = 67, so even
though my lines are addhering to the RFC, the client thinks they are too long.

The irony is that truncated lines have the last two characters replaced
with '..'. Which actually overwrites the last two digits of the date. If
the accounting was correct, then it would remain untouched...

I wrote a phlog post about it here with more detail: gopher://gopher.icu/0/phlog/Computing/Display-lines-and-UMN-gopher.md

In the meantime I shortened my menu titles to 67 characters to stop the phantom truncation. But as per the phlog post, I'm wondering what to do
about it...

Any helpful suggestions or guidance greatfully received.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On Tue, 25 Feb 2025 18:57:55 -0000 (UTC), IanJ wrote:

Fellow gophers,

I recently discovered that UMN Gopher client has some rather odd
behaviour when deciding if it should truncate menu titles.

The RFC suggests they should be kept below 70 characters. I have always addhered to this and used 69 but I received a report, after adding the
date to the end of some lines, that my titles were now being truncated
when viewed on an 80 character display.

This didn't add up, quite literally, so I did a little investigation of
the source code. It seems 13 characters are reserved for the left info margin. The margin can be less depending on the index number of the menu item, this is a problem in itself. But following its calculation logic,
you have COLS - 13 resulting in the maxwidth. 80 - 13 = 67, so even
though my lines are addhering to the RFC, the client thinks they are too long.

The irony is that truncated lines have the last two characters replaced
with '..'. Which actually overwrites the last two digits of the date. If
the accounting was correct, then it would remain untouched...

I wrote a phlog post about it here with more detail: gopher://gopher.icu/0/phlog/Computing/Display-lines-and-UMN-gopher.md

In the meantime I shortened my menu titles to 67 characters to stop the phantom truncation. But as per the phlog post, I'm wondering what to do
about it...

Any helpful suggestions or guidance greatfully received.

It would be worth submitting a patch to alter the client's display so that
it only takes 11 characters on the left hand side and makes the correct calculation.

As to whether you should reduce your menu titles to 67 characters is an interesting question and really points to how Gopher use has changed.
When I used it in the 90s it was mainly used to download files and
although I don't remember seeing this truncation I don't think it would
really have been that much of an issue as I don't expect many lines were formatted in that way. The formatting makes sense on your site and looks
nice - it is curious how the 'i' itemtype isn't truncated in the same way
by the client.

Perhaps submit a patch and see if it gets merged in. Then wait until the
major distributions have updated their packages and revert to 69
characters.

Best wishes


Lorry

---
XCCP: A Shell Extension for CP/M https://techtinkering.com/articles/xccp-a-shell-extension-for-cpm/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On Fri, 28 Feb 2025 09:03:25 -0000 (UTC), Lawrence Woodman wrote:

On Tue, 25 Feb 2025 18:57:55 -0000 (UTC), IanJ wrote:

Fellow gophers,

I recently discovered that UMN Gopher client has some rather odd
behaviour when deciding if it should truncate menu titles.

The RFC suggests they should be kept below 70 characters. I have always
addhered to this and used 69 but I received a report, after adding the
date to the end of some lines, that my titles were now being truncated
when viewed on an 80 character display.

This didn't add up, quite literally, so I did a little investigation of
the source code. It seems 13 characters are reserved for the left info
margin. The margin can be less depending on the index number of the
menu item, this is a problem in itself. But following its calculation
logic, you have COLS - 13 resulting in the maxwidth. 80 - 13 = 67, so
even though my lines are addhering to the RFC, the client thinks they
are too long.

The irony is that truncated lines have the last two characters replaced
with '..'. Which actually overwrites the last two digits of the date.
If the accounting was correct, then it would remain untouched...

I wrote a phlog post about it here with more detail:
gopher://gopher.icu/0/phlog/Computing/Display-lines-and-UMN-gopher.md

In the meantime I shortened my menu titles to 67 characters to stop the
phantom truncation. But as per the phlog post, I'm wondering what to do
about it...

Any helpful suggestions or guidance greatfully received.

It would be worth submitting a patch to alter the client's display so
that it only takes 11 characters on the left hand side and makes the
correct calculation.

[SNIP]

I've been thinking about this a little more and rereading the RFC and it
does say 'Clients may truncate to a length convenient to them'. Although
this client's calculation as to when to truncate and show '..' is a little
off, the decision to truncate at less than 69 characters makes some sense
given how it displays menus, especially when you consider that types such
as <HTML> are indicated after the title. It might be that we have to
accept that titles can be truncated and plan our sites accordingly.

Lorry

---
XCCP: A Shell Extension for CP/M https://techtinkering.com/articles/xccp-a-shell-extension-for-cpm/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On 2025-02-28, Lawrence Woodman <lorrywoodman@gmail.com> wrote:

On Fri, 28 Feb 2025 09:03:25 -0000 (UTC), Lawrence Woodman wrote:

On Tue, 25 Feb 2025 18:57:55 -0000 (UTC), IanJ wrote:

Fellow gophers,

I recently discovered that UMN Gopher client has some rather odd
behaviour when deciding if it should truncate menu titles.

The RFC suggests they should be kept below 70 characters. I have always
addhered to this and used 69 but I received a report, after adding the
date to the end of some lines, that my titles were now being truncated
when viewed on an 80 character display.

This didn't add up, quite literally, so I did a little investigation of
the source code. It seems 13 characters are reserved for the left info
margin. The margin can be less depending on the index number of the
menu item, this is a problem in itself. But following its calculation
logic, you have COLS - 13 resulting in the maxwidth. 80 - 13 = 67, so
even though my lines are addhering to the RFC, the client thinks they
are too long.

The irony is that truncated lines have the last two characters replaced
with '..'. Which actually overwrites the last two digits of the date.
If the accounting was correct, then it would remain untouched...

I wrote a phlog post about it here with more detail:
gopher://gopher.icu/0/phlog/Computing/Display-lines-and-UMN-gopher.md

In the meantime I shortened my menu titles to 67 characters to stop the
phantom truncation. But as per the phlog post, I'm wondering what to do
about it...

Any helpful suggestions or guidance greatfully received.

It would be worth submitting a patch to alter the client's display so
that it only takes 11 characters on the left hand side and makes the
correct calculation.

[SNIP]

I've been thinking about this a little more and rereading the RFC and it
does say 'Clients may truncate to a length convenient to them'. Although this client's calculation as to when to truncate and show '..' is a little off, the decision to truncate at less than 69 characters makes some sense given how it displays menus, especially when you consider that types such
as <HTML> are indicated after the title. It might be that we have to
accept that titles can be truncated and plan our sites accordingly.

Lorry

---
XCCP: A Shell Extension for CP/M https://techtinkering.com/articles/xccp-a-shell-extension-for-cpm/

Good point. In that case, you can choose any length you like under 70 characters knowing that any client that truncates below 70 characters
is just exercising its freedom to truncate to a length thats
convenient to them.

And if your lines are truncated by a client, despite being under 70
characters, don't submit a patch; just send the link to your
gopherhole and let the developer see how it looks in their client.
The odds are good that they'll wonder why its truncated, and learn
that it doesn't need to be truncated.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Lawrence Woodman <lorrywoodman@gmail.com> wrote:

It would be worth submitting a patch to alter the client's display so that
it only takes 11 characters on the left hand side and makes the correct calculation.

As to whether you should reduce your menu titles to 67 characters is an interesting question and really points to how Gopher use has changed.
When I used it in the 90s it was mainly used to download files and
although I don't remember seeing this truncation I don't think it would really have been that much of an issue as I don't expect many lines were formatted in that way. The formatting makes sense on your site and looks nice - it is curious how the 'i' itemtype isn't truncated in the same way
by the client.

Perhaps submit a patch and see if it gets merged in. Then wait until the major distributions have updated their packages and revert to 69
characters.

Best wishes

Lorry

I'm not much of a C programmer and have very little experience using
ncurses, but I wrote a patch today. It works for me, but YMMV: gopher://gopher.icu/0/files/0001-Removed-selected-item-indicator-from-left-margin-rep.patch

It can be applied to the latest source tree from here: https://github.com/jgoerzen/gopher.git

I also wrote a brief phlog post about it for anyone who wants more info: gopher://gopher.icu/0/phlog/Computing/UMN-gopher-revisited.md

Here is a screenshot of it with the changes: gopher://gopher.icu/I/files/gopher-menu2.png

If people feel that this is an improvement, then I may submit the patch.
Any fixes or feedback gratefully received.
--

IanJ

gopher://gopher.icu
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On 3/1/25 1:30 PM, IanJ wrote:

Lawrence Woodman <lorrywoodman@gmail.com> wrote:

It would be worth submitting a patch to alter the client's display so that >> it only takes 11 characters on the left hand side and makes the correct
calculation.

As to whether you should reduce your menu titles to 67 characters is an
interesting question and really points to how Gopher use has changed.
When I used it in the 90s it was mainly used to download files and
although I don't remember seeing this truncation I don't think it would
really have been that much of an issue as I don't expect many lines were
formatted in that way. The formatting makes sense on your site and looks
nice - it is curious how the 'i' itemtype isn't truncated in the same way
by the client.

Perhaps submit a patch and see if it gets merged in. Then wait until the
major distributions have updated their packages and revert to 69
characters.

Best wishes


Lorry

I'm not much of a C programmer and have very little experience using
ncurses, but I wrote a patch today. It works for me, but YMMV: gopher://gopher.icu/0/files/0001-Removed-selected-item-indicator-from-left-margin-rep.patch

It can be applied to the latest source tree from here: https://github.com/jgoerzen/gopher.git

I also wrote a brief phlog post about it for anyone who wants more info: gopher://gopher.icu/0/phlog/Computing/UMN-gopher-revisited.md

Here is a screenshot of it with the changes: gopher://gopher.icu/I/files/gopher-menu2.png

If people feel that this is an improvement, then I may submit the patch.
Any fixes or feedback gratefully received.

Hey, very nice!

If you're still up for more UMN Gopher client hacking you might
try getting it to scroll multi-page menus that DON'T have actual
links, i.e. phlogs that are menus consisting of mostly Type "i".
It seems to be the only client I've tested that fails to scroll
these types of menus.

Cheers,
A.I.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Arti F. Idiot <addr@is.invalid> wrote:

If you're still up for more UMN Gopher client hacking you might
try getting it to scroll multi-page menus that DON'T have actual
links, i.e. phlogs that are menus consisting of mostly Type "i".
It seems to be the only client I've tested that fails to scroll
these types of menus.

Is that not a warning from Gopher developers past that Type 'i'
shouldn't be used like that? I like having long text and navigation
separated in the traditional Gopher way, it makes keyboard
navigation much more practical than on the Web.

Also I hate always needing up-to-date Web browsers to browse the
Web, so I'd prefer Gopher content to stick with the formatting
which works in old Gopher clients anyway, ideally back to the
1990s. UMN Gopher is a good role model for the old ways.

I imagine it bearing a sign:

You are entering UMN Gopherspace
No pseudo-webpages, UTF-8, or long lines past this point!
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Arti F. Idiot <addr@is.invalid> wrote:

Hey, very nice!

If you're still up for more UMN Gopher client hacking you might
try getting it to scroll multi-page menus that DON'T have actual
links, i.e. phlogs that are menus consisting of mostly Type "i".
It seems to be the only client I've tested that fails to scroll
these types of menus.

Cheers,
A.I.

Would you believe that back in time it actually used to work this way?
It was a deliberate change by the developers at the time to prevent it.
I remember reading a comment in the code somewhere...

Multi page menus do actually work fine, it's where there are entire
pages with nothing but "i" lines. This only happens where people
attempt to put their content into a menu to make pseudo web pages.

There are better ways to achieve in-text linking: gopher://gopher.icu:70/0/phlog/Computing/Smart-terminal-not-client.md

I, like Nerd Kev, personally don't agree with people turning menus into
pseudo web pages. Not only because it makes chunks of them largely
unreadable in this client, it also prevents you using the email, print
and download features.

The protocol was designed to share files, not menus IMHO...

Best regards,

IanJ
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Arti F. Idiot <addr@is.invalid> wrote:

Hey, very nice!

If you're still up for more UMN Gopher client hacking you might
try getting it to scroll multi-page menus that DON'T have actual
links, i.e. phlogs that are menus consisting of mostly Type "i".
It seems to be the only client I've tested that fails to scroll
these types of menus.

Would you believe that back in time it actually used to work this way?
It was a deliberate change by the developers at the time to prevent it.
I remember reading a comment in the code somewhere...

Multi page menus do actually work fine, it's where there are entire
pages with nothing but "i" lines. This only happens where people
attempt to put their content into a menu to make pseudo web pages.

There are better ways to achieve in-text linking: >gopher://gopher.icu:70/0/phlog/Computing/Smart-terminal-not-client.md

I, like Nerd Kev, personally don't agree with people turning menus into >pseudo web pages. Not only because it makes chunks of them largely
unreadable in this client, it also prevents you using the email, print
and download features.

The protocol was designed to share files, not menus IMHO...

Fair enough, though I think relegating Gopher to mere file sharing will
not do much for fanning interest in anyone not raised on green screens
and analog modems. In any event, A.I. appears to be right that the UMN
client is the only one displaying this scrolling issue. Poking through
some old gopher mlist posts relating to gophernicus I came these:

"... The offical Gopher+ client from UMN is so broken I had to detect
it in the Gophernicus server code to make it work - dedicated code
for just *one* client." [1]

A matter of opinion.

jj
--
[1] https://lists.debian.org/gopher-project/2017/02/msg00023.html
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

jeojet@not.valid wrote:

Fair enough, though I think relegating Gopher to mere file sharing will
not do much for fanning interest in anyone not raised on green screens
and analog modems. In any event, A.I. appears to be right that the UMN client is the only one displaying this scrolling issue. Poking through
some old gopher mlist posts relating to gophernicus I came these:

"... The offical Gopher+ client from UMN is so broken I had to detect
it in the Gophernicus server code to make it work - dedicated code
for just *one* client." [1]

A matter of opinion.

jj
--
[1] https://lists.debian.org/gopher-project/2017/02/msg00023.html

As I have already explained. What you describe as a 'scrolling issue'
was a deliberate design choice by those who wrote the RFC and reference
client. Gopher 2.1 Client patchlevel 0, " * Skip over type 'i'
items."[2]

[2] https://raw.githubusercontent.com/jgoerzen/gopher/master/doc/client.changes

The RFC position on non-core item types, which includes 'i', is that
the client implementation "may simply ignore the item":

3.5 Building clients

If a client does not understand what a say, type 'B' item (not a
core item) is, then it may simply ignore the item in the directory
listing; the user never even has to see it. Alternatively, the
item could be displayed as an unknown type.

To put your content within a non-core type is therefore not advised.

No opinion, just facts.

IanJ
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On 2025-03-01, IanJ <SPAMian_jones_01@yahoo.co.uk.invalid> wrote:

Lawrence Woodman <lorrywoodman@gmail.com> wrote:

It would be worth submitting a patch to alter the client's display so that >> it only takes 11 characters on the left hand side and makes the correct
calculation.

As to whether you should reduce your menu titles to 67 characters is an
interesting question and really points to how Gopher use has changed.
When I used it in the 90s it was mainly used to download files and
although I don't remember seeing this truncation I don't think it would
really have been that much of an issue as I don't expect many lines were
formatted in that way. The formatting makes sense on your site and looks
nice - it is curious how the 'i' itemtype isn't truncated in the same way
by the client.

Perhaps submit a patch and see if it gets merged in. Then wait until the
major distributions have updated their packages and revert to 69
characters.

Best wishes


Lorry

I'm not much of a C programmer and have very little experience using
ncurses, but I wrote a patch today. It works for me, but YMMV: gopher://gopher.icu/0/files/0001-Removed-selected-item-indicator-from-left-margin-rep.patch

It can be applied to the latest source tree from here: https://github.com/jgoerzen/gopher.git

I also wrote a brief phlog post about it for anyone who wants more info: gopher://gopher.icu/0/phlog/Computing/UMN-gopher-revisited.md

Here is a screenshot of it with the changes: gopher://gopher.icu/I/files/gopher-menu2.png

If people feel that this is an improvement, then I may submit the patch.
Any fixes or feedback gratefully received.

Dots only appearing at the end of line when it doesn't fit feels natural, so I'd say its an improvement.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On 3/2/25 11:58 AM, IanJ wrote:

I, like Nerd Kev, personally don't agree with people turning menus into pseudo web pages. Not only because it makes chunks of them largely
unreadable in this client, it also prevents you using the email, print
and download features.

The protocol was designed to share files, not menus IMHO...

Let's check "i" item type, when people turn menus into pseudo web pages.

echo | nc gopher.icu 70 |grep ^i | wc -l
22

echo | nc morena.rip 70 |grep ^i | wc -l
0

Dear IanJ, 22 from 58 lines of your main menu are just non recognized,
custom "i" item types. Shame on you ;/

Also that right aligned date is nonsense.
--
morena
gopher://morena.rip
nex://morena.rip
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

morena <morena@morena.rip> wrote:

On 3/2/25 11:58 AM, IanJ wrote:

I, like Nerd Kev, personally don't agree with people turning menus into
pseudo web pages. Not only because it makes chunks of them largely
unreadable in this client, it also prevents you using the email, print
and download features.

The protocol was designed to share files, not menus IMHO...

Let's check "i" item type, when people turn menus into pseudo web pages.

echo | nc gopher.icu 70 |grep ^i | wc -l
22

echo | nc morena.rip 70 |grep ^i | wc -l
0

Dear IanJ, 22 from 58 lines of your main menu are just non recognized, custom "i" item types. Shame on you ;/

An ASCII art banner, spacing and section headings. All of which can be
safely ignored.

Menus are not used for content in place of files, that is the point.

Also that right aligned date is nonsense.

Your opinion.

---

The subject of the thread is 'UMN Gopher - menu title length.'. Please
let us focus on whether the changes I have made in my patch are an
improvement to the client, worthy of submitting for inclusion in the
main branch.
--

IanJ

gopher://gopher.icu
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On 3/3/25 10:00 PM, IanJ wrote:

An ASCII art banner, spacing and section headings. All of which can be
safely ignored.

I don't see anything about ASCII art banner, spacing or section headings
in the RFC 1436.

Menus are not used for content in place of files, that is the point.

22 from 58 lines. Yes, that's not menu item, but content file.

Also that right aligned date is nonsense.

Your opinion.

Most people write opinion of somebody's else sadly, luckily I write my own.

The subject of the thread is 'UMN Gopher - menu title length.'. Please
let us focus on whether the changes I have made in my patch are an improvement to the client, worthy of submitting for inclusion in the
main branch.

UMN Gopher client is broken and full of junk. It has issue with most
Gopher servers available this time.
If you would like that it is RFC compliant, then you should probably
make your own server that way. Then you may touch tools other people use
too. You can get always inspired by my RFC 1436 compliant Gopher server.

Also if you mentioned "i" item type issue, you should allow others to
write about it too.

Sometime is good to let things go. Let them die in peace. UMN Gopher
want's to die, Gopher protocol too.
--
morena
gopher://morena.rip
nex://morena.rip
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

morena <morena@morena.rip> wrote:

Also if you mentioned "i" item type issue, you should allow others to
write about it too.

If you check the thread you would note that it was Arti F. Idiot who
raised the perceived issue with UMN Gopher and type 'i' by asking:

If you're still up for more UMN Gopher client hacking you might
try getting it to scroll multi-page menus that DON'T have actual
links, i.e. phlogs that are menus consisting of mostly Type "i".

I explained why I wouldn't be doing that.

IanJ
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Stone Fox <stone@unix.dog> wrote:

On 2025-03-01, IanJ <SPAMian_jones_01@yahoo.co.uk.invalid> wrote:

Lawrence Woodman <lorrywoodman@gmail.com> wrote:

It would be worth submitting a patch to alter the client's display so that >>> it only takes 11 characters on the left hand side and makes the correct
calculation.

As to whether you should reduce your menu titles to 67 characters is an
interesting question and really points to how Gopher use has changed.
When I used it in the 90s it was mainly used to download files and
although I don't remember seeing this truncation I don't think it would
really have been that much of an issue as I don't expect many lines were >>> formatted in that way. The formatting makes sense on your site and looks >>> nice - it is curious how the 'i' itemtype isn't truncated in the same way >>> by the client.

Perhaps submit a patch and see if it gets merged in. Then wait until the >>> major distributions have updated their packages and revert to 69
characters.

Best wishes


Lorry

I'm not much of a C programmer and have very little experience using
ncurses, but I wrote a patch today. It works for me, but YMMV:
gopher://gopher.icu/0/files/0001-Removed-selected-item-indicator-from-left-margin-rep.patch

It can be applied to the latest source tree from here:
https://github.com/jgoerzen/gopher.git

I also wrote a brief phlog post about it for anyone who wants more info:
gopher://gopher.icu/0/phlog/Computing/UMN-gopher-revisited.md

Here is a screenshot of it with the changes:
gopher://gopher.icu/I/files/gopher-menu2.png

If people feel that this is an improvement, then I may submit the patch.
Any fixes or feedback gratefully received.

Dots only appearing at the end of line when it doesn't fit feels natural, so I'd say its an improvement.

This morning I updated the patch with some more extensive changes to
correct the truncation of title lines in the menu.

It can be downloaded from the same link above.

I also posted a followup explaining the changes: gopher://gopher.icu/0/phlog/Computing/UMN-gopher-revisited-pt2.md

Best regards,
--

IanJ

gopher://gopher.icu
--- Synchronet 3.21d-Linux NewsLink 1.2