bugGNU Octave - Bugs: bug #56151, esc should clear command line,...


bug #56151: esc should clear command line, edits shouldn't disable history

Submitted by:  eflister <eflister>
Submitted on:  Wed 17 Apr 2019 04:14:33 PM UTC  
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Works For Me Assigned to:  None
Originator Name:  eflister Open/Closed:  Closed
Release:  5.1.0 Operating System:  Mac OS

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 10 Sep 2019 09:56:09 PM UTC, comment #24: 

There haven't been any suggestions here about how to improve the documentation on configuring command line editing, closing this bug. Can of course be reopened if changes are needed.

Mike Miller <mtmiller>
Project Administrator
Sun 11 Aug 2019 09:35:54 PM UTC, comment #23: 

Octave's user manual already includes a section about its command line interface, Section 2.4, Command Line Editing:


This section explains some of the default key bindings for cursor movement and manipulating text. This section also explains how to reload the readline configuration or how to load a non-default readline configuration file, and points the user to the Readline documentation for more information (https://tiswww.cwru.edu/php/chet/readline/rluserman.html).

Is there anything that Octave can do, including improving the documentation, to address this issue, or are we already doing enough?

Mike Miller <mtmiller>
Project Administrator
Wed 17 Apr 2019 11:55:53 PM UTC, comment #22: 

jwe: agreed -- since non-negligible subpopulations of octave users have differing expectations in this case, i don't think it matters much what the default behavior is.  what does matter is that there is a discoverable and easy way for users to understand what is happening when their expectations are violated and how to get their expected behavior (and learn about the advantages of alternatives).

eflister <eflister>
Wed 17 Apr 2019 11:52:29 PM UTC, comment #21: 

Closing the loop, if I add these two commands to my .inputrc file

"\e[A": previous-history
"\e[B": next-history

then up/down arrow fetch the previous/next history line without searching.

Anything more to be done for this report?

Rik <rik5>
Project Administrator
Wed 17 Apr 2019 11:32:56 PM UTC, comment #20: 

eflister: I generally agree, but I also think "unexpected" behavior is quite subjective.  As someone who has used bash, Emacs, vi, and similar programs for many years, I would find ESC clearing the line to be annoying and unexpected.

John W. Eaton <jwe>
Project Administrator
Wed 17 Apr 2019 11:12:11 PM UTC, comment #19: 

my matlab lic expired which is why i'm switching to octave, so i can't check the behavior -- my memory is that it worked like bash, but their doc corroborates what you're describing:

To recall previous lines in the Command Window, press the up- and down-arrow keys, ↑ and ↓. Press the arrow keys either at an empty command line or after you type the first few characters of a command. For example, to recall the command b = 2, type b, and then press the up-arrow key.
To clear a command from the Command Window without executing it, press the Escape (Esc) key.

the different esc semantics might be the root of my issue - if i up arrowed in matlab and saw it was stuck, my muscle memory is to hit esc so i can use the arrows again.

i think the fancy configurable readline stuff is cool, i just think it should be discoverable and have an easy/default way to mimic matlab/bash (including arrows and esc).  if a key command is having no effect, what about printing out a link that describes readline, how to customize it, see current bindings, etc.

unexpected behavior is bad behavior, especially if there's no way to discover what is going on.  how is someone supposed to understand why the esc key isn't working if they've never heard of readline?

eflister <eflister>
Wed 17 Apr 2019 10:41:12 PM UTC, comment #18: 

I think there may be some confusion about what is happening with the arrow keys.  I don't think it is that they are disabled, but when the cursor is not at the beginning of the line, readline is always trying to search for the previous (up arrow) or next (down arrow) line that matches what appears between the beginning of the line and the cursor.  That's exactly what is described in Octve's default system-wide inputrc file where we add the bindings for up and down arrow to be:

## history-search-backward:
##   Search backward through the history for the string of characters
##   between the start of the current line and the point.  This is a
##   non-incremental search.  Bound to "\e[A", the ANSI escape
##   sequence for the UP arrow.

"\e[A": history-search-backward

## history-search-forward:
##   Search forward through the history for the string of characters
##   between the start of the current line and the point.  This is a
##   non-incremental search.  Bound to "\e[B", the ANSI escape
##   sequence for the DOWN arrow.

"\e[B": history-search-forward

We added these bindings because another Matlab user com^H^H^Hexplained that Matlab performs searches with the arrow keys in this way.  Maybe that explanation was not complete, or the behavior of readline is not exactly what Matlab does.

When the cursor is not at the beginning of the line, it only appears to leave you stuck if there are no other matches in the history list.  So if you move up in the history and edit a line (leaving the cursor somewhere other than the beginning of the line) and then type the up or down arrow readline will search for lines that match the text between the beginning of the line and the cursor.  Moving the cursor to the beginning of the line should make the arrow keys move up or down by one entry in the history list instead of matching.

I don't think it's that readline's behavior here is necessarily bad, it's just not what you were expecting.

Maybe removing the bindings shown above will help you?  If not, then I think we need to understand precisely what Matlab does here in order for someone to attempt to make Octave behave the same way.

Rik: For Octave's GUI terminal window, I think you can use the "\e[A", "\e[B", "\e[C", and "\e[D" sequences for the arrow keys.  And these days, I think they should work for most any terminal, but I could be wrong.

The default bindings for previous-history and next-history should include the up and down arrow keys so if we change this globally, we should only have to remove the bindings from Octave's default inputrc file, not add anything new.

But if you want to change this for yourself without editing a system-wide file, adding

"\e[A": previous-history
"\e[B": next-history

to your ~/.inputrc file should do it.

Finally, you can use "Control-x k" at the Octave prompt to display all the bindings that are currently active.

John W. Eaton <jwe>
Project Administrator
Wed 17 Apr 2019 09:44:13 PM UTC, comment #17: 

@Torsten: I find the same behavior as you.  Up arrow is doing a search through history using the first part of the line.  It seems like it should be possible to use an inputrc to bind the up arrow to "prev-history" but I don't know the exact escape sequence for the up arrow (probably depends on terminal such as rxvt, xterm, aqua, etc.)

Rik <rik5>
Project Administrator
Wed 17 Apr 2019 09:40:47 PM UTC, comment #16: 

@eflister: I think e-mail is possibly not a nuanced enough medium for communication.  I simply stated the Octave project goals.  And a close reading of my messages, shows that I am looking for a solution as well.  The Ctrl+p/n is not ideal which is why I am trying to discover why it appears to work on Torsten's machine.  I don't use Matlab, but 'octave --help' reports

  --traditional           Set variables for closer MATLAB compatibility.

This isn't a strawman, just something that looks like it would help.  Your mileage may vary.

Rik <rik5>
Project Administrator
Wed 17 Apr 2019 09:01:26 PM UTC, comment #15: 

On the other side, when I am typing something and i then use the up arrow key, the previous command is shown and not commands that match what I have entered so far. I remember that his was working. Maybe that is the reason why the arrow keys are always browsing the history, because there is no search for a matching history entry.

Torsten Lilge <ttl>
Project Member
Wed 17 Apr 2019 08:50:28 PM UTC, comment #14: 

Your /etc/inputrc is the same as mine.  I moved my ~/.inputrc out of the way but I still find that after editing a history line the arrow keys don't work.  There might be something else going on like Readline library versions.  Seems like this is supposed to work.

Rik <rik5>
Project Administrator
Wed 17 Apr 2019 08:36:06 PM UTC, comment #13: 

@rik5: did you read the part where i wrote "doesn't have to be exactly like matlab's" or any of the constructive suggestions i offered to make octave-gui a better experience, not just for the large number of users who arrive with a matlab background, but also for anyone who isn't familiar with readline or doesn't think they should have to switch from arrows to ctrl-p/n just because they edited something?

note that bash works just as i am requesting, so we can dispense with the strawman that this is about matlab-myopia.

regarding --traditional, the only doc i see is under '--braindead' here:
and none of it has anything to do with the present discussion or the gui.  another strawman.

note that under "is it really a bug?" at https://www.gnu.org/software/octave/bugs.html
it says "If you are an experienced user of programs like Octave, your suggestions for improvement are welcome in any case."

eflister <eflister>
Wed 17 Apr 2019 08:30:11 PM UTC, comment #12: 

@Rik: Yes, the arrow keys work for me after editing. However, I have never customized my ~/.inputrc (it is empty). Please find attached /etc/inputrc. Are there other locations for readline configuration files?

(file #46789)

Torsten Lilge <ttl>
Project Member
Wed 17 Apr 2019 08:03:09 PM UTC, comment #11: 

Octave is its own project.  We try to make the interpreter as compatible as possible so that code developed with either platform can run.  But there isn't any stated goal or desire to replicate the GUI.

@eflister: You can launch octave with the --traditional option which makes a few things more Matlab compatible.  That might help with transitioning.

@Torsten: Do the arrow keys work for you after you edited a command?  I had to use Ctrl+p, Ctrl+n at that point.  If it does, maybe you could share some of your .inputrc file.

Rik <rik5>
Project Administrator
Wed 17 Apr 2019 07:46:18 PM UTC, comment #10: 

Soory, my post was misleading. Browsing the history (on Linux) works exactly like you expect ti should. I can edit a recent command, use arrow keys to browse up and down and get the edited command when I come to this entry in the history again. When I understand your post correctly, this does not work for you.

Torsten Lilge <ttl>
Project Member
Wed 17 Apr 2019 07:26:15 PM UTC, comment #9: 

@ttl: are you on osx/5.1.0?  sounds like we agree it should work that way anywhere.  the gui doesn't have to be exactly like matlab's, but it should be discoverable how to get matlab behavior especially for muscle-memory actions.  and it doesn't make sense that arrow keys shouldn't work after editing a history item.

eflister <eflister>
Wed 17 Apr 2019 07:08:46 PM UTC, comment #8: 

Reply to comment #3 and comment #6: Browsing the history exactly works for me as you describe. I can edit a recent command, use arrow keys to browse up and down and get the edited command when I come to this entry in the history again.

The general question is if "Matlab compatibility" really should include a user interface that completely behaves like Matlab.

Torsten Lilge <ttl>
Project Member
Wed 17 Apr 2019 06:41:46 PM UTC, comment #7: 

i see octave.org/doc/v5.1.0/Command-Line-Editing.html#Command-Line-Editing but that is not discoverable.  perhaps print that link to the command window if you can tell user is stuck -- like hitting up/down arrow or esc when those won't do anything.

and for the readline-ignorant such as myself, default to settings that work like matlab (locally) if .inputrc etc haven't been customized.

eflister <eflister>
Wed 17 Apr 2019 06:28:40 PM UTC, comment #6: 

sounds like at least some doc describing that readline is being used, what it is, and where to learn to use it, is required.  i wasn't aware of it.  it sounds valuable and i agree with not changing user settings, though that is different than overriding them in a local context.

perhaps a preference setting that defaults to readline settings corresponding to default matlab behavior, just locally, but notices if there are custom settings in .inputrc and offers to use them (or v/v)?

in any case i don't think the out-of-the-box behavior is good -- when i fire up octave and use muscle memory from matlab, nothing works.  i hit 'esc' and the line freezes (i guess it is interpreting esc as a character added to the line), and i can't move through history anymore with up/down arrow.  there's no reason up/down arrow should work before edits, but require switching to ctrl-p/n after edits.

eflister <eflister>
Wed 17 Apr 2019 06:08:59 PM UTC, comment #5: 

Readline is a complicated, but configurable tool.

Assuming default Emacs keybindings are in place you might want to look at the cheatsheet here (http://readline.kablamo.org/emacs.html).

I can use the sequence Ctrl+g to abort entering, but leave the edited command history in place, and then use Ctrl+p for previous history or Ctrl+n for next history.  That seems to cover the use case you had in mind.

I happen to use VI-mode and, in this instance, it seems to provide better behavior.  If I use 'ESC' to exit from editing mode in to command mode then I can use the cursor up / cursor down keys instead of Ctrl+p / Ctrl+n to navigate through history.

This seems likely to be an upstream issue.  Octave uses Readline which the user is allowed to configure through their .inputrc in any way they like, but we shouldn't change the user's settings unilaterally.

Rik <rik5>
Project Administrator
Wed 17 Apr 2019 05:30:16 PM UTC, comment #4: 

> usually using esc to clear the line

meant to include: or down-arrowing past the end of the history to get a clear line

eflister <eflister>
Wed 17 Apr 2019 05:28:54 PM UTC, comment #3: 

the usage pattern is you up-arrow to a history item you want to edit, you start editing, but then either A) realize you want to abandon this command and do something else (usually using esc to clear the line), or B) temporarily refer to another history item (earlier or later) -- up/down arrow to it, and then up/down arrow back to the item you were editing without having lost the edits.

eflister <eflister>
Wed 17 Apr 2019 05:06:57 PM UTC, comment #2: 

As Torsten pointed out, 'ESC' can be bound to whatever you like.  I use VI-mode with Readline so, for example, 'ESC' is used to switch between editing mode and command mode and it should never be bound to deleting the line.

Could you clarify the second part of the report, "edits shouldn't disable history".  I don't understand what the desired behavior is.  Normally, one uses the up-arrow to go backwards in history, edit a command, and then type return to execute it.  It sounds like you have a different usage pattern.

Rik <rik5>
Project Administrator
Wed 17 Apr 2019 04:47:38 PM UTC, comment #1: 

This is related to readline and is therefore not limited to the GUI. Actually, Ctrl-U kills the current line to the beginning. You can also bind "ESC" to "kill-whole-line" by adding


to your ~/.inputrc file. However, this is not recommanded since readline uses ESC as some sort of modifier key. For details, please refer to, e.g., https://unix.stackexchange.com/questions/30987/windows-shell-escape-key-delete-whole-line-equivalent-in-bash

Torsten Lilge <ttl>
Project Member
Wed 17 Apr 2019 04:14:33 PM UTC, original submission:  

important when editing a line initiated by up arrowing through command history.

also maintain position in up/down arrowing through history even after clearing w/esc.

also allow continuing to use up/down arrow through history even after editing one or more of the items (match matlab command window behavior), maintaining the edits only until this line is executed.

eflister <eflister>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #46789:  inputrc added by ttl (2KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by eflister (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-09-10 mtmiller CategoryNone => Documentation
        StatusNone => Works For Me
        Open/ClosedOpen => Closed
    2019-04-17 ttl Attached File- => Added inputrc, #46789
    2019-04-17 rik5 CategoryGUI => None

    Back to the top

    Powered by Savane 3.5