Re: patch for new feature: placeholders in execute command

Luca Coraggio <[email protected]> Tue, 18 Nov 2025 12:18:32 +0100
Newsgroups gmane.editors.nano.devel
Message-ID <[email protected]>
Op 18/11/2025 11:14, Benno Schulenberg wrote:
> Oh. Unfortunately nano has just one cutbuffer, so passing two parameters
> (the filename and the highlighted word) to the external script will need
> some creative gluing.  For example (all on one line):
>
>   bind Sh-M-M "{copy}{writeout}==={paste}{copy}{cancel}{execute}
>        yourscript.sh {paste}{enter}" main
>
> Then yourscript.sh will have to separate the filename (before the ===)
> from the highlighted word (after the ===), deduce the filetype from the
> filename, and then invoke the appropriate doc reader with the extracted
> word as a parameter...  Quite some scripting.  :| 

Indeed, what I typically do is to pipe the highlighted text to the 
script and let it handle the pipe;
but I am not sure now if this can be easily combined with the 
"{writeout}" trick.
What I would do with the patch would be something like

   bind Sh-M-M "{nextword}{mark}{prevword}{execute}| nano-doc \FTYPE 
{enter}{undo}" main

where nano-doc is the script that handles the pipe and invokes the 
correct document
program according to FTYPE.

Another application I was mentioning: I use tmux to let nano interact 
with REPL consoles. Essentially,
tmux continuously listens to buffer (fifo file) and nano writes to it on 
a shortcut press. The binding I use is
something like

   bind Sh-M-e "{execute}|tmux-listen-ide 1{enter}{undo}" main

I highlight the text I need to run and via the binding I send it to the 
script tmux-listen-ide which handles it.
Currently, I am not able to distinguish between filetypes so I can not 
have the script to parse differently the chunk of
codes I send. For example, when I use this with python, additional 
new-tabs are inserted at every new line and python
(rightfully) complains. This works flawlessly if I send the code to 
bash, for example. Were I able to distinguish the file type,
I would add a sed line to the tmux-listen-ide to remove unnecessary tabs 
only when I have python code and the binding
would be

   bind Sh-M-e "{execute}|tmux-listen-ide 1 \FTYPE{enter}{undo}" main

Sometimes I also need external scripts to read or search the content of 
the current file for doing some actions, so that
something like

   bind Sh-M-M "{execute} | script $(pwd)\FNAME" main

would be useful. For example, I may need to search for included 
libraries in python or C to grep
the correct documentation.

> How many different
> documentation readers (besides `pydoc` and `man`) do you use that this
> is worth the effort? 

I actively work in C, Python, tex (LaTeX), and I typically use man, 
pydoc and texdoc (even though this last one I use occasionally).
I also actively work in R (so I use Rscript for doc), even though I 
understand it is not worth to mention it for nano. But I think this
is applicable also to other languages that are supported by nano and 
have cli documentation programs.
To me it is worth the effort (so worth in fact that I even tried to 
write a patch), because I find it extremely convenient to
be able to interact quickly and the way I want with the text/code I am 
handling. I find it impractical to resort to web-browsers
when I have the doc locally, and I find it more convenient not to have 
to manually spawning and copy-pasting a new terminal
or copy-pasting to a REPL.

I understand that nano is not meant for this, but it is extremely 
effective at doing this. Whenever you have to interact with
the shell, nano is extremely convenient (arguably, even more than vim). 
It plays well with modular workflows: nano handles the text
only and external script handles the rest. In fact, I use external shell 
scripts/filters for a lot of stuff, and I think other users do.
Exposing the filetype or filename (which nano already knows about) would 
make this much more convenient in some cases.
I will try to integrate your "{writeout}"  suggestion for my use cases, 
but I am not sure it will always fit. So I think I will
continue to have this patch for other corner-cases.

If in light of this you think other users may benefit, I may try to 
rewrite the patch as you suggest, for example I may try
to shorten it (using only one pass as you suggested) and/or restricting 
it to actually useful information
(e.g. \CWD can be easily substituted with $(pwd)).


Thank you,
Luca