suplemon
suplemon copied to clipboard
richrd
Can't find newlines (\n) when regex find isn't enabled
I've been thinking about this, and UX wise it's not entirely simple. When the user uses the non-regex find, we don't know wether they wan't to use escape sequences like \n, \t or not. Maybe they wan't to find the characters '\n' in their code, or maybe their looking for a new line.
Should we actually just constrain escape sequences to regex search? Now the prompts only support single line input (simple to accept with enter), so inserting an actual new line into the search prompt can't be done if multi line prompts aren't implemented.
Anyway, if escape sequences are to be interpreted I'd probably go with this: http://stackoverflow.com/questions/4020539/process-escape-sequences-in-a-string-in-python
Sublime Text doesn't allow for escape sequences. Instead it does the literal representation in the search field (i.e. a new line scrolls the search field/expands the height of the search field)
See "Shift+Enter" inside of "Find" for "Find in File":
Multi line prompts would be nice to have. Only problem is there's no support for "shift-enter" in the termimal :/
I wish it helped. We should be in raw mode already https://github.com/richrd/suplemon/blob/master/suplemon/ui.py#L120
Anyway I do think a multi line prompt could be something worth having, but maybe it's not worth it just for this usecase.
Ah, I think I missed that transition. I concur with your work to value assessment and maybe there's another solution
For now I'll keep the behaviour as it is. For regex searches it makes perfect sense for \n etc escape sequences to work. For the basic find it would be ambigious. If (and when) multi line prompts are implemented this could be resolved. Closing for now though.
Let me backtrack a little regarding shift+enter (and other special key combinations). Apparently curses doesn't distinguish between enter and shift+enter when using curses.key_name, and Suplemon relies heavily on that function. But after some testing I found that we actually do receive different key codes for shift+enter and enter. So I'll try and get this (issue #164) fixed for next release, but it'll probably require lots of testing to make sure the solution doesn't break anything.