GNU nano - Bugs: bug #61692, [Wish] allow binding a key to a...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61692: [Wish] allow binding a key to a sequence of functions and strings
Submitter: | Tasos Papastylianou <tpapastylianou> | ||
Submitted: | Fri 17 Dec 2021 03:40:09 PM UTC | ||
Severity: | 1 - Wish | Status: | Fixed |
Assigned to: | bens | Open/Closed: | Closed |
Jump to the original submission
Wed 16 Nov 2022 08:12:03 AM UTC, comment #19: |
Benno Schulenberg <bens> |
Thu 18 Aug 2022 01:27:31 PM UTC, comment #18: I don't really want to encourage including control codes now that {function} things are possible. Also, I would prefer to keep it a dry manual instead of making it more like a tutorial. But... I'll think about it.
|
Benno Schulenberg <bens> |
Thu 18 Aug 2022 10:03:57 AM UTC, comment #17: I would still mention the fact that control codes can be inserted verbatim into the string, since this is not mentioned anywhere else in the nanorc (or nano) man pages.
|
Tasos Papastylianou <tpapastylianou> |
Thu 18 Aug 2022 09:11:44 AM UTC, comment #16: Would the following change be good enough?
|
Benno Schulenberg <bens> |
Thu 18 Aug 2022 08:47:14 AM UTC, comment #15: The syntax coloring and replacing existing macros with the new functional form was a nice touch :)
|
Tasos Papastylianou <tpapastylianou> |
Thu 18 Aug 2022 08:26:10 AM UTC, comment #14: Thanks Benno!
|
Tasos Papastylianou <tpapastylianou> |
Thu 18 Aug 2022 07:47:19 AM UTC, comment #13: Anyway, fixed in git, commit 958ec294, plus some subsequent commits for syntax coloring and documentation. |
Benno Schulenberg <bens> |
Thu 18 Aug 2022 07:39:44 AM UTC, comment #12: Hi Tasos -- Oh, I've missed your email. Savannah has been behaving strangely for some days, so maybe it failed to send the email?
|
Benno Schulenberg <bens> |
Tue 16 Aug 2022 12:35:39 AM UTC, comment #11: Hi Benno, thanks for putting so much thought into this!
|
Tasos Papastylianou <tpapastylianou> |
Fri 12 Aug 2022 12:50:51 PM UTC, comment #10: Monday I started coding for the format:
But in the afternoon I had already fifty lines of code and was still just parsing the rcfile, and wasn't even halfway... The advantages of the single-string format then became quite clear -- the advantages of this format:
It requires zero extra code for parsing the rcfile, while the parsing during the execution phase is dead-simple. So I wrote down in words how this execution part should work. The crucial idea was: to not want to interpret the whole expansion string in one go and store the entire result in the keyboard buffer (as I thought to do in a previous comment), but to interpret one fragment at a time, either a command cartouche or a piece of literal text outside of those cartouches, and after each fragment let the keyboard routine come back for more. Quite simple, really. On Tuesday I started to code this up (starting from the "outside", with the variables and the special keycodes and the two hooks into the input routines), and at the end of the afternoon I had it working. It worked on the first run, too. :) Wednesday morning I fixed one bug, and after that just applied some polishing. So here it is. |
Benno Schulenberg <bens> |
Tue 18 Jan 2022 03:05:18 PM UTC, comment #9: One argument against introducing the escaping of a double-quote (in whatever way) is that it will break any existing string bind that contains a double-quote. But I don't see how each and every breakage can be avoided: even if the whole sequence of function names and strings has to be inside double-quotes, we would need to be able to tell which things are meant as function names, so some character or character sequence needs to be special, which will break some string binds -- maybe exceedingly few, but still. So... I prefer the more elegant way and have it be obvious what are function names and what are literal strings. |
Benno Schulenberg <bens> |
Mon 17 Jan 2022 04:10:01 PM UTC, comment #8: Hi Benno. Yes, you're right. Sorry, I see what you were saying now.
|
Tasos Papastylianou <tpapastylianou> |
Wed 12 Jan 2022 03:19:14 PM UTC, comment #7: There is no necessity for a double-character delimiter. I see no problem with parsing something like:
Here a doubled double-quote means one escaped double-quote, and a semicolon within a string is not special. Of course, this requires a new string parsing routine for the key binding code, but I don't see a problem with that, as the code has to change anyway, to allow for the concatenating of several function names and strings. |
Benno Schulenberg <bens> |
Sat 08 Jan 2022 05:35:49 PM UTC, comment #6: Hi Benno, sorry for the delay, I did not spot your response on my email.
|
Tasos Papastylianou <tpapastylianou> |
Wed 05 Jan 2022 09:58:09 AM UTC, comment #5: Using a double colon and two spaces to separate function names is horribly verbose. Remember what I liked about your first suggested syntax? That is was lean and clean. Also, the semicolon is a well-known command separator, and using no whitespace glues the function names nicely together, showing that they are single unit. (Of course there could still be spaces inside strings, but that is the nature of strings: they end only at an unescaped closing quote. And of course a semicolon inside a string is not special.)
|
Benno Schulenberg <bens> |
Sat 01 Jan 2022 08:40:33 PM UTC, comment #4:
If you still think this is a good idea, perhaps there is a better delimiter that avoids potential bugs with plain semicolons, and can still respect the 'final double quote closes the quote' after tokenization. Perhaps ' :: ' (i.e. two colons with spaces on either side)? E.g.:
I don't necessarily disagree, but I would like to 'defend' the points nonetheless for the sake of the completeness:
Perhaps, yes. But, I think it would still be sufficiently friendlier than using only prebound keystrokes. Compare:
Even without the involvement of functionnames, string macros containing control codes are already a bit cumbersome to type anyway, but their usefulness more than makes up for it. While I agree that the 'clean' syntax above would be preferable, I don't necessarily think the 'okayish' syntax would be more of a 'nuisance' than current string macros, where things need to be bound to non-clashing keys first before use.
Perhaps not, but they would still be shareable as files. The recent uppercasing/lowercasing macros you included in the sample.nanorc are a good example of this.
I whole-heartedly agree with you on this! Though, in vim, this is partly because the alternative to typing commands sucks: there's no menu, the shorcuts are not particularly intuitive or memorable, and discovering the right keyboard shortcut is an exercise in frustration. In nano's case, however, an 'evaluate' menu wouldn't abolish existing functionality or replace nano's menu-based approach; it would simply be extra functionality for whoever needs it, and invisible to whoever doesn't. But, if present, it becomes very useful (e.g. for macros); and if this menu were to accept 'set' and 'bind' commands as well, then it becomes very powerful indeed.
|
Tasos Papastylianou <tpapastylianou> |
Sat 01 Jan 2022 02:56:02 PM UTC, comment #3: Creating an 'evaluate' function would avoid having to make changes to the parsing routines in rcfile.c, true, but the resulting string-bind commands would still suffer from most of your original objections against the current state of things.
|
Benno Schulenberg <bens> |
Thu 30 Dec 2021 05:21:59 PM UTC, comment #2: My proposed syntax was simply a visual example. I don't know if I would suggest that explicitly as the actual syntax for this; in fact, I can see one big problem with it, which relates to how nanorc treats quoted values specifically, by treating the last double quote as the closing quote, and interpreting all other in-between quotes as literal quotes.
|
Tasos Papastylianou <tpapastylianou> |
Tue 28 Dec 2021 03:34:18 PM UTC, comment #1: Yes, being able to bind a key to a sequence of functions and strings would be cool. It has been proposed before (see [1]; continued in [2]), but your proposed syntax is much leaner and cleaner:
I can imagine how this could work: when such a sequence of functions and/or strings is detected while parsing an rc file, then for each function a special keycode is added to the 'expansion' string followed by the function name. This rcfile routine should check that it is an existing function name, but not whether it is available in the specified menu, as preceding function names could have entered a different menu. When the bound key is pressed, the whole expansion string is implanted in the keyboard buffer, as is already done. When then parse_kbinput() encounters the special keycode, it will read the function name, check whether it exists in the current menu, and if so, execute it, and when not, report an error on the status bar and discard the entire rest of the keyboard buffer. Anything I'm overlooking?
|
Benno Schulenberg <bens> |
Fri 17 Dec 2021 03:40:09 PM UTC, original submission:
At the moment (nano 6.0), the 'bind' command can:
|
Tasos Papastylianou <tpapastylianou> |
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 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-11-16 | bens | Open/Closed | Open | Closed | |
2022-08-18 | bens | Status | Ready For Test | Fixed | |
2022-08-12 | bens | Attached File | - | Added 0001-input-interpret-commands-of-the-form-functionname-in.patch, #53565 | |
Status | In Progress | Ready For Test | |||
2022-08-10 | bens | Status | None | In Progress | |
Assigned to | None | bens | |||
2021-12-28 | bens | Severity | 3 - Normal | 1 - Wish | |
Summary | [Wish] Enable bind to perform a sequence of functions/commandstrings rather than just a single function or commandstring | [Wish] allow binding a key to a sequence of functions and strings |
Powered by Savane 3.13-f8d8.
Corresponding source code
Released in nano-7.0.