bugGNU nano - Bugs: bug #61316, at a secondary prompt, history can...


You are not allowed to post comments on this tracker with your current authentication level.

bug #61316: at a secondary prompt, history can start in the middle

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Sat 09 Oct 2021 08:34:48 AM UTC  
Severity:  2 - Minor Status:  Fixed
Assigned to:  Benno Schulenberg <bens> Open/Closed:  Open

Sun 10 Oct 2021 08:08:02 AM UTC, comment #3: 

The discrepancy can be fixed, in most cases.  At the start of acquire_an_answer() the current history pointer is remembered AND the string that it points to too.  Then, if at the end of the function the answer is equal to the remembered string, then the user chose that item from history, or retyped it, but in either case this string is now at the bottom of the history list (not the real bottom, which always contains an empty string, but the one right before it), so the history pointer should be reset.  If, however, the answer differs from the remembered string, then the history item that the remembered pointer points at still exists, so restore the history pointer to the remembered one.  Except when that item was at the top of the list, then it may have fallen off the top of the stack (if the user typed an answer that did not already exist in history).  So... remember the history pointer only when its prev is not NULL, AND restore the remembered one only when it isn't NULL.

Pfff...  That is some ten, twelve, fourteen lines of code, all for something that will probably never occur and if it were to occur, it would be just an inconvenience, a slight confusion.  So, I'm not going to bother.

But one improvement can be made: reset the history pointer only when the user starts to go into history, and at the end reset the history pointer only when magichistory is set, so that the user can do ^W ^C (Search and Cancel) in a help text without disturbing the history pointer in an earlier search prompt.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 09 Oct 2021 03:07:46 PM UTC, comment #2: 

I've tried it, but clearing the answer (when it was filled in from history) when the user comes back from ^G^W is not nice -- it is too unexpected.

Another solution might be to disable history when searching in the help viewer.  And when searching in the file browser: it has always annoyed me that a filename search polluted the search history of the editor.  But... I can imagine a user navigating through several folders searching for a certain file.  Having the history available might be handy.  Although maybe just having the 'last_search' set would cut it for most cases.

So, maybe only disable history when searching in help => !inhelp.  ...  Tried it.  It would require suppressing 'last_search' when in the help viewer, but that is not nice when searching the help text a second time.

So... we will just have to live with the discrepancy.  It's not that it will happen often: the help text of the Search menu is fairly small and will fit entirely on a screen of 29 rows.  So... let it be.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 09 Oct 2021 10:54:16 AM UTC, comment #1: 

Fixed in git, commit 3d6dcb95, by resetting the history pointer both at the start and the end of acquiring an answer from the prompt.

However, now there is a discrepancy between the Execute/ReplaceWith prompts and the Search prompt: invoking ^G^W from the latter will have reset the history pointer when returning from ^G, but returning from ^G to the Execute or ReplaceWith prompt will have left the history pointer at the place where it was, and the user can continue to move up or down as if nothing happened.  The latter is in fact cool behavior, but implementing the same for the Search prompt might mean that the history pointer is pointing at an item that no longer exists (because the search in the help text selected that item and thus caused it to be deleted and an equivalent item to be re-added at the bottom of the list.

It might mean that, but currently it doesn't: re-adding an equivalent item at the bottom sets the relevant history pointer to the bottom of the list.  See at the end of update_history().  But if history_list were made a local variable to acquire_an_answer(), then indeed it could be left pointing at an item that no longer exists... Crap.  So... the only consistent solution seems to be to reset all history pointers whenever a new prompt is presented.  And it would be nice too if (upon returning to a prompt from a help text) any answer that came from history (and was not typed by the user herself) is cleared, to not maybe make the user think she is still in the middle of history.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 09 Oct 2021 08:34:48 AM UTC, original submission:  

To reproduce, run 'src/nano --ignore'.
Then type: ^W aaa <Enter> ^W bbb <Enter> ^W ccc <Enter>
Now type: ^W <Up> <Up>
See that "bbb" is shown after the prompt.
Now type: ^G ^W <Up>
See that "aaa" is shown after the prompt.  At the secondary prompt, the history list does not start at the end but continues where the primary prompt left it.  This is wrong.

Expected behavior: whenever a new prompt appears, going into history should start at the last added item, not somewhere midway.

Upon returning from the secondary prompt to the first one, it might make sense to be again at the same point in history where the user was when ^G was invoked (like when ^K or ^U is typed in the middle of history), but it would be fine too to start at the bottom of the list (like is done now), because invoking a help text is a rather big interruption.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by bens (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 logged-in users can vote.




    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-10-09 bens StatusNone => Fixed

    Back to the top

    Powered by Savane 3.7