1

I recently switched from rxvt-unicode to st. This means I went from $TERM=rxvt-unicode-256color to $TERM=st-256color.

I'm happy with the switch and want to continue to use st. However, I quickly noticed that emacs was not rendering my colors appropriately. After some googling, I found this question. Following mndrix's advice, I added

(add-to-list 'term-file-aliases
    '("st-256color" . "xterm-256color"))

to my .emacs. This solved the problem. However, my start time is now really slow.

Now I'm wondering if there is another solution. On my system, the directory /usr/share/emacs/26.2/lisp/term has some el.gz and elc files corresponding to different terminals. For instance, this directory has xterm.el.gz and xterm.elc in it. I'm guessing that the fundamental issue is that this directory does not have st.el.gz and st.elc. Is it possible to add this support? If so, how might one go about this configuration?

7
  • "However, my start time is now really slow." seems like a very unexpected consequence of setting that term alias. How much slower are we talking?
    – phils
    Commented Apr 25, 2019 at 22:03
  • @phils Like a hard five count. I don't know how to rigorously convey this information which is why I put effort into phrasing this question in a way so that I hoped people wouldn't interpret it as an XY question. I gave motivation for my question but the question stands alone apart from the motivation. Commented Apr 25, 2019 at 22:36
  • Can you confirm that env TERM=xterm-256color emacs is just as slow? What about with emacs -Q instead of emacs ?
    – phils
    Commented Apr 26, 2019 at 0:27
  • "I gave motivation for my question but the question stands alone apart from the motivation." -- If you're not looking for solutions to the slowness (and it's not obvious that a st.el library should behave any differently), it's probably best to remove that context from the question as, despite your efforts, it did seem rather like an XY question. It's probably also more a feature-request to submit with M-x report-emacs-bug.
    – phils
    Commented Apr 26, 2019 at 0:31
  • 1
    debbugs.gnu.org/cgi/bugreport.cgi?bug=33182
    – phils
    Commented Apr 26, 2019 at 0:34

1 Answer 1

1

This is Emacs bug 33182.

The 5-second delay is confirmed in that bug report.

No st.el library is provided in that bug report at this point; but that would be the sensible place to follow up.

You could start by looking at the existing term libraries and README file:

I would suggest looking into those, and see whether you can come up with something which works, and then following up the bug report.

Eli's comment in that bug also points us to these:

xterm-extra-capabilities is a variable defined in `xterm.el'.
Its value is `check'

Documentation:
Whether Xterm supports some additional, more modern, features.
If nil, just assume that it does not.
If `check', try to check if it does.
If a list, assume that the listed features are supported, without checking.

The relevant features are:
  modifyOtherKeys  -- if supported, more key bindings work (e.g., "\C-,")
  reportBackground -- if supported, Xterm reports its background color
  getSelection     -- if supported, Xterm yanks text from the X selection
  setSelection     -- if supported, Xterm saves killed text to the X selection

and

xterm-query-timeout is a variable defined in `xterm.el'.
Its value is 2

Documentation:
Seconds to wait for an answer from the terminal.
Can be nil to mean "no timeout".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.