[request] prompt expansion to line content

[avih]

Prompt string %bX and several others expand to line/page/percentage/etc of the top/mid/bot/target line, depending on X.

This is a request to do the same as far as identifying the line, but expand to the actual line content.

This can be useful with external commands which can perform some action depending on the line content, like extracting a git hash from the line, and running git show HASH, etc.

I expect it would be most useful with external commands rather than in an actual "less" prompt, so it likely needs to be shell-quoted.

It might be debatable whether the value should be the displayed value (for instance with some binary escaped) or the actual input line content, whether it should be the full line or only the visible part (in case it's cropped or wrapped to the next page).

I think the simplest and probably most useful is the full original unmodified input line, including binaries and parts of it which are not on-screen, if any.

One exception to "full original line" might be byte value 0 - which will likely cause issues on many platforms if it appears at the middle of an argument, but it's not obvious to me what to do with 0 byte in such case (removing it is an option, but it feels meh). Or maybe replace byte 0 with newline? (because a single line doesn't include newlines by definition, so there's no ambiguity).

Off topic, but it could also be used to test shell quoting of arbitrary values using an input file which was crafted for such test, probably including 0 byte too.

EDIT: it's possible to do that with line number and the original file name (so that the external command can extract that line from the file on its own), but that wouldn't work for content from stdin.

EDIT2: another option instead of expanding it to a line-content argument is to send the line to an external command's stdin (maybe with other arguments, which could also be other prompt expansions). In such case it can include 0 bytes, and it's up to the external utility to handle it as it sees fit. That would not allow testing shell-quoting though, but it's not the goal of this feature to begin with.

[gwsw]

This seems rather similar to the | (pipe) command. What are you looking for that can't be done by marking a line and piping it via the | command?

[avih]

This seems rather similar to the | (pipe) command.

I wasn't aware of |, and it does seem similar, thanks.

Although I think that if I want a single line, then the marked line has to be the top line? (I guess I could live with that)

What are you looking for that can't be done by marking a line and piping it via the | command?

I guess. I've maybe played once with executing something from "less", but largely I don't have experience with it (I've now read the related docs, but didn't really try it out).

Is mouse double click supported? for instance binding it to marking the line and then invoke the | command?

If it isn't (which I think is the case - I didn't find it at the docs), can a binding to left-click do "if the clicked line is not already marked with the mouse, then mark it (the normal default left-click behavior), else (it is already mouse-marked) invoke | on the mouse mark" ? (kinda simulating the above double-click behavior)

[avih]

can a binding to left-click do "if the clicked line is not already marked with the mouse, then mark it (the normal default left-click behavior), else (it is already mouse-marked) invoke | on the mouse mark"

That makes me think whether there's room for some actual programmable logic in "less", for instance using lua or javascript.

I think there is logic in conditional prompt expansions, but I think ultimately there's limit to what can be expressed or be done with those. For instance it's probably not possible to do what I asked in this quote, or maybe it might, but it would be very awkward and might require some extension (like new prompt thing which expands to "is this line mouse-marked?" and derivative conditional commands). Maybe not impossible, but also not turing-complete.

In mpv we have lua and js scripting support (I added the js support, but I also worked on the lua integration and very familiar with it), where a script can bind key presses and other mpv "events" (like new file loaded), execute mpv commands (similar to "less" commands), and read (and sometimes also modify) mpv "properties" (mpv state values exposed as meta-variables to scripts - like the current time-position of the playback, whether it's paused, etc), and it's been an extremely popular way to extend mpv with new functionalities which the basic player doesn't have (and sometimes inspired mpv to add these features as builtins).

Check out this page of 3rd party scripts and other mpv extensions, which users share at the mpv wiki https://github.com/mpv-player/mpv/wiki/User-Scripts (personally I have dozens of js scripts which customize mpv to my liking. I only shared few of them on that wiki page, and some others there were inspired by my scripts).

Any thoughts about something like this? (for instance Lua support).

[gwsw]

I don't think there's any easy way to bind a mouse click to an arbitrary command. Nor is there any existing mechanism whereby the clicked line number could be passed to the bound command. You could easily create a command that pipes the first line on the screen to a shell command, but you'd have to move the line to the top of the screen manually.

I don't know about adding lua support. It seems overkill to handle this one particular case; I would like to see a lot of other examples of how it could be useful before I'd consider such a massive new feature. I think it would approximately double the amount of code in less, not even counting whatever glue logic that would need to be written to allow lua code to access less features.

[avih]

You could easily create a command that pipes the first line on the screen to a shell command, but you'd have to move the line to the top of the screen manually.

Yup, as suggested:

Although I think that if I want a single line, then the marked line has to be the top line?

As for:

I don't know about adding lua support. It seems overkill to handle this one particular case

Of course. It's an overkill for any single particular case.

The goal of such feature is to open the door for actual programmable customization. As noted, it proved extremely popular elsewhere (mpv, but not only - there are other tools which support programmable extention using lua or other scripting languages).

"less" already puts a LOT of effort into customizability. I'd guess (without trying to confirm it) that already a very considerable percentage of the code in less is related to configurable behavior. All the env vars, commands, bindings, prompt expansions, etc - all have the goal of allowing users to "program" it to fit their needs, but using different ad-hoc mechanisms and methods.

It certainly works (up to the allowed extent - e.g. the mouse line thing), but arguably maybe not very easy to learn or use.

Since I do have a lot of experience with such extensibility in mpv, I'm estimating that such integration could be potentially very clean, in the sense that it would come down to single or very few places at the code which "hook" into a script, rather than having tendrils all over the place (which I think the current customizable behavior has).

But that's an estimation, and I'm not familiar enough with the code in "less" to know that for a fact.

Of course, some scripting VM setup and integration would be needed, which might mean one or two more files, but that should be largely independent code without impact on actual "less" code, except through the aforementioned "hooks".

And obviously, such scripting support should be optional.

I might try to play with it some day, but no concrete plans currently.

Anyway, it was more musing and RFC than actual suggestion.

Thanks.

[gwsw]

Apart from the question of adding a scripting language to less, which should probably be a separate issue, is there anything more that is actionable in this issue, or is the | command sufficient?

[avih]

is the | command sufficient?

Might be usable, but I think it's not convenient.

Ultimately my goal with this was to pick a line with the mouse and send this line to an external command. My idea was some prompt expansion to the quoted line content to be used by some command, but I'm open to others.

If | could take # argument for mouse-mark, then that's a good start (didn't try it out).

But the fact that it sends several lines rather than one, and different lines depending on $things, makes it more complex than necessary to deal with.

Does | take mouse-mark as argument?

Does it support sending just the marked line?
If not, do you think it's a reasonable feature request?

[gwsw]

Yes, | can take # as the marked line. If the # line is at the top of the screen, just that one line will be piped to the shell command. The command 1'x will move the line marked with x to the top of the screen, so you could click the line to mark it, then issue the command 1'#|# followed by a shell command. I think that does what you want. If you bind the command to a key, say X, you would just need to click the line and then type X.

[avih]

Yes, | can take # as the marked line.

Thanks. Wasn't sure it would. Maybe consider changing

       | <m> shell-command
              <m> represents any mark letter. ...

to "any mark character".

The command 1'x will move the line marked with x to the top of the screen, so you could click the line to mark it, then issue the command 1'#|# followed by a shell command. I think that does what you want.

Seems like it does. Thanks. It still moves the line to the top, but that's not a huge issue.

I still think that being able to use the | command with just the marked line (without having to move it to top first), could be useful, because afterall, that IS the marked line, and any range which it implies is.. well.. implicit. The user marks one line, and it feels logical to me that they should be able to use it on its own.

But the core reason I wanted it is largely addressed using the | command, and it's reasonably appropriate to send the line to stdin rather than as argument.

[gwsw]

It still moves the line to the top, but that's not a huge issue.

You could append '# after the shell command to return the marked line to its original position. (Note that I just fixed a bug related to this, so you would need 48b4bc6 or later for this to work.)

The | command pipes a range of lines in the general case, so there are two lines involved, the starting and ending line. To avoid explicitly specifying both, it assumes that one side of the range is the top screen line and the other side is the marked line. It seems reasonable that someone might want to pipe a paragraph by putting the top of the paragraph at the top of the screen, then click on the end of the paragraph and use |# to pipe the whole paragraph. If |# piped only the marked line, it's not clear how you could pipe a paragraph using the mouse.

[avih]

I just fixed a bug related to this,

Yeah, I noticed. I thought you just noticed it while helping me, but now I realized that without this issue it's possible to also "not move" the line (logically speaking).

To avoid explicitly specifying both, it assumes that one side of the range is the top screen line and the other side is the marked line

Yeah, the other side of the range is implicit.

It seems reasonable that someone might want to pipe a paragraph by putting the top of the paragraph at the top of the screen, then click on the end of the paragraph and use |# to pipe the whole paragraph

Sure, and I wasn't suggesting it's unreasonable or that it shouldn't be possible.

Just that it's also reasonable that in some cases the user wants to use JUST the marked line.

[avih]

Just that it's also reasonable that in some cases the user wants to use JUST the marked line.

Syntax wise, maybe instead of |[X] it could be |[X[Y]] to specify a range, where X/Y can be either a mark or top/bottom of screen or top/bottom of file (assuming there are some "meta mark" character for those), etc, and then |## CMD ... would send just the marked line, but also allow more flexible range in general.

(I don't know if that syntax is good or if it conflicts/whatever, but you get the idea).

[gwsw]

Currently, typing the mark char immediately switches to input of the shell command, so something would have to change to be able to accept a second mark char. Requiring ENTER after the first mark letter seems unnecessarily incompatible. Maybe a new command letter different from | that takes two mark chars? Or maybe typing a second | in place of the mark would switch to a different mode that accepts two mark chars?

[avih]

Both sound reasonable.

Or maybe |X... where X a char which is not reserved for [meta] marks, maybe - to indicate that what follows is a range, or some such. Maybe the - is also needed between the parts, and that would also allow range of line numbers... there are some possibilities.

Are there such "meta mark letters" for top/bottom of screen/file?

[gwsw]

Yes, ^ means first line in the file, and $ means last line in the file. There aren't metachars for first/last line on the screen.

Actually, . means "pipe the whole current screen". The way it's implemented, if used in conjunction with a second mark, it would mean "first line on the current screen".