12 ms·
> Bash now checks $INSIDE_EMACS as well as $EMACS > when deciding whether or > not bash is being run in a GNU Emacs shell window. hahaha Next release it
by i4k 10y ago
> Bash now checks $INSIDE_EMACS as well as $EMACS
> when deciding whether or
> not bash is being run in a GNU Emacs shell window.
hahaha
Next release it will check the variables $INSIDE_ACME, $INSIDE_SUBLIME and $INSIDE_NOTEPADPLUSPLUS
- jxy 10y agoI don't think this is a good design decision either. Next release would probably check $INSIDE_SCREEN, $INSIDE_BROWSER, $INSIDE_PHONE, $INSIDE_VR, $INSIDE_PAPER, $INSIDE_HUMAN
- rgtk 10y agoBash and Emacs are under the same umbrella. This software is part of GNU system and systems tend to incorporate its part to make it more maintainable. However, more generic solution shall be used, like checking out parent process of current session to determine environment in which bash is running.
- i4k 10y agoThe problem is not only with bash, but with entire gnu ecosystem. Bash disable something ONLY when the parent process is EMACS is totally nonsense. Bash should check for some behavior, instead of some technology... because I'm sure other editors can behave similarly when executing bash inside some buffer. Doing software this way makes bash and emacs working well, but hard to make other softwares interact with both of them... Sublime, acme, micro, and so on can benefit of a better solution. In the same way, other shell should work fine inside emacs (M-x ansi-term). But software design is not expected here (see downvotes)