'Ctrl+X, Ctrl+E' in terminal no longer brings up the default editor

Support Software & Applications
1

Normally, whenever one is typing up a compound command at the command prompt of a terminal — such as a… :point_down:

for var in ... ; do ... ; done

… iteration — and one presses the keyboard shortcut sequence Ctrl+XCtrl+E, the default editor should be loaded with that compound command in it, the various sections of the command neatly ordered as if they are the multiple lines of a shell script.

One can then edit this “script”, and without saving it, exit the editor by way of the usual keyboard shortcut or menu entry, and then the “script” will be neatly displayed as a properly formatted single-line command again at the prompt.

This works regardless of whether one is typing the command at the prompt of a terminal emulator in a graphical environment, or whether one is logged in at a character-mode virtual console — i.e. a tty.

The editor that will be invoked is the one defined via the ${EDITOR} variable, and if this variable has not been set, then the shell will attempt to invoke one of the usual suspects, be it emacs, vi or nano.

Now, I have all three of the editors above installed, and I do have the ${EDITOR} variable set to /usr/bin/nano.

[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >  for program in nano emacs vi ; do type $program ; done
nano is /usr/bin/nano
emacs is /usr/bin/emacs
vi is /usr/bin/vi

[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >  echo $EDITOR
/usr/bin/nano

[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >

However — and I’m not sure on when this changed because I don’t use this functionality all that much, given that I’m fairly good at getting my compound commands right without this aid, but — apparently the Ctrl+XCtrl+E sequence no longer works.

From the looks of things, Ctrl+X is still recognized as the terminal escape character, but the Ctrl+E character — which, when used all on its own without the preceding Ctrl+X, correctly moves the cursor to the end of the line — now appears to send a carriage return to the terminal instead, resulting in whatever you were typing to get passed onto the shell as a command.

Yet, the terminal options suggest that everything should still work as before… :point_down:

[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >  bind -P | grep edit
edit-and-execute-command can be found on "\C-x\C-e".
emacs-editing-mode is not bound to any keys
vi-edit-and-execute-command is not bound to any keys
vi-editing-mode is not bound to any keys

[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >

Is this a bug, or has anything changed upstream to the bash or terminal configuration in recent times? :thinking:

1 Like
2

Hmm… A new discovery… Apparently it does work if you use it in a terminal window, but not quite as expected. :astonished:

Instead of invoking ${EDITOR}, it invokes ${VISUAL}, which on my system is set to /usr/bin/kate. And I had no idea about it, because it simply opened up a new and anonymous tab in an already open kate session on another virtual desktop without that Plasma switched to that virtual desktop.

So upon returning to my kate session, I noticed a whole bunch of tabs labeled “Untitled”. :man_facepalming:

Furthermore, if ${VISUAL} is set, then it will also try to invoke the editor specified as such when you’re invoking the command editing function in a tty, and of course, this will then fail because you cannot start a GUI-only application in a strictly CLI-only environment.

So, the solution is to not have the ${VISUAL} variable set, and to simply stick with whatever you’ve set as ${EDITOR}.

Lesson learned, although I do consider this behavior to be a bug introduced by upstream. The edit shortcuts in a terminal should invoke the editor applicable to the type of terminal. If it’s a terminal window in a GUI, then it should invoke ${VISUAL}, and if it’s a tty, then it should invoke ${EDITOR}. :man_shrugging:

3 Likes
3

By the way, I have something in my .profile that’s related and may or may not help. For you it would be kate and nano instead of gnome-text-editor and micro:

export EDITOR="$(if [[ -n $DISPLAY ]]; then echo 'gnome-text-editor'; else echo 'micro'; fi)"
export SUDO_EDITOR="$(if [[ -n $DISPLAY ]]; then echo 'gnome-text-editor'; else echo 'micro'; fi)"
export VISUAL="$(if [[ -n $DISPLAY ]]; then echo 'gnome-text-editor'; else echo 'micro'; fi)"
1 Like
4

That would indeed be a good workaround, provided that one sets those variables by way of one’s ~/.profile or ~/.bash_profile. But in my case, those variables are defined in /etc/environment, which does not allow any scripting. :face_with_diagonal_mouth:

5

Instead of editing /etc/environment, customizations should be created as a shell script in /etc/profile.d/; i.e., maybe something like default-editor.sh.

❯ grep Manjaro /etc/environment
# Manjaro defaults are now in /etc/profile.d/
2 Likes
6

Ah, I’m guessing that must have been a .pacnew that I forgot to merge at the time. :thinking:

I’ll grant you the solution, then. :wink:

7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.