Tracker
jarun opened this issue ยท 45 comments
Rolled from #1454.
Cooking
- create new file or directory (tree) on startup
- improve archive, rename and create new workflows
- optimize link creation
- allow overwriting regular files on new empty file creation
- add correct check for Wayland in clipboard plugins
Up for grabs
None open at the time.
Contribution guideline.
does the wiki says that without atool, pressing enter on an archive opens it with the opener, and with atool instead pressing enter will show options?
When atool is not available default opener is used. atool/bsdtar are optional.
When atool is not available default opener is used. atool/bsdtar are optional.
That's not the question.
The question is:
does the wiki says that without atool, pressing enter on an archive opens it with the opener, and with atool instead pressing enter will show options?
See https://github.com/jarun/nnn/wiki/Usage#dependencies
It's doesn't have to. The system default opener invokes a tool which nnn
is not aware of and can't know which options would be provided.
The opener only takes the file name/path.
The system default opener invokes a tool which nnn is not aware of and can't know which options would be provided.
I didn't say nnn should know which options the software called by the opener provides.
I said that the wiki (not the software) should say that, if you hover over a file with an extensions that matches NNN_ARCHIVE
,
- If
atool
is available, options to open/extract/mount the archive are provided - If
atool
is not available, the opener is called
It's doesn't have to
The wiki doesn't have to document the behavior of nnn
when an archive is hovered on? Even when that behavior changes on the basis of the software installed on the system?
Even when that behavior changes on the basis of the software installed on the system?
Exactly. When the optional tool is not present, the default behaviour is to call the opener. Otherwise, if nnn
shows the options and the user chooses an option, what would nnn
do?
Exactly. When the optional tool is not present, the default behaviour is to call the opener. Otherwise, if nnn shows the options and the user chooses an option, what would nnn do?
Carry the option chosen by the user?
I don't see how that answer my objection.
The objection is: the wiki should say that:
if you hover over a file with an extensions that matches NNN_ARCHIVE,
If optional atool is available, options to open/extract/mount the archive are provided
If atool is not available, the opener is called
Even if atool is optional, the wiki still should say that the behaviour changes when the optional atool
is available.
I didn't have atool installed. I hovered over an archive and pressed Enter. (I think) the opener was called on that file since it got opened in GNOME Archive.
Then I went to the wiki and looked on how to extract archives with nnn
and couldn't find exactly how (except that atool
is an optional dependency, but it doesn't say what happens when it is available).
Then I googled it and found this.
It said that by pressing Enter on the archive nnn
would have shown options. It didn't for me.
Since the poster said "I have atool", I guessed that the behavior would change with atool installed.
So I installed it and it did.
I think that this behavior should be documented, I should not had to google it (only look for it in the wiki) and I should not had to guess it.
This doesn't imply in any way shape or form that atool should be compulsory.
Otherwise, if nnn shows the options and the user chooses an option, what would nnn do?
I don't understand why you keep talking about the software. I'm talking about the wiki, not about the software.
Maybe under Basic use cases create a new section "Manage archives".
- A file whose extension matches one of the extensions provided in
NNN_ARCHIVE
is an archive. - If you hover over an archive and press Enter:
- If atool or bsdtar is available, options to 'o'pen/e'x'tract/'l's and 'm'ount the archive are provided
- If both of them are available, [atool/bstar] take precedence
- If neither of them are available,
nnn
will try to open the file withNNN_OPENER
It says very clearly in the Depedencies section that:
tar, (un)zip [bsdtar/atool/(un)rar for more formats]
And then in the Configuration section that:
3. With atool or bsdtar and (un)rar installed you can have:
export NNN_ARCHIVE="\\.(7z|a|ace|alz|arc|arj|bz|bz2|cab|cpio|deb|gz|jar|lha|lz|lzh|lzma|lzo|rar|rpm|rz|t7z|tar|tbz|tbz2|tgz|tlz|txz|tZ|tzo|war|xpi|xz|Z|zip)$"
Your problem is you have defined NNN_ARCHIVE
with more formats but didn't install any optional utility to handle it.
Even without atool
, if you have unzip
installed, pressing Enter on it would show the prompt. It's pretty basic:
If you do not have the utility to handle a specific archive type, the default opener will be invoked.
Your problem is you have defined NNN_ARCHIVE but didn't install any optional utility to handle it.
Yes, that's what I said here. I don't need additional troubleshooting :)
And then in the Configuration section that:
It says how to set NNN_ARCHIVE
if you have atool
or the others.
It doesn't say what happens if you have atool
and set the variable like that. So it's not clear at all why you should do that.
It is also misleading because in the Dependencies section you linked it says "for more formats (install) atool". So it looks like it is needed only if you want to support additional formats.
Instead no, the behavior changes and with that tool nnn
is able to extract/list/mount the archive without relying on the opener.
Even without atool, if you have unzip installed, pressing Enter on it would show the prompt. It's pretty basic:
That's undocumented as well. There is no unzip
not even in the Dependencies section you linked.
If you do not have the utility to handle a specific archive type, the default opener will be invoked.
That's what I said here and after that.
You continue to tell me what happens in various cases. I already figured that out by googling and by trial and error. I just would like for this to be written in the wiki.
That behavior is documented in the manpage as far as I can see:
NNN_ARCHIVE: archive extensions to be handled silently (default: bzip2, (g)zip, tar).
export NNN_ARCHIVE="\\.(7z|bz2|gz|tar|tgz|zip)$"
NOTE: Non-default formats may require a third-party utility.
calm down
Anyone know what binding triggers the behavior that when opening the file, the cursor moves to the next item? Really annoying I toggle that by accident but not sure what key to toggle it back so I need to restart the instance.
The program help shows with ?
. It's there:
^J Toggle auto-advance on open
- Switch to select only folders (hide files, pressing Enter on a folder select it)
- Switch to deactivate selection of multiple files/folders (can only select one file or folder)
- Switch to support a user-provided name for new files
- Switch to read a file (cannot create new files/folders) or create new file (will issue warning if you select an existing file)
Use case: use nnn as an xdg-desktop-portal file chooser through https://github.com/GermainZ/xdg-desktop-portal-termfilechooser
Check the picker mode. Option -p
.
- Folders are always on the top and clearly visible with customizable color. You can select the folders and press
Q
to exit. The selection will be printed. You can also use option-p
to print the selection to an output file. - Use the picker mode, select what you want and quit.
nnn
can't start with non-existent files. It's not vim. You can create a new file innnn
usingn
.- Open the file to read it. Creating a new file would fail if the file exists.
- I know about picker mode. I didn't know that you can select folders (i.e., pressing
Space
over them), and by quittingnnn
the selection will be written in the file provided by-p
. Since bothQ
andq
seems to work in this case, what is the difference between the two? I used to hover over a file and pressEnter
(with the-p
option, it will write the file path to that file) - It is still useful to know whether the website can accept multiple files or only one file is accepted
- But the browser is providing a "default" filename for the file to save, which is useful to have. I think we can have a switch that set the default filename in readline when you create a new file?
- Seems reasonable at the moment
I made a fork of xdg-desktop-portal-termfilechooser that allows a FileChooser portal with nnn
here
@raffaem how does it handle the workflow of browser suggesting the default filename for the file to save?
@raffaem how does it handle the workflow of browser suggesting the default filename for the file to save?
It separates the dir from the filename. The dir is opened in nnn, and the filename is copied to the system clipboard.
Awesome!
The way this is usually done, including the wiki example we already have, is to create an empty file with the suggested name which can be selected immediately.
The way this is usually done, including the wiki example we already have, is to create an empty file with the suggested name which can be selected immediately.
But then you have to manually delete the file if you want to save to another name.
And you are stuck with it if you forget to delete it.
Maybe have an option that pass the default name to readline?
Maybe have an option that pass the default name to readline?
The major problem is it percolates deep down and through several checks. And then there are the cases of overwrite, cancellation and so on. The current arrangement seems to be the best to me.
You can simply delete the suggested file if it is still empty when nnn closes (which is what the wiki example does).
You can simply delete the suggested file if it is still empty when nnn closes (which is what the wiki example does).
Oh, I see.
What if the folder has a lot of files? How do you find which file to select, if you want to save in the default position?
Pass the suggested file as argument to nnn and nnn will place the cursor there on startup.
Pass the suggested file as argument to nnn and nnn will place the cursor there on startup.
That makes sense.
Is this one the wiki entry you are referring to?
At commit 2a673b4 I have made a change to allow overwriting existing regular files on new file creation.
This may not help immediately but I am thinking of options to allow creation of non existent files on passing the option at startup.
See commit 56fd6ea for an implementation of creating a new file at startup.
Note that the parent directory, if passed, much exist and has to be accessible. Otherwise nnn
will quit.
I implemented it because I see a faster workflow where I can just nnn new.txt
and create and start using the file from within nnn
.
All right, I finished the work on my fork for now.
I implemented the suggested workflow (touching a new file on save and deleting it afterwards if it's empty).
Also my fork should now work out-of-the-box: just install it and change the configuration file.
See commit 56fd6ea for an implementation of creating a new file at startup.
Note that the parent directory, if passed, much exist and has to be accessible. Otherwise
nnn
will quit.I implemented it because I see a faster workflow where I can just
nnn new.txt
and create and start using the file from withinnnn
.
Thanks, I will take a look at it.
Lifted all restrictions at commit d4c3e52. nnn
will attempt to create non-existent directory trees, directory-only paths can also be created (more in the man page).
Following the latest commit, I have removed the creation of file from the wrapper and now I delegate all to nnn.
But there is something that makes me uncomfortable with this implementation.
-
What is the workflow in case I want to save the file in a different folder than the suggested one? I first save in the suggested one, and then move the file around?
-
When I put a path in front of the suggested file name (e.g. I'm in
~/Download
, the suggested file name isfile.pdf
, and I put../Documents/file.pdf
, and suppose that../Documents
doesn't exist), the full tree is effectively created if it doesn't exist, but then the file is not selected (i.e., the folder is not changed). Would it make sense to select the file also in this cases?
- It's optional to use. You can still use the older older technique:
It separates the dir from the filename. The dir is opened in nnn, and the filename is copied to the system clipboard.
Otherwise, you can pass the complete tree as well. nnn
will create the directories and prompt with the filename.
- I don't understand. On master, it prompts with the suggested filename and when you create it, the new file is selected.
Suppose neither ~/Documents/file.pdf
exist nor ~/Download/file.pdf
exist
Call nnn ~/Documents/file.pdf
. Remove all text, type ../Download/file.pdf
and press enter. nnn
will not switch to the folder, altough the file is created correctly.
Yes, that is the correct behaviour as of now. The file is being created in another directory. In a regular workflow, the user may not want to switch to the other directory yet, hence she didn't switch first and then create.
I will think more on this.
Yes, that is the correct behaviour as of now. The file is being created in another directory. In a regular workflow, the user may not want to switch to the other directory yet, hence she didn't switch first and then create.
I will think more on this.
But can you switch first if readline is waiting for the input?
If we can implement navigation while readline is waiting for user input that would be perfect
No we can't.
@raffaem I think your previous wrokflow is better - open the default and copy the filename to clipboard. I don't want to over-complicate things here.
@jarun How vigilant do we want to be with what is considered a dependency for plugins? The list is a bit inconsistent and I'm not exactly sure what should and shouldn't be considered a dependency.
Generally speaking, the base utilities installed by default OR which are well-known are left out.