bugGNU nano - Bugs: bug #54889, [Request] re-add a per-syntax...

 
 

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

bug #54889: [Request] re-add a per-syntax filtering command

Submitter:  Benno Schulenberg <bens>
Submitted:  Tue 23 Oct 2018 07:00:12 PM UTC
   
 
Severity:  1 - Wish Status:  None
Assigned to:  None Open/Closed:  Closed

Jump to the original submission

Wed 02 Jan 2019 06:47:30 PM UTC, comment #7: 

Please stop spamming me with irrelevant stuff.

Benno Schulenberg <bens>
Group administrator
Wed 02 Jan 2019 05:54:22 PM UTC, comment #6: 

I'd like to provide a user experience report as it relates to the idea that `^R^X|<command>^M` is a suitable replacement for the functionality of `formatter`.

There are some difficulties I encountered.

The first is that `go fmt` does not operate on pipes; it formats files in-place. The implementation of `go fmt` is that it calls `gofmt`, which does operates on pipes when not told to do otherwise. So, this specific issue is tractable. But, the robustness principle suggests that nano should be able to handle file processors that work like `go fmt` does, like `formatter` did.

The second issue is one I foresee encountering, but didn't happen to run into. `gofmt` performs syntax validation as part of its formatting, and when there are syntax errors, instead of outputting formatted source code, it outputs the syntax errors. With `^R^X|go fmt^M`, such errors would replace the source code. This is at least undesirable, and is surprising enough that it could result in catastrophe for a naive user.

The third issue I encountered is that the behavior of `^R^X|go fmt^M` depends on whether `multibuffer` is set or not. When multibuffer is set, the output of the execution goes into a new buffer, which is not desirable in the context of a formatter. If we're imagining sharing snippets of nano configuration, I think it would be undesirable for the user to need to be aware that a binding or key sequence needs to differ based on whether multibuffer is set or not.

I think the ideal solution here is a way to perform a single execute as though multibuffer were disabled, without needing to run `^R^[F` to completely un-set multibuffer (which is non-idempotent, and moreover would fail if multibuffer were temporarily un-set for some other reason).

The fourth difficulty is that after the execution is complete, the cursor is moved to the end of the file, losing my place. This didn't happen with formatter. I acknowledge that it's hard to ensure the cursor is returned exactly, but keeping it on the N'th line or N'th character would at least keep it in the same neighborhood.


I know this is a little tangential to the specific discussion here, but I hope that any filtering implementation would consider these concerns.


On the subject of `sbind`, I'd propose two possible improvements; one is that the command could include an indicator of the bind's scope. E.g., `bind syntax M-F "^R^X|gofmt^M"`. This way there's still only one command, but non-syntax binds will still be global.

The second improvement could be a to borrow the `$""` syntax from Bash, to allow for writing command sequences without needing verbatim characters. Specifically, I propose that a bind like `bind M-F $"^R^X|gofmt^M"` would convert `^R`, `^X`, `^M`, `M-…` to the relevant literals, presumably allowing for escape sequences `\\`, `\^`, `\M`, and that behavior without `$` would be unchanged.

This would allow sharing as you describe, without breaking any backwards compatibility.


As I mentioned elsewhere, I'm happy to pitch in and write some code to support these ideas; I'd just like there to be consensus on an approach before I do the work of implementing something.

Patrick Bogen <pdbogen>
Thu 08 Nov 2018 10:47:51 PM UTC, comment #5: 

FYI, the bind command can't be reused for syntax binds, doing so would require all nanorc binds to be placed before syntax definitions declared inside nanorc.

Brand Huntsman <brand>
Mon 29 Oct 2018 03:10:06 PM UTC, comment #4: 

About the 'sbind' command...  First off, I hated the name.  Second, it should not be necessary to introduce a new command.  Looking over the code, it looks entirely feasible to reuse the 'bind' command and allow it to be used inside a syntax.  It would make the patch considerably smaller too.

Third, the main purpose of allowing to bind a key to a string was to allow the user to put the function keys to some good use: to make them generate some often used words or strings.  (I realized that the string could contain anything, also control characters and complete escape sequences (in short: commands), but I regret having advertised this, because it is unstraightforward to use and results in having literal control characters in a config file, which should rather be all human-readable plain text.)  But the main or only purpose of allowing string binds in a syntax file is to allow the user to bind some often-used command sequence to a key -- most of them will start with ^R^X| and end with ^M.  For the determined user, it is not a problem to make such binds.  But, as Brand said, it is awkward, cannot be copy-pasted from a webpage or IRC or whatever, and assumes none of the used keys has been rebound to something else.

So, if I would allow the 'bind' command to be used inside a syntax, the pressure toward being able to refer to functions by name in a string bind would increase.  And I don't want to go there.

Benno Schulenberg <bens>
Group administrator
Thu 25 Oct 2018 04:15:06 PM UTC, comment #3: 

For the name, I'd agree that "fixer" works much better than "frobber".

David Lawrence Ramsey <dolorous>
Group Member
Wed 24 Oct 2018 10:47:16 AM UTC, comment #2: 

Why not that "sbind" command so syntaxes can have multiple keys? The formatter commands could be added back to syntaxes using sbind, and reserve M-F as a comment in the code so it doesn't get used.

Brand Huntsman <brand>
Wed 24 Oct 2018 09:08:40 AM UTC, comment #1: 

Better name for the command: 'fixer'.  Beautifully short, most people will now what it means, and it can encompass the meanings of formatting and spell checking and sorting.

Benno Schulenberg <bens>
Group administrator
Tue 23 Oct 2018 07:00:12 PM UTC, original submission:  

When removing the 'formatter' command, I thought of later allowing the 'speller' command to be per-syntax (that then could be "abused" to do filtering or whatever instead of spell checking).  But after thinking a little more, this is no good, because it would mean that ^T would be "hijacked" by the syntax and it would no longer be possible to invoke the basic spell checker.

I didn't think the 'formatter' command would be used by anyone else other than a few Go programmers, but apparently this is the case.  See bug #54651, and http://lists.gnu.org/archive/html/help-nano/2018-09/msg00000.html.  And I can see that it makes sense to have a per-syntax formatter/transformer/processor.

So... I want to re-add something similar to the 'formatter' command but without copying more than a hundred lines of code.  I want to reuse the code for the alternate spell checker.  The messages that that code spits out can be trimmed down and made more general without losing much clarity -- making them maybe even clearer because more concise.

The problem I had was: what to call the new command?  'formatter' is too specific in my opinion.  'filter' is not good because it will make the user think that the command will use standard input and standard output for in and out, but the alternate spell checker uses a temporary file that the command needs to operate on.  I've been thinking about: comb, rake, kneader, massager, groomer, neatener, tidier, transformer, rinser...  The words that start with a "t" are unsuitable because they will make the user think of ^T too much.  The word "comb" would be good but shares too many letters with the command 'comment'.

So... I'm thinking of 'frobber'.  It is computer-centric, and connotes "working on something", "making changes to something".  That something would be the buffer, and in practice: the temporary file.  It would be bound by default to M-F (a keytroke that was recently freed), which would be good mnemonics.

Benno Schulenberg <bens>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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 pdbogen (Posted a comment)
  • -email is unavailable- added by dolorous (Posted a comment)
  • -email is unavailable- added by brand (Posted a comment)
  • -email is unavailable- added by bens (Submitted the item)
  •  

    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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-02 bens Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code