bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors]

In some common configurations, GNU Screen sets
TERM=screen.xterm-256color.

In this case, the desired behavior from the user's perspective would be
for Emacs to load the term/screen.el library to perform terminal
initialization specific to screen.

However, Emacs doesn't do this, because the logic that parses TERM to
determine which library to load only considers hyphens and underscores
to be valid separators - not periods. Emacs instead looks for a file
named "screen.xterm.el", and doesn't find one.

The TERM parsing logic is documented at
https://www.gnu.org/software/emacs/manual/html_node/elisp/Terminal_002dSpecific.html
and the code is in `tty-find-type` within lisp/faces.el

The simple fix would be to also consider periods to be a valid separator
within this logic.

Alternatively, Emacs could add a special case for when TERM starts with
the literal "screen.".

bug#45824:

[Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors]

A workaround is to add the following to your Emacs configuration:
(add-to-list 'term-file-aliases '("screen.xterm-256color" . "screen-256color"))

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[Lars Ingebrigtsen]

Alex Hutcheson <alexhutcheson@google.com> writes:

> In some common configurations, GNU Screen sets
> TERM=screen.xterm-256color.

[...]

> The TERM parsing logic is documented at
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Terminal_002dSpecific.html
> and the code is in `tty-find-type` within lisp/faces.el
>
> The simple fix would be to also consider periods to be a valid separator
> within this logic.

That does sound like a simple fix.  :-)  Are there any common TERM
values that have dots in them, though?  It does seem unlikely, in which
case this simple fix should probably work?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I just checked on two of my machines (running different distributions)
and didn't see anything that looked like it would cause problems. Most
were of the form "screen.something", and a couple terminfo files
included dots within version specifiers (e.g. st-0.8 and st-0.7).

The command I used to list all the relevant terminfo files was:
find /lib/terminfo /usr/share/terminfo -name '*.*' -type f -exec
basename '{}' ';' | sort -u

This worked on two Debian systems (one testing, one Buster), as well
as a macOS system.


On Tue, Jan 19, 2021 at 1:51 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Alex Hutcheson <alexhutcheson@google.com> writes:
>
> > In some common configurations, GNU Screen sets
> > TERM=screen.xterm-256color.
>
> [...]
>
> > The TERM parsing logic is documented at
> > https://www.gnu.org/software/emacs/manual/html_node/elisp/Terminal_002dSpecific.html
> > and the code is in `tty-find-type` within lisp/faces.el
> >
> > The simple fix would be to also consider periods to be a valid separator
> > within this logic.
>
> That does sound like a simple fix.  :-)  Are there any common TERM
> values that have dots in them, though?  It does seem unlikely, in which
> case this simple fix should probably work?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no



-- 
Alex Hutcheson
alexhutcheson@google.com

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[Lars Ingebrigtsen]

Alex Hutcheson <alexhutcheson@google.com> writes:

> I just checked on two of my machines (running different distributions)
> and didn't see anything that looked like it would cause problems. Most
> were of the form "screen.something", and a couple terminfo files
> included dots within version specifiers (e.g. st-0.8 and st-0.7).

Hm...  but wouldn't that possibly cause problems?  That is, if your TERM
is 

linux2.6.26

then if we split on dots, then Emacs will first look for
"text/linux2.6.26.el", and then "term/linux2.6.el"...  and those are
indeed different terminfos as found on my system:

linux2.6
linux2.6.26

> The command I used to list all the relevant terminfo files was:
> find /lib/terminfo /usr/share/terminfo -name '*.*' -type f -exec
> basename '{}' ';' | sort -u

Now, there is no term/linux2.6.el, so perhaps this is irrelevant...  And
perhaps if there was a term/linux2.6.el, perhaps loading that would be
OK in this case?  Anybody got an opinion here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

That behavior seems fine to me. In your example, Emacs would check
for the following, in-order:

   1. linux2.6.26.el
   2. linux2.6.el
   3. linux2.el

This seems like the right approach - try to match minor versions, but
if there is not a config for a specific minor version, then use the
config that matches the major version.

In this specific instance, it wouldn't actually find anything, because
there is no term/linux2.el file (just a term/linux.el file). This
could be resolved by also splitting between non-numeric characters and
numbers (so we would try linux.el as a step #4), but that's not
necessary to solve my specific problem.



On Tue, Jan 19, 2021 at 10:56 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Alex Hutcheson <alexhutcheson@google.com> writes:
>
> > I just checked on two of my machines (running different distributions)
> > and didn't see anything that looked like it would cause problems. Most
> > were of the form "screen.something", and a couple terminfo files
> > included dots within version specifiers (e.g. st-0.8 and st-0.7).
>
> Hm...  but wouldn't that possibly cause problems?  That is, if your TERM
> is
>
> linux2.6.26
>
> then if we split on dots, then Emacs will first look for
> "text/linux2.6.26.el", and then "term/linux2.6.el"...  and those are
> indeed different terminfos as found on my system:
>
> linux2.6
> linux2.6.26
>
> > The command I used to list all the relevant terminfo files was:
> > find /lib/terminfo /usr/share/terminfo -name '*.*' -type f -exec
> > basename '{}' ';' | sort -u
>
> Now, there is no term/linux2.6.el, so perhaps this is irrelevant...  And
> perhaps if there was a term/linux2.6.el, perhaps loading that would be
> OK in this case?  Anybody got an opinion here?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>


-- 
Alex Hutcheson
alexhutcheson@google.com

[-- Attachment #2: Type: text/html, Size: 2786 bytes --]

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 19 Jan 2021 16:56:27 +0100
> Cc: 45824@debbugs.gnu.org
> 
> Hm...  but wouldn't that possibly cause problems?  That is, if your TERM
> is 
> 
> linux2.6.26
> 
> then if we split on dots, then Emacs will first look for
> "text/linux2.6.26.el", and then "term/linux2.6.el"...  and those are
> indeed different terminfos as found on my system:
> 
> linux2.6
> linux2.6.26
> 
> > The command I used to list all the relevant terminfo files was:
> > find /lib/terminfo /usr/share/terminfo -name '*.*' -type f -exec
> > basename '{}' ';' | sort -u
> 
> Now, there is no term/linux2.6.el, so perhaps this is irrelevant...  And
> perhaps if there was a term/linux2.6.el, perhaps loading that would be
> OK in this case?  Anybody got an opinion here?

Maybe we should just introduce a way for users to specify the terminal
type that would override the value of TERM in the environment?  Some
defcustom that could be set in the init file?  That way, we don't need
to worry about inventing a new rule, with all the unintended
consequences that could bring us.

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]

A defcustom won't really work, since the correct value of TERM to use
might be different for different frames. For example, I might
sometimes launch Emacs directly within an xterm, and other times
launch it within a screen session.

Also, we already have the term-file-aliases variable, which enables a
workaround as mentioned up the thread.

However, I still think we should aim to work correctly with GNU Screen
without any additional configuration required by the user. The current
state is broken in that regard.

If we'd rather minimize complexity and just add a handful of aliases
to term-file-aliases, that's probably fine too.

On Tue, Jan 19, 2021 at 1:27 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Tue, 19 Jan 2021 16:56:27 +0100
> > Cc: 45824@debbugs.gnu.org
> >
> > Hm...  but wouldn't that possibly cause problems?  That is, if your TERM
> > is
> >
> > linux2.6.26
> >
> > then if we split on dots, then Emacs will first look for
> > "text/linux2.6.26.el", and then "term/linux2.6.el"...  and those are
> > indeed different terminfos as found on my system:
> >
> > linux2.6
> > linux2.6.26
> >
> > > The command I used to list all the relevant terminfo files was:
> > > find /lib/terminfo /usr/share/terminfo -name '*.*' -type f -exec
> > > basename '{}' ';' | sort -u
> >
> > Now, there is no term/linux2.6.el, so perhaps this is irrelevant...  And
> > perhaps if there was a term/linux2.6.el, perhaps loading that would be
> > OK in this case?  Anybody got an opinion here?
>
> Maybe we should just introduce a way for users to specify the terminal
> type that would override the value of TERM in the environment?  Some
> defcustom that could be set in the init file?  That way, we don't need
> to worry about inventing a new rule, with all the unintended
> consequences that could bring us.
>


-- 
Alex Hutcheson
alexhutcheson@google.com

[-- Attachment #2: Type: text/html, Size: 2750 bytes --]

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[Eli Zaretskii]

> From: Alex Hutcheson <alexhutcheson@google.com>
> Date: Tue, 19 Jan 2021 13:33:09 -0500
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 45824@debbugs.gnu.org
> 
> A defcustom won't really work, since the correct value of TERM to use
> might be different for different frames. For example, I might
> sometimes launch Emacs directly within an xterm, and other times
> launch it within a screen session.

A defcustom can be set (by your code) depending on the value of TERM,
of course, so this problem is easily solvable.  IOW, my proposal is to
delegate the responsibility for "parsing" the TERM value to the user
initializations, instead of asking Emacs to understand all the
possible quirks there.

> Also, we already have the term-file-aliases variable, which enables a
> workaround as mentioned up the thread.

Then perhaps nothing at all needs to be done.  (I thought that the
existing aliases were somehow inconvenient in this case.)

> However, I still think we should aim to work correctly with GNU Screen
> without any additional configuration required by the user. The current
> state is broken in that regard.

I just don't see where that would end, that's all.  Any
terminal emulator can call itself anything, and Emacs cannot possibly
know all the future names.

But that's me; if Lars thinks we should have built-in support for this
use case, I won't argue.  I was just responding to his request for
other opinions.

bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I just don't see where that would end, that's all.  Any
> terminal emulator can call itself anything, and Emacs cannot possibly
> know all the future names.
>
> But that's me; if Lars thinks we should have built-in support for this
> use case, I won't argue.  I was just responding to his request for
> other opinions.

Even though it's a slippery slope adding more DWIM here, I think the
proposed tweak makes sense.  It seems unlikely to break anything, and it
makes the common Emacs-under-screen case work better automatically.

So I think we should give it a go, but if it regresses anything, it
should be backed out again.  Pushed now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no