--- Begin Message ---
|
Subject: |
Underline does not work in Terminal Emacs |
|
Date: |
Sat, 18 Mar 2023 17:40:51 +0000 |
Hi,
Underline support for tty frames was added to Emacs back in the Emacs
28.0.90 release. It hasn't worked for me since. Today I tried
investigating why. I tracked it down ncurses and discovered the tgetstr
function to retrieve the escape sequence for underline support doesn't
fetch the value configured in the terminfo database for my Terminal
(st). I can reproduce this function failing to fetch the entry in a
minimal sample program (code attached).
reproduce-smxx-failure.c
Description: Sample program that fails to get smxx
The cause for this seems to be in ncurses directly. In the definition of
tgetstr in lib_termcap.c there's a check for ValidExt for any
non-standard terminfo entries. This macro fails when fetching an entry
that is longer than 2 characters, meaning tgetstr for "smxx" fails and I
get no underlines. I've managed to fix this by using tigetstr in-place
of tgetstr (this variant is also used for querying the setf24 and setb24
termcaps already in "term.c" so I suspect this is a known issue). I'm
not sure what the termcap library does but I'm guessing it doesn't have
this restriction.
Please fix this by switching to tigetstr instead of tgetstr for this
record when building with terminfo. I've got a sample patch for this
attached.
diff --git a/src/term.c b/src/term.c
index d881dee39fe..a2d1743bdad 100644
--- a/src/term.c
+++ b/src/term.c
@@ -4163,7 +4163,11 @@ use the Bourne shell command 'TERM=...; export TERM'
(C-shell:\n\
tty->TS_enter_alt_charset_mode = tgetstr ("as", address);
tty->TS_exit_alt_charset_mode = tgetstr ("ae", address);
tty->TS_exit_attribute_mode = tgetstr ("me", address);
+#ifdef TERMINFO
+ tty->TS_enter_strike_through_mode = tigetstr ("smxx");
+#else
tty->TS_enter_strike_through_mode = tgetstr ("smxx", address);
+#end
MultiUp (tty) = tgetstr ("UP", address);
MultiDown (tty) = tgetstr ("DO", address);
--
Mohsin Kaleem
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#62265: Underline does not work in Terminal Emacs |
|
Date: |
Sun, 16 Apr 2023 09:22:53 +0300 |
> Cc: jporterbugs@gmail.com, 62265@debbugs.gnu.org
> Date: Sun, 19 Mar 2023 14:24:19 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Mohsin Kaleem <mohkale@kisara.moe>
> > Cc: jporterbugs@gmail.com, 62265@debbugs.gnu.org
> > Date: Sun, 19 Mar 2023 11:51:45 +0000
> >
> > Eli Zaretskii <eliz@gnu.org> 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.
--- End Message ---