Ctrl+r for search

[santagada]

Hi,

Thanks so much for porting PyCMD to python 3 and moving to github!

I've tried the latest release here and while most seem to work it seems like Ctrl+R is not bind to search, and Shift + F3 also doesn't seem to work. Together with ctrl + a and ctrl + e and general up and down for history, history search on ctrl+r is my most used keybinding on bash. Is there a reason for it not being set?

[horeah]

Hi,

History search in PyCmd uses a different paradigm: you type some search string, then use the Up arrow (or Ctrl-P) to iterate the list of commands filtered by the search string. Is your question related to using Ctrl-R instead of Up (or Ctrl-P) in this scenario, or is it rather about supporting the "bash-style" incremental search?

p.s. F3 and Shift-F3 are used for a very spartan "search substring within current command" feature.

[santagada]

I tried and I think this works well, although the ctrl+r ui (being a separate prompt) is nice. I was refering to bash-style incremental search.

any plans on autocomplete of whole command line like fish does it?

[horeah]

Whaddayaknow! Turns out that fish has just added Ctrl-R for incremental history search: https://fishshell.com/docs/current/relnotes.html So I guess you had the right intuition :grin:

I still prefer the "type + Up" paradigm but I guess it would not hurt to support "Ctrl-R + type" as well; the implementation might be as simple as feeding the history into a new Window instance.

As for autocomplete: incorporating it into the limited windows-console color scheme is a bit hard; it might make more sense if/when PyCmd switches to an ANSI console (which seems to be increasingly popular on modern windows versions).

[santagada]

Yep I've been using the "new" windows terminal for more than 2 years now, AFAIK it has full color support

[horeah]

An implementation of incremental history search (Ctrl-R) has been pushed on branch "ctrl-r"; it does not perfectly imitate bash or fish -- it tries to be better 😉

You can trigger it on an empty line, or after typing some characters, or even during the filtered history search (the latter two will start the list with a pre-filled search string).

Do you want to give it a spin and see how it works for you?

Note: there are some rough edges that I am aware of (they are mostly limitations of the Window implementation and they can be probably fixed separately):

1. entries that are longer than the screen width cannot be shown in full; for now, long commands are displayed in a shortened form
2. If the filter text is long enough to overflow the screen width, it will destroy the rendering of the Window
3. it would be nice to have the filter matches highlighted
4. Up/down navigation does not wrap around (Issue #4)
5. The search text is limited to alphanumerics and whitespace. I am undecided whether to keep this limitation or not: in practice it seems to pair well with the "fuzzy" search that PyCmd implements.

Feedback is much appreciated!

[santagada]

I'll take a look at it, but seems like a great start. The long line breaking thing is a common problem in windows terminal but would be nice to be fixed. Maybe look at a prompt toolkit library called wcwidth it calculates string width even taking into account emojis (which are possible now on the new windows terminal)

[santagada]

the problem is you can't search for a an option because there's no way to type --, why are you limiting to a small set of characters?

[santagada]

also ctrl+c doesn't close the search, would be nice if that also closed the filter

[horeah]

I'll take a look at it, but seems like a great start. The long line breaking thing is a common problem in windows terminal but would be nice to be fixed. Maybe look at a prompt toolkit library called wcwidth it calculates string width even taking into account emojis (which are possible now on the new windows terminal)

Thanks for the tip; I had a look and found several places in the code where PyCmd is incorrectly using the string length as a cell-width (ignoring the actual span of the characters). I created a new issue to track this: #9

the problem is you can't search for a an option because there's no way to type --, why are you limiting to a small set of characters?

The implementation of the interactive window was originally targeted at completing paths; lots of characters are forbidden for paths, and the search is fuzzy and token based -- so back then I decided to make my life simple and disallow special characters (as a temporary solution) to avoid having to escape/unescape for regex. It is indeed time to improve this; there are some corner cases which will be hard to support in an intuitive way (e.g. searching for whitespace) but I think we should be able to handle most of the non-ascii characters in the filter string. Thanks for pointing this out!

also ctrl+c doesn't close the search, would be nice if that also closed the filter

I'm not so sure about Ctrl-C -- I would prefer to reserve this shortcut for copying the selected entry (this is maybe not so useful when searching the command history, but would come in handy when searching the completions or the Alt-D directory history). Ctrl-G as an alternative to Esc, on the other hand, is undisputed -- I've added a note to #5.

[horeah]

5f0114c4c203b68cac79149f422db8a23c599d36 relaxes the constraint on the filter text as suggested.

[santagada]

IT works great now

[horeah]

Ok, I guess we can close this; the feature is included in release 20230202, and subsequent improvements are to be tracked by separate issues.

@santagada Thank you for the idea(s) and the feedback!