bugGNU nano - Bugs: bug #65897, [Wish] the ability to 'enact'...

 
 

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

bug #65897: [Wish] the ability to 'enact' predefined string macros

Submitter:  Tasos Papastylianou <tpapastylianou>
Submitted:  Wed 19 Jun 2024 07:20:19 PM UTC
   
 
Severity:  1 - Wish Status:  Wontfix
Assigned to:  None Open/Closed:  Closed

Jump to the original submission

Wed 31 Jul 2024 07:00:46 AM UTC, comment #15: 

Looking forward to your blogpost.  :)

Benno Schulenberg <bens>
Group administrator
Thu 25 Jul 2024 02:02:02 PM UTC, comment #14: 

Hi Benno! Sure, I'll do that. I admit I never thought about joining any of the mailing lists before ... but why not.

I'll post something as soon as my academic duties allow. I've been wanting to do a blogpost about my nano workflow / custom macros for a while now anyway :p

Tasos Papastylianou <tpapastylianou>
Tue 23 Jul 2024 07:46:26 AM UTC, comment #13: 

Maybe you could post the {enact} patch and some example to nano-devel and see if there are like-minded people out there.

(One little side note: there is no bindable function named 'space' because no one ever requested the ability to bind space to some other key than the space bar.  And nowadays, if anyone wanted to do such a thing, they could use a string bind -- so 'space' is not going to be added.)

Benno Schulenberg <bens>
Group administrator
Sun 21 Jul 2024 11:35:53 PM UTC, comment #12: 

Hi Benno!

Alas, I failed to convince you! I do agree with your general sentiment, that more powerful macros are no match for editing nano sources and adding features directly -- though I did not mean to imply this was the intended goal with enact!

It is a shame, but I respect your decision, thank you for giving this a good deal of consideration, and for the initial patch implementing enact. I admit that, having witnessed the power of enact, I now cannot live without it, and will be patching all my future nano versions to include it! But I understand if you don't want this to be a thing for everyone.

Having said that, I would like to address your comments below, as I do feel they miss the point a bit, and make one last attempt to state why I think enact would be a worthwhile 'plus', rather than a 'minus' in nano:

- Comments re first example: I didn't mean to imply the macro would be 'aesthetically comparable' to something that could be achieved by directly editing the nano sources; only that it adds enough extra power to the macro system, such that that functionality could be now more-or-less replicated as a macro simply by using enact (whereas previously it could not, at all). It was simply meant to demonstrate the added power enact brings to macros. But obviously these would still behave like macros. E.g., there's obviously no way for a macro to generate a custom 'error' message, since nano does not provide that kind of 'api' to users.

- Comments re second example: same as above. It's still a macro. Obviously a bespoke solution implemented at the source level would naturally be a lot more flexible. But the point was to demonstrate that enact finally allows a user a strategy to achieve saving/restoring anchors, which is currently not possible with simple stringbinds. This particular example was also intended to show that enact would enable many feature requests submitted here (many of which were labelled 'wontfix') to be dealt with by the users themselves via custom macros. I believe a user given the choice of something that works but is 'ugly' vs something conceptually beautiful that never comes to exist, would prefer the former!

- Comments re third example: I am actually the same as you on this. But this kind of numbered-actions thing is something often touted by vim users as a godsend, which tells me not everyone has the same workflow preferred by you and me! Having said that, I could see it being useful for things like, e.g., easily making an html table with x rows and y columns, or replacing the first N entries only, etc. But again, it was just to demonstrate what enact enables which is currently not possible. I was not implying this is functionality that nano desperately needs, let alone officially.

- Comments re fourth example: I think you misunderstood what this macro does. You can indeed use this to see immediately the effect of each function/keystroke, this is exactly the point. You can execute this keystroke by keystroke / bracefunction by bracefunction, and watch it happen live. The intent is not to write the whole macro all at once and only then execute it - this defeats the purpose. The big difference between this and writing a macro down in nanorc as a keybinding "in your head" offline, is that with this you can perform your macro on your live session, test it keystroke by keystroke (or more if preferred), and have it 'saved' simultaneously as a result. You can even 'undo' a couple of keystrokes and continue, instead of having to restart 'recording' from scratch (as you would currently with an interactive macro gone wrong half-way through). This is very powerful!

- Comments regarding 'ugliness': of course, macros will always look 'hackier' compared to implementing features directly in the source code. But macros are largely "user-code", from users who probably care more about getting their work done or tailoring their workflow to their needs/preferences than about nice messages or flickering. Besides, if users want to write ugly macros for themselves, I don't quite get why that's a big problem -- plus, people will do that anyway, with or without enact! Enact simply adds another layer of flexibility to the macro system, making it more useful for people who 'do' use macros (e.g. in the same way that bracefunctions did).

If I've still failed to convince you, please accept my apologies for wasting your time and feel free to close the ticket, and thank you for your thoughtful consideration of this feature so far, and for the initial patch (like I said, I personally have found this so useful that I will keep using it!)

Tasos Papastylianou <tpapastylianou>
Sun 21 Jul 2024 12:02:01 PM UTC, comment #11: 

About the first example, in comment #6: It works, but 1) it "flickers" the screen (because of the quick switching between buffers), and 2) any cursor movement does not reset the first invocation to act as `center`.

About the second example in comment #7: It's not good enough that M-! saves just one anchor -- it would have to store all anchors at once, and then restore them all after having stored them, and give feedback saying that the anchors were stored.  When using M-", for me, the anchors were restored one line before where they were.

About the third example in comment #8: When wanting to execute a macro mutiple times, I normally don't know how many times it needs to run, and it would take more time to first count the needed number than just slowly executing the macro one time after the other until done.  So I don't consider this a very useful example.  Also, the error message "No more open file buffers" at the end is unpleasant.

About the fourth example in comment #10: I don't see why one would cumberfully write a macro with braced function names while not being able to see immediately the effect of each function.  And if someone realy would write something that way, I don't see why they wouldn't write it straightaway as a string bind in a .nanorc file.

In short, your examples have convinced me that actual uses of {enact} look ugly -- flickering, unwanted feedback, missing desired feedback) -- too ugly to want to include {enact} in nano.  Also, the resulting needed string binds are so convoluted that the average nano user (and certainly I) can't be bothered to try and figure out how the heck these things work, much less be able to construct such string binds themselves.

Benno Schulenberg <bens>
Group administrator
Fri 19 Jul 2024 11:07:00 PM UTC, comment #10: 

Here is a final example which you might also find useful/interesting. This provides the ability to run a macro while also saving it to file for posterity at the same time. The saved macro can then be enacted later, or bound to a keystroke in nanorc. A nice side-effect is that this allows one to execute actions directly via the bracefunction names, rather than require them to first be bound to a keystroke; therefore this allows one to call bracefunctions within a live nano session, and have them executed appropriately.

Note that a previous bugreport made a request in the same spirit, which at the time was deemed unimplementable and closed as a wontfix (bug #58991). Enact allows a solution for this relatively trivially.

Required:

1. ~/.local/share/nano/savedmacros on your system (this will be created at first run if not already present).

2. The following keybinding in your nanorc:

# enact sequence of keystrokes (or bracefunctions) provided at 'execute' menu, while also saving resulting string macro to file.
bind M-! "{home}echo "{end}" | tee -a ~/.local/share/nano/savedmacros{enter}{{}prevbuf}{end}{{}nextbuf}{{}exit}n{{}prevbuf}{enact}" execute


How to use:

Enter the 'execute' menu normally, and start writing your macro in stages. You can write as little as a single keystroke (/ bracefunction), or the whole macro all at once. Press M-! while still at the execute menu to have the (potentially partial) macro executed. This will also result in the partial macro snippet written to your 'savedmacros' file.

Obviously, the resulting partial snippets may have to be joined together afterwards in the 'savedmacros' file, to make up the proper, full, oneliner macro

Caveats:

- intentional spaces in the macro should be avoided, since extra spaces may be introduced later when 'joining' the partial macros into a single line; if a space is needed, one could use the (non-existent bracefunction) {space} on its own instead, and replace that with an actual space later after 'joining' all the partial macros and removing the 'joining' spaces. (incidentally I found it odd there's no {space} function in the same way there's an {enter} function for macros).

- since this relies on 'echo', double quotes need to be escaped here, even though they generally don't need to be escaped in nanorc.

- when literal '{' needs to be inserted, the stringmacro syntax of {{} should be used, to avoid interpreting as bracefunctions (just like in nanorc).

- for control codes, these need to be entered 'verbatim'

Tasos Papastylianou <tpapastylianou>
Thu 18 Jul 2024 09:01:05 AM UTC, comment #9: 

Thanks, Tasos, for the three examples.  I will try them out and will post my thoughts in a couple of days.

Benno Schulenberg <bens>
Group administrator
Mon 15 Jul 2024 09:10:34 PM UTC, comment #8: 

With the patch from bug #65991 applied which fixes the issue of running recorded macros multiple times via enact, here is another example. This time, it makes use of an external script. The following is an implementation of the 'repeat recorded marco N times' functionality mentioned below.

Given the following script (named nano-repeat)

#!/bin/bash

if test $# -ne 1; then echo "ERROR: nano-repeat failed - incorrect arguments" && exit 0; fi

REPETITIONS="$1"

echo -n "{prevbuf}"
for i in $(seq $REPETITIONS); do echo -n "{runmacro}"; done
echo -n "{nextbuf}{exit}n{prevbuf}"

and the following nanorc entry:

bind M-! "{home}./nano-repeat {enter}{enact}" execute

To use:

Record an interactive macro (e.g. a cut move).
Then trigger the execute menu, then type a number followed by M-!

Tasos Papastylianou <tpapastylianou>
Mon 15 Jul 2024 11:41:21 AM UTC, comment #7: 

Here is another small example. This one uses the shell in order to calculate a while loop, but no external scripts otherwise (though arguably the whole thing could have been packaged as an external script, yes).

This can be used to save and restore anchors (currently an open bug here, requested by another user, see bug #62269 ).

# save anchors
bind M-! "{firstline}{mark}{nextanchor}{anchor}{right}{execute}| wc -l >> ~/.local/share/nano/anchors{enter}{exit}n" main

#restore anchors
bind M-" "{execute}echo -n "{{}prevbuf}" && cat ~/.local/share/nano/anchors | while read -r LINE; do echo -n "{{}gotoline}$LINE{{}enter}{{}anchor}"; done && echo -n "{{}nextbuf}{{}exit}n{{}prevbuf}"{enter}{enact}" main


The first macro consumes an anchor each time it is called and saves the linenumber in ~/.local/share/nano/anchors. (when it's finished and there are no more anchors to consume it should be obvious because it will go to the top of the file and stay there)

The second macro relies on enact and the shell's while loop, to build up a stringmacro that restores all anchors. As a bonus, activating the macro a second time while anchors are present will remove them all from the session instead.

Tasos Papastylianou <tpapastylianou>
Mon 15 Jul 2024 10:20:23 AM UTC, comment #6: 

Hi Benno!

Here is a simple example which does not require an external script (or, use of the shell more generally). This is a simple implementation of the 'cycle' functionality you created in nano 8.1, implemented using enact instead (using your first version of enact patched over nano 8.0).

Requirements:
1. Ensure multibuffer is set to on in your nanorc
2. Create file ~/.local/share/nano/cycle with the following contents:

{prevbuf}{center}{nextbuf}{exit}{prevbuf}
{prevbuf}{center}{bottomrow}{center}{toprow}{scrolldown}{nextbuf}{exit}{prevbuf}
{prevbuf}{center}{toprow}{center}{bottomrow}{down}{nextbuf}{exit}{prevbuf}


3. Create the following keybinding in your nanorc

bind M-! "{insert}~/.local/share/nano/cycle{enter}{toprow}{cut}{bottomrow}{paste}{savefile}{enact}" main


To test it, go to any file (which is sufficiently long to demonstrate the functionality meaningfully) and press M-! to see the result.

The nanorc key-bound stringmacro simply shuffles the top line in the 'cycle' file and calls enact on it. Each line in 'cycle' file either centers, moves the line to the top of the viewport, or moves to the line to the bottom of the viewport accordingly (and performs some 'cleanup' afterwards).

Albeit a somewhat simple example, since you saw fit to hardcode this functionality in nano itself, I'm hoping the above example qualifies as a useful one :)

Tasos Papastylianou <tpapastylianou>
Sun 14 Jul 2024 09:01:37 AM UTC, comment #5: 

Hi Tasos,

I lack the imagination to see how a string bind that does not invoke an external script could make fruitful use of {enact}.  If you can conjure up an example of such a string bind, one that does something obviously useful, then it could be a candidate for inclusion in sample.nanorc, to showcase the power of {enact}.

But as I lack that imagination, I still think fruitful uses of {enact} require an external script, and as implied before, such scripts open the door to a whole new class of possibilities -- read: attack surface, because people are less likely to inspect such a (largish) script than a plain string bind.

So... let's see if you can come up with a compelling example.

Benno Schulenberg <bens>
Group administrator
Sat 13 Jul 2024 01:46:41 PM UTC, comment #4: 

Hi Benno! Sorry for yet another long email; however I wanted to address all your important points appropriately (and you made quite a few!) and in a timely manner (especially since I see you've already released a new version of nano in the meantime!) :)

> it would be nice if nano were able to execute a string bind that is assembled "on the fly" -- that is: without having to close nano, edit nanorc, and restart nano


A nitpick, but this is the lesser benefit of enact. The more important ones are 1) it finally enables otherwise trivial macros, that were previously frustratingly impossible due to the need to restart and lose state, and 2) it enables external scripts to trigger keystrokes within nano and more generally interact with nano's state, whereas at the moment external scripts can only interact with the text content.

As a trivial example demonstrating this, suppose you've saved an interactive macro, and want to have a way of repeating it N times, for arbitrary N. Enact makes this trivial, by creating either a keybound string macro or an external script which takes N as input and dumps {runmacro} N times in a new buffer, and then enacts it (with appropriate buffer-movements appended/prepended to the macro to ensure the action takes place at the right buffer and cleans up after itself).

> Enactment of a buffer line, however, requires an external script in order to be useful


Not necessarily. See example above.

> Such a script could sneakily do more things than advertised.  Of course, users can also now download scripts [...] but when {enact} is implemented, then users of nano could become a specific target. I don't like that idea. So... I am sliding into the direction of Wontfix.


As a possible compromise, rather than wontfix, may I suggest you make this a feature which is optional at compilation (e.g. via an ifdef). Therefore if you're worried about casual / "noob" users of nano not being aware of risks of downloading and executing scripts off the internet (whether enacted or otherwise), then you can at least ensure that the user who is using this feature was sufficiently advanced to be aware of the dangers and explicitly have to enable it at compilation time. Having said that, I think the worry is probably a bit overstated; I don't see why downloading an obscure macro from the internet with the intent of running it locally should be so much more dangerous when used with enact compared to when simply imported into one's nanorc file. If anything, I could make the opposite argument: since enact only takes the top line into consideration during execution, enact-intended files could come with an explanation in the lines below, that the user could easily inspect for correctness before actually running the macro; also, unless they go out of their way to bind such an external macro to their nanorc directly, loading and enacting a macro is safer, because the user gets to 'see' what they're about to enact first. Whereas a nanorc imported macro may well simply be dumped in the file externally, without a passive opportunity for the user to inspect the contents. And finally, obscure macros downloaded from the internet is probably a secondary scenario anyway; the most likely primary scenario is that users will be able to use their own scripts to more easily customise their nano experience, in a manner that previously was not possible (except with ugly hacks like mine!).

> Attached patch also includes an infinite-loop protection: refusing to execute a line that itself contains an {enact}.


My personal view is that this is unnecessary (and also possibly harmful), since the presence of a second 'enact' in the top line doesn't necessarily imply an infinite loop, and could in fact be a useful mechanism for building more elaborate/recursive/multibuffer macros (e.g. performing the same action until some base case is met in nano's state). I am still of the opinion that macros should be 'as dumb as possible' and simply execute a sequence of instructions without too many checks. This makes them more flexible. Caveat emptor.

> Attached patch implements {enact} in a slightly different manner: it now executes the current line instead of the first line


After some thought, I believe this would not be desirable, and would prefer enacting the top line always, as in your previous version. This versatility comes at the cost of predictability, and one could always trivially copy the current line to a new buffer before enacting it if desired. Otherwise the current line may be different every time you open the file, and would also make it harder to 'document' saved macros intended for enactment.

> About {enact} discarding the current contents of the keystroke buffer...  I don't see that as a problem [...] I would expect [a macro] it to clean up after itself.


You're right. Agreed. It's unnecessary overhead, and one could always design their keybound string macro so as to build up the full macro intended for enactment, complete with necessary prepends and appends, before calling 'enact'. In retrospect, the clearing of the keystroke buffer is probably a desirable property here.

However, I would repeat here what I stated above: I would honour the ability to make a secondary call to 'enact' from within a 'primary' macro string that is to be enacted - but this would necessarily have to come at the end of the primary macro, since the keystroke buffer is expected to be cleared at the point of digesting the second 'enact'. This makes things much simpler, and does not require keeping track of stacks etc. I think your previous version of enact already does this, so in that sense it was already perfect.

> [You] do not give an actual, worked-out simple example of something obviously useful. The first two examples are rather vague, the third one (saving and restoring anchors) is not very interesting to me, but the fourth...  If it were possible to construct line folding with the help of {enact} and an external script, that would be awesome.


I'm happy to do this, but in the spirit of not delaying the above response and risking you closing this ticket due to inactivity before I have demonstrated a fully-fleshed use-case, I will post this reply in the meantime, and try to write such an example soon. However, I'm guessing this isn't the most powerful example of enact anyway, since conceivably one could find a way to do this entirely via a script as well (as opposed to, say, the 'repeat' functionality mentioned above). Enact could make the implementation a lot simpler, obviously, but for an end-user it wouldn't really matter; so this arguably isn't the most compelling demonstration of its power / need.

Tasos Papastylianou <tpapastylianou>
Sat 22 Jun 2024 09:27:45 AM UTC, comment #3: 

Regarding the security considerations:

Also currently it is possible for a string bind to modify a nanorc file and thus itself, but it requires a restart of nano for this to have an effect.  Allowing on-the-fly enactment of a buffer line, however, while nano is running, brings string binds to a whole new level: far more powerful and dangerous.

The static string binds in a nanorc file could employ an external script but are mostly simple uses of 'sed' or 'grep' or 'xsel' or something similar.  Enactment of a buffer line, however, requires an external script in order to be useful, and such a script could sneakily do more things than what is advertised.  Of course, users can also now download scripts from the internet and run them without fully checking them, but when {enact} is implemented, then users of nano could become a specific target.  I don't like that idea.

So... I am sliding into the direction of Wontfix.

Benno Schulenberg <bens>
Group administrator
Fri 21 Jun 2024 02:37:56 PM UTC, comment #2: 

Hello Tasos,

Thanks for filing this request.  It is clear that, in theory, it would be nice if nano were able to execute a string bind that is assembled "on the fly" -- that is: without having to close nano, edit nanorc, and restart nano.  You describe some possible use cases for this feature, but... do not give an actual, worked-out simple example of something obviously useful.  The first two examples are rather vague, the third one (saving and restoring anchors) is not very interesting to me, but the fourth...  If it were possible to construct line folding with the help of {enact} and an external script, that would be awesome.

About {enact} discarding the current contents of the keystroke buffer...  I don't see that as a problem: if a string macro starts with "{prevbuf}", I would expect it to end with "{nextbuf}{exit}N".  In other words: I would expect it to clean up after itself.

(But things could be made so that {enact} appends the current contents of the keystroke buffer after the ingested string macro, I just think that this is not necessary.  If you can give an example of something that can't be done without this appending behaviour, then I can add the appending code, but it would be ugly.)

Attached patch implements {enact} in a slightly different manner than the earlier patch: it now executes the current line in the current buffer, which normally (in a newly opened buffer) will be the first line, but if 'positionlog' is in effect, it could be a different line, the line that was used the previous time.  I suspect that this is more versatile.

Attached patch also includes an infinite-loop protection: refusing to execute a line that itself contains an {enact}.

(The patch is against current git, but applies fine to 8.0.)


(file #56178)

Benno Schulenberg <bens>
Group administrator
Wed 19 Jun 2024 08:52:45 PM UTC, comment #1: 

Just an addendum to the below: if the {enact} bracefunction is to be used in the context of a different macro, then the desired effect would be for the {enact} instruction in the original macro to be replaced by the enacted string macro instructions, leaving the rest of the original macro intact.

I believe the current implementation instead simply discards the rest of the original macro if an enact has been encountered.

E.g. if you had

bind M-! "{nextbuf}{enact}{nextbuf}{exit}n" main

And the next buffer contained the string macro

{prevbuf}{replace}Hello{enter}Greetings{enter}a

Then pressing M-! should result in the following sequence being executed:

{nextbuf}{prevbuf}{replace}Hello{enter}Greetings{enter}a{nextbuf}{exit}n

Whereas I think the current implementation of enact that you provided in the previous patch would only result in

{nextbuf}{prevbuf}{replace}Hello{enter}Greetings{enter}a

being executed instead, effectively clearing any operations from the original M-! macro following the call to {enact}.

Tasos Papastylianou <tpapastylianou>
Wed 19 Jun 2024 07:20:19 PM UTC, original submission:  

This issue was already discussed in bug #65741; creating a new issue here stating the case for it a bit better, as requested. Apologies in advance that this is a bit long!

Terminology
I would like to define relevant terminology first, at least as used in the context of this issue, so that we're on the same page.

  • Macro (more generally): A sequence of operations that can be 'replayed' in the context of a live nano session. 'Replaying' here means to execute each operation (i.e. keystroke or function) represented in the macro sequence, in order of appearance.
  • Interactive macro: A sequence of keystrokes (corresponding to either literal or control-code characters), which can be 'recorded' interactively within a nano session. Recording is invoked via the {recordmacro} command (typically bound to the 'M-:' keystroke in nanorc). Replaying the recorded macro can then be invoked via the {runmacro} command (typically bound to the 'M-;' keystroke in nanorc).
  • Bracefunction: A string token consisting of a valid nano function name surrounded by braces. Used in string macros.
  • String macro: A one-liner string, consisting of a sequence of literal characters, control-code characters, or bracefunction tokens. String macros can be replayed by either binding the macro to a valid keystroke within nanorc first, or by invoking the {enact} function during a live nano session (which is the proposal of this ticket).
  • Keybinding: The assignment of a single function or of a string macro to a particular keystroke (acting in the context of a particular menu). When binding string macros to keystrokes in nanorc, the macro definition is surrounded by double quotes.


Rationale for request
Currently there is no way to replay an externally defined string macro, other than by creating a keybinding for it in nanorc first.

If one has access to such an externally defined string macro, and wants to use it in a live nano session, the only solution is to close nano, bind it to an empty keystroke in nanorc, relaunch nano, and then use the newly defined keystroke. Beyond the fact that this process is a bit tedious, it can also be problematic for a number of reasons; e.g. this would also require closing all open buffers, losing all 'undo' history, anchors, etc. Furthermore, if one wishes to use a non-trivial library of macros, it might be infeasible to assign a large number of keystrokes to these (or expect one to perform a "close nano -> edit nanorc -> close nanorc -> open nano -> use new keystroke" loop every time). Even if one decides to retain those keystrokes, it pollutes the user's nanorc needlessly, for macros which may only be required infrequently.

It would be desirable to have a mechanism by which one can effectively 'load' a predefined string macro into a live nano session (possibly even edit it a little bit first), and then 'replay' it.

You already created an implementation of this, as per our previous discussion, which simply executes the topmost line of the current buffer as a string macro. I was initially a bit skeptical of that approach, as it felt a bit 'hackier' than I envisioned. However, having tried it and given it some thought, I now believe this is indeed the most versatile approach, and I would be keen for this to be the form of {enact} applied to nano. The reason for this is that, I think this is the most macro-friendly / hackable implementation, which does not require having to detect and deal with special cases or state. The only downside is that, in practice, the most common way that this would be used would probably be by first opening a file containing the macro definition in a new buffer, and then executing the macro from within the new buffer; this leaves the onus of having to issue appropriate {prevbuf} or {cut} operations that precede the main logic of the macro, within the macro definition itself, but I believe this is more than acceptable. Otherwise, the alternative would require knowing explicitly whether you intend to run a macro currently in the cutbuffer, vs a selection, vs in a file, vs the result of a command execution, etc, which are all steps that can be part of a separate keybinding in the first place, if that is really desired. E.g., you had suggested as alternatives possibly executing the current cutbuffer or marked region instead. These would be problematic, since the macro may well need to make use of the current cutbuffer or marked region in the first place. Executing the top line of a newly opened buffer (where the macro itself issues a {prevbuf} command and then continues with the main logic of the macro on the intended buffer) bypasses all these problems.

Use cases

  • A string macro could be the output of a command run via the execute menu, which decides the correct macro to produce for the live nano session, based on the current buffer's contents. This could be used, for instance, to conditionally produce a different string macro, depending on a selection, or depending on the success or failure of a previous macro.
  • Given an external script whose output repeats its input N times, create a string macro that invokes the most recently recorded interactive macro N times, or only replaces the first/last N entries, etc.
  • Create a simple macro that 'saves' current anchor positions in the form of an enactable string macro; enacting that string macro from a later session can restore those anchors into the new session (this is currently an open ticket at the time of speaking).
  • Ability to temporarily fold lines: given a macro that replaces a range of lines with a predefined marker (while also saving the contents in a temporary location), then a separate macro could reload those contents and restore the folded lines via enactment, as long as the cursor is currently on such a folded location. (currently an open ticket in nano; granted, this would change line numbers if toggled on)

etc.

Security considerations

> But I think this is madness: a security nighmare, where nano is Turing complete and can do anything.  :|

I agree that, at first glance, this "feels" like it might introduce security concerns; upon closer inspection I believe it does not pose any further security risk than what is already present in nano. Consider the following scenarios:

  • A user downloads a compromised macro from the internet, and 'enacts' it:  this is no more risky than a user downloading a compromised string macro from the internet, and assigning it to a keystroke in nanorc directly.
  • A user downloads an executable which when run is intended to produce a macro for enactment, but running it actually infects the system:   this is no more risky than a user downloading an executable unrelated to macro enactments, and running it (within or outside of nano) which then directly compromises the system.

Perhaps I'm missing something, but I can't think of any more elaborate scenarios where the ability to enact string macros could pose a further security risk that isn't already an existing security consideration in nano (and where equally deliberate actions would be required before resulting in system compromise).



That is all, sorry for the long ticket report, and thank you for considering this.
T.

Tasos Papastylianou <tpapastylianou>

 

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Updated the item)
  • -email is unavailable- added by tpapastylianou (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.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-07-31 bens Open/ClosedOpen Closed
    2024-07-23 bens StatusNone Wontfix
    2024-06-21 bens Attached File- Added 0001-possible-new-feature-enact-executes-the-current-line.patch, #56178
        Severity3 - Normal 1 - Wish
        SummaryAbility to 'enact' predefined string macros [Wish] the ability to 'enact' predefined string macros

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code