unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
@ 2021-01-12 19:04 Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-01-12 19:22 ` bug#45824: Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-01-19  6:51 ` bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color Lars Ingebrigtsen
  0 siblings, 2 replies; 10+ messages in thread
From: Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-01-12 19:04 UTC (permalink / raw)
  To: 45824

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.".





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824:
  2021-01-12 19:04 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
@ 2021-01-12 19:22 ` Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-01-19  6:51 ` bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color Lars Ingebrigtsen
  1 sibling, 0 replies; 10+ messages in thread
From: Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-01-12 19:22 UTC (permalink / raw)
  To: 45824

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
  2021-01-12 19:04 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
  2021-01-12 19:22 ` bug#45824: Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-01-19  6:51 ` Lars Ingebrigtsen
  2021-01-19 15:34   ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-19  6:51 UTC (permalink / raw)
  To: Alex Hutcheson; +Cc: 45824

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
  2021-01-19  6:51 ` bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color Lars Ingebrigtsen
@ 2021-01-19 15:34   ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-01-19 15:56     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-01-19 15:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 45824

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
  2021-01-19 15:34   ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-01-19 15:56     ` Lars Ingebrigtsen
  2021-01-19 16:52       ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-01-19 18:27       ` Eli Zaretskii
  0 siblings, 2 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-19 15:56 UTC (permalink / raw)
  To: Alex Hutcheson; +Cc: 45824

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
  2021-01-19 15:56     ` Lars Ingebrigtsen
@ 2021-01-19 16:52       ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-01-19 18:27       ` Eli Zaretskii
  1 sibling, 0 replies; 10+ messages in thread
From: alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-01-19 16:52 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 45824

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
  2021-01-19 15:56     ` Lars Ingebrigtsen
  2021-01-19 16:52       ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-01-19 18:27       ` Eli Zaretskii
  2021-01-19 18:33         ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2021-01-19 18:27 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 45824, alexhutcheson

> 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.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
  2021-01-19 18:27       ` Eli Zaretskii
@ 2021-01-19 18:33         ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-01-19 19:20           ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-01-19 18:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 45824

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
  2021-01-19 18:33         ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-01-19 19:20           ` Eli Zaretskii
  2021-01-20 16:26             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2021-01-19 19:20 UTC (permalink / raw)
  To: Alex Hutcheson; +Cc: larsi, 45824

> 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.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color
  2021-01-19 19:20           ` Eli Zaretskii
@ 2021-01-20 16:26             ` Lars Ingebrigtsen
  0 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-20 16:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 45824, Alex Hutcheson

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-01-20 16:26 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-12 19:04 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
2021-01-12 19:22 ` bug#45824: Alex Hutcheson via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-19  6:51 ` bug#45824: 27.1; term/screen.el not loaded when TERM=screen.xterm-256color Lars Ingebrigtsen
2021-01-19 15:34   ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-19 15:56     ` Lars Ingebrigtsen
2021-01-19 16:52       ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-19 18:27       ` Eli Zaretskii
2021-01-19 18:33         ` alexhutcheson--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-19 19:20           ` Eli Zaretskii
2021-01-20 16:26             ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).