Subject: Re: bug#62265: Underline does not work in Terminal Emacs
From: Eli Zaretskii <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Sun, 16 Apr 2023 09:22:53 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> Cc: [email-masked], [email-masked]
> Date: Sun, 19 Mar 2023 14:24:19 +0200
> From: Eli Zaretskii <[email-masked]>
> 
> > From: Mohsin Kaleem <[email-masked]>
> > Cc: [email-masked], [email-masked]
> > Date: Sun, 19 Mar 2023 11:51:45 +0000
> > 
> > Eli Zaretskii <[email-masked]> writes:
> > 
> > > However, what about the non-TERMINFO branch?  Do termcap databases
> > > support this capability and tigetstr?  I wonder whether we should do
> > > one of the following:
> > >
> > >   . support "smxx" only when TERMINFO is defined
> > >   . support "smxx" regardless of whether TERMINFO is defined
> > 
> > The latter wouldn't be possible for those using terminfo because of the
> > issue I described before. I'm okay with the former approach but I
> > imagine the author of the original TTY strikethrough patch was building
> > Emacs without terminfo and they described the patch as working for them
> > so I'd have to conclude termcap does support this (in a non-compliant
> > ncurses way). Switching to the former approach might break their
> > workflow since if they build without terminfo they'd lose strikethrough
> > altogether. I'm happy to test whether this would be the case but not
> > sure how to. The difference between termcap and terminfo seem kinda
> > arbitrary to me and I can't find any documentation describing the exact
> > difference (except this sort of 2 letter restriction in termcap
> > extensions).
> 
> If your hypothesis is correct, I'm fine with leaving the non-TERMINFO
> branch using tgetstr.  But is it indeed correct?
> 
> Let's ask the author of that strikethrough patch.  Mike, can you tell
> whether you tested the patch on a system with or without terminfo?
> And what, if anything, can you tell about using tgetstr for
> capabilities whose names are more than 2 characters -- is that
> supported with the curses library you were using at the time?

No further comments, so I've installed a fix for this along the lines
we discussed, and I'm closing this bug.