Let nlay-config be either shipped with .def suffix or don't overwrite it on update (checksum)

[Anachron]

Like the title says.

https://www.reddit.com/r/opensource/comments/6arvoq/nnn_v11_the_missing_terminal_file_browser_for_x/dhhzncf/

[jarun]

I see now I left a MUST READ section above nlay which a user changing the file cannot overlook. One of the lines in it is:

Keep a personal backup (on GitHub Gist maybe?) of this file if you modify it. nlay is OVERWRITTEN during nnn upgrade.

The ask is very straight and blunt - if you are a power user, you handle this yourself.

There are several things to consider:

• overwrite is obviously not desirable
• handling checksums in GNU make is not straightforward
• it's simpler to have a single copy but we can't merge all complex combinations
• if we can't checksum, in every installation we are going to install the new nlay as a backup if the older nlay exists. Regular uses would never notice and miss new stuff in nlay. nnn might break when working with older nlay (hence, I gave higher priority on having stuff working for regular users, not the ones who can actually edit a shell script, however easy it is)
• backing up the older file as a .bak doesn't make sense aesthetically either because nlay is not a config file but an executable script. However, I think this is the sanest approach.

Opinion?

[jarun]

@shaggytwodope @szlin any thoughts on this?

[professorjamesmoriarty]

@jarun one method would be to "have our cake and eat it too". In the sense of providing nlay as a default. And possibly something to the effect of ~/.config/nnn/nlay_user (poor naming choice aside lol). Allowing the created file to take priority over nlay that ships by default (and maybe a fallback should an error occur in users nlay?). This would leave alot of freedom for the user. Just need to be made clear at some stage no support is offered for user edited version.

This would however need to change in how nlay is currently used. What ranger does is it copies the script scope.sh among other items from /usr/share/ranger/* to ~/.config/ranger/* when you run a --flag to begin customizing said config. While this does begin to complicate things to a degree, it's the only thing that comes to mind currently.

[jarun]

How about an option to use a custom player (nlay)? E.g.

-p /path/to/modified/nlay
?

[professorjamesmoriarty]

@jarun I very much like this idea. For one it makes things far far simpler. Permits "power" users to setup things with ease avoiding any funky overwriting issues. I'd suggest making a note somewhere about being able to set a bash alias alias mynnn="nnn -p /path/mystuff/nlay".

This makes things very simple as I see it. Just need to make a few notes for users on best practices and use cases. It could be considered to create a modified nlay example and ship in /usr/share/nnn/.

[jarun]

I very much like this idea

Your comment triggered this. I'm fuzzy. In bed the last 3 days because of fever. So thanks! 👍

It could be considered to create a modified nlay example and ship in

We'll ship nlay as it is today because we need the player in vanilla state. -p would override it. ;)

[szlin]

Option solution is great; moreover, I think we can also consider to use configuration file such as /etc/nnn/nnn.conf and thus to solve this issue.

[jarun]

@szlin I would avoid reading a file from disk every time we start (as looong as possible) using options and env variables. Apart from the tiny delay ;), it also leads to the same issues for nlay upgrade we are discussing now.

[szlin]

@jarun Indeed, I/O operation always gets slow; however, the power user can set their own custom player path in nnn.conf such as nlay_path=/path/to/modified/nlay to overwrite original one.

This is what I thought and I think it can solve nplay upgrade issue - or did i misunderstand something?

Both option and conf can achieve the goal and choose one of them is enough I think :p

[jarun]

Yes, we would have that too! ;)
An alias as @shaggytwodope mentioned:

alias mynnn="nnn -p /path/mystuff/nlay"

[szlin]

Alias and conf. file are different meanings to me, maybe I am used to conf. way with Debian packaging :D

ref: https://wiki.debian.org/ConfigPackages

[jarun]

Got it now!!! I'll bank on the alias for this case though. :)