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