walles
Provide custom display name for stdin stream
Obviously, when the input to moar is being passed by stdin, moar doesn't have access to its filename or path to display on the status bar. In some cases however, such a name could be available to whatever's calling moar. This could be passed as an optional flag. Aside from this usecase, it could also potentially be used just to override the displayed file name with a custom string that might not actually be a valid path, such as a more user friendly name or a URL, in which case this feature could be used even when the input is a file in the command line arguments.
A potential issue would probably be for the feature to open the current file in an editor, which appears to use the original file rather than moar's internal buffer. If this is the case, then the displayed filename and the stored path for reopening in an editor would need to be stored separately.
My personal use case for this would be nushell's source metadata value saying where the currently used data came from, even if the data itself has been modified during a pipeline in some way. Not a very significant or important feature, but just a small quality of life change.
Minor update, I managed to forget that I was using moar with piped in input. Moar doesn't support the particular syntax it uses, so I was using an external tool to highlight the syntax before it got to moar, but then pressing v to edit it opened the stream, complete with formatting commands, in my editor rather than the original file. So being able to use a separately passed-in file name to change what file gets opened in an editor would be desirable.
Moar doesn't support the particular syntax it uses
What was the syntax of this file?
Moar doesn't support the particular syntax it uses
What was the syntax of this file?
Nushell. It happens to include a built-in command specifically for highlighting its own source code, so I was using that before piping the file into moar.
e1ee92fb791b88d974493a7d2ab5cc85ef2375f8 introduces Nushell highlighting.
Also, 4abc99f465ef708af5c95e644dd4d6625d438742 makes moar pass not-highlighted data to editors on v.
Are these two together enough to close this ticket @boomshroom?
That seems like it would help with the specific use-case I had, and sanitizing the text before sending it to an editor would be a better solution for the follow-up I had.
I'd still see the feature described in the title as valuable even if it'd just be cosmetic. There are more reasons than just using an external highlighter to pipe a file through stdin rather than passing it as a path, while still having a name that can be used to label it in the UI. For example: piping a file from curl while showing the original filename on the status bar without saving it in the filesystem.
Edit: So essentially, a flag that that takes a string to override the constant "" in https://github.com/walles/moar/blob/65ca4d02eeeafd7aaf62f1a8d87da8f67a440997/moar.go#L497 and that would be it. Probably the only other thing would be to maybe override "moar-contents-" in https://github.com/walles/moar/blob/65ca4d02eeeafd7aaf62f1a8d87da8f67a440997/m/editor.go#L18 with the same value.
This release should cover your specific use-case: https://github.com/walles/moar/releases/tag/v1.32.6
As for the remaining part, how much do you believe it would actually be used in practice? By people in general?
It would most likely only be used in scripts. My use-case was using moar in nushell's display hook, so anything that gets printed to the screen ends up piped through moar. Nushell also has a metadata feature that can record the origin of the current stream which can be accessed in said display hook.
This feature would not be useful for anyone not writing their own scripts that call moar automatically. It is also purely cosmetic, so it would be low priority anyways. (I could probably just make a local patch for my package manager to apply at build time rather than trying to get it upstream.)
I have another use-case.
Looking at a set of files.
Less can do less <glob> moar can only take one file. less shows the file name in its status line.
To get the same with moar I use bat and it passes each file in. I would like to know what file I am looking at.
Under what circumstances do you want to view more than one file?
I would like to understand the use case.
Or maybe continue this conversation in #248?
Many I often do
less *.h to look at all the headers - or more usually a more complext glob that recurses.
Of if I have piped errors stdout and stdrr to separate files - I want to look at all so less err.*
moor *.h is now supported in this release (just out):
https://github.com/walles/moor/releases/tag/v2.3.0
I will close this ticket now, feel free to open others as needed.
Since 15ab0bd9147c5bafed6edf5e2f97e65013dcf76f moor will now read the PAGER_LABEL environment variable and use that to label stdin.
@walles can you help me to know what PAGER_LABEL values i can set for this ENV
