GNU nano - Bugs: bug #52257, shortcut issues regarding the...
You are not allowed to post comments on this tracker with your current authentication level.
bug #52257: shortcut issues regarding the search prompt inside the help viewer
Submitter: | David Lawrence Ramsey <dolorous> | ||
Submitted: | Sat 21 Oct 2017 12:05:00 AM UTC | ||
Severity: | 2 - Minor | Status: | Fixed |
Assigned to: | dolorous | Open/Closed: | Closed |
Jump to the original submission
Wed 25 Oct 2017 06:03:59 PM UTC, comment #6: |
Benno Schulenberg <bens> |
Sat 21 Oct 2017 05:54:34 PM UTC, comment #5: As for the other undocumented keys in the file browser, I'd agree with not documenting those because they're there for compatibility with pilot, as opposed to there to match the rest of nano; the other bits are the ones I'd consider more important.
|
David Lawrence Ramsey <dolorous> |
Sat 21 Oct 2017 02:17:54 PM UTC, comment #4: Okay. I figured having the history inside the help viewer was for symmetry with the search code used elsewhere. And... fine on not displaying shortcuts, then.
|
David Lawrence Ramsey <dolorous> |
Sat 21 Oct 2017 08:12:48 AM UTC, comment #3: Ad 1.) How often would one need the history feature at the search prompt inside the help viewer? Exceedingly seldom, I guess. So to display these shortcuts is just a distraction to the user. Also, if we were to put them there, we would have to add another key (probably ^L Refresh), because not having the ^P and ^N neatly paired in one column is unacceptable.
|
Benno Schulenberg <bens> |
Sat 21 Oct 2017 12:28:07 AM UTC, comment #2: ...because having undocumented features inside the help browser, which has no purpose other than documenting things for the user, just seems wrong. |
David Lawrence Ramsey <dolorous> |
Sat 21 Oct 2017 12:07:36 AM UTC, comment #1: Assuming the answer to both these questions is yes, I've attached a patch that makes the relevant changes. (I can split it up if necessary.) |
David Lawrence Ramsey <dolorous> |
Sat 21 Oct 2017 12:05:00 AM UTC, original submission:
Currently, as of git 4d35835, the search menu inside the help browser has a few issues regarding its shortcuts. (I've read through the old thread from November 2016, and I'm not certain whether these are considered problematic, so I'd like to make certain here.)
|
David Lawrence Ramsey <dolorous> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 7 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-11-19 | bens | Open/Closed | Open | Closed | |
2017-10-25 | bens | Severity | 3 - Normal | 2 - Minor | |
Status | None | Fixed | |||
Assigned to | None | dolorous | |||
2017-10-21 | dolorous | Attached File | - | Added 0001-help-allow-first-last-line-to-work-at-help-s-search-.patch, #42208 | |
Summary | shortcut issues regarding the search prompt inside the help browser | shortcut issues regarding the search prompt inside the help viewer | |||
2017-10-21 | dolorous | Attached File | - | Added 0001-help-show-search-shortcuts-for-prev-next-history-and.patch, #42203 |
Powered by Savane 3.13-f8d8.
Corresponding source code
The ^W^Y and ^W^V combinations have been added to the help viewer, git commit ddd300af. Thanks for the patch.
Thank also for the reminder about consistency, because in the past I have considered disabling the search history in the file browser: I thought that the things one searched for in the browser would just be a "hindrance" when using the search history in the editor. But you're probably right: it's better that the search history works consistently at all search prompts.