jarun / nnn

n³ The unorthodox terminal file manager
BSD 2-Clause "Simplified" License
19.32k stars 762 forks source link

ToDo list #1416

Closed jarun closed 2 years ago

jarun commented 2 years ago

Rolled from #1348.

Cooking

Up for grabs

None open at the time.

For anything else please discuss in this thread.

Contribution guideline.

anjerukare commented 2 years ago

Is there option to not display "nnn is already running" when I opened shell in nnn, but to move me to that running nnn.

N-R-K commented 2 years ago

Is there option to not display "nnn is already running" when I opened shell in nnn, but to move me to that running nnn.

Yes, just replace it with exit.

    # Block nesting of nnn in subshells
    [ -n $NNNLVL ] && [ "${NNNLVL:-0}" -ge 1 ] && exit

Btw, I don't get the point of ${NNNLVL:-0} , we're already making sure it exists with -n $NNN_LVL. @jarun

anjerukare commented 2 years ago

Is there option to not display "nnn is already running" when I opened shell in nnn, but to move me to that running nnn.

Yes, just replace it with exit.

    # Block nesting of nnn in subshells
    [ -n $NNNLVL ] && [ "${NNNLVL:-0}" -ge 1 ] && exit

Thank you! I also added &> /dev/null after exit to hide output.

anjerukare commented 2 years ago

Why does mapping some action to Ctrl + I causes a key collision? I don't see any default mappings on Ctrl + I in nnn.h.

N-R-K commented 2 years ago

That's because Ctrl+I sends the TAB key on terminals. ^0

anjerukare commented 2 years ago

Final version of Colemak-DH key binding patches is done. colemak-dh-patches_final.tar.gz

Changes from previous version

Summary of changes

Key bindings
Navigation
Key binding Action
m Parent
n Down
e Up
i Open
Ctrl + E Top
Ctrl + N End

Files
Key binding Action
s Select range/clear
l Edit sel list
c Create new/link
y Edit file

Other
Key binding Action
h Connect remote
Ctrl + F Toggle type-to-nav
k Manage session
jarun commented 2 years ago

@luukvbaal please plan to add to the patch framework. Once you are done, I'll plan for the next release.

jarun commented 2 years ago

Btw, I don't get the point of ${NNNLVL:-0} , we're already making sure it exists with -n $NNN_LVL. @jarun

@N-R-K sorry I missed earlier. Yes, I think it's redundant.

jarun commented 2 years ago

@N-R-K please confirm commit f4f4e1a97b7539f5dcd21eb07c6284b6153b1c3f. This is the latest version.

vaygr commented 2 years ago

I can't find it mentioned anywhere, but due to better results output, is it possible to get fzy support back?

It was added in #505, then silently removed in 4832fc5 one month later. Any good reasoning against fzy?

jarun commented 2 years ago

Any good reasoning against fzy?

It's a dead tool - https://github.com/jhawthorn/fzy/issues/135

vaygr commented 2 years ago

I'm not sure a couple of feature requests not addressed within a few months is enough to mark it dead. I, for instance, have software that was updated more than 15 years ago, but it still works as expected and is unlikely to get any more updates. Another good example is bspwm, which is pretty slow in terms of bug and feature requests handling with the last release 2 years ago, but it's not going anywhere.

Another thing, nobody discarded forks – so some might have it built for themselves with specific changes they need, while for most users it'd good enough. And if the community decides a lot of things piled up with no movement for a long time, it will be eventually forked – that's how recently nsxiv popped up.

And it seems there are some good PRs coming up (https://github.com/jhawthorn/fzy/pull/170, https://github.com/jhawthorn/fzy/pull/174) meaning people still need and use this tool.

So I don't think this argument is strong enough.

I personally prefer a compact 39K binary over 2.5M bloated one for the job I need, and have no interest in keeping the entire Go toolkit when building packages from source (since I use a source-based distro as well).

I think it would be great to have alternative fuzzy searchers to challenge the status quo, but also for extensiveness and overall health of nnn providing users choice of functionality implementations (like mediainfo, exiftool, file for filetypes/fileinfo).

jarun commented 2 years ago

@vaygr I have a problem with a maintainer not even responding to feature requests. Period.

vaygr commented 2 years ago

@jarun unfortunately that's true for many popular projects including the ones I mentioned above. But that shouldn't discourage from using them, especially if the community is interested.

N-R-K commented 2 years ago

@vaygr We get bug reports on plugins quite often which are actually upstream issues. So if a particular upstream is unmaintained and/or doesn't respond on defect reports, then I can understand why @jarun may not want to have that project be included in the plugins.

Besides, plugins are indicative so you're free to modify them to support alternatives. And you can make your modifications public as well so that other's who are interested can fetch from that.

jarun commented 2 years ago

@vaygr I don't want to have deps on repos which are unresponsive. Write your own plugin and move on. No one cared when I removed fzy (including its maintainer). That's exactly where its popularity lies.

N-R-K commented 2 years ago

Does anyone actually use icons-in-terminal ? Haven't seen anyone use it and upstream seems inactive as well: https://github.com/sebastiencs/icons-in-terminal. I'm thinking of removing it.

jarun commented 2 years ago

Yes, there are users. Please retain.

anjerukare commented 2 years ago

Is it possible to set up archive extraction to open extracted folder in the current context?

jarun commented 2 years ago

No, don't want to change the behaviour. But extract to . and a new context will not be opened. Thanks!

egrain commented 2 years ago

Is there a way to do nnn -A inside nnn? I'm sure there is a reason to make the auto advance thing the default, but I hate it.

N-R-K commented 2 years ago

@egrain you can use NNN_OPTS to set A to be default. See the manpage for more details.

egrain commented 2 years ago

Thanks for the quick response. But then I could just make a bash alias. My issue is that I'm using nnn on multiple boxes with multiple distros, so I'm always using the default settings. I guess I just have to nnn -A from now on. Still, an inside switch would be appreciated. I thought ctrl + n might do it, but that didn't change anything. Someone's good lord it auto opens files as well! Should there ever be a vote count me against this.

tzeikob commented 2 years ago

Not sure if anyone has already mentioned this, but in the case where trash is enabled wouldn't be better to have the key binding x attached to trash and the ctrl + x to the rm command so we can have both ops? Now both bindings set to trash if trash environment variable is set.

Kind of the same way the GUI file managers work (delete, shift + delete) nowadays.

I'll be happy to work on this.

jarun commented 2 years ago

No, I don't want the keybind to percolate that deep. An additional check at every step makes the code unmaintainable at some point.

TBH, we don't want to become like the other file managers in every aspect.

jarun commented 2 years ago

@N-R-K @luukvbaal what do you guys say?

N-R-K commented 2 years ago

You can already use a plugin for doing rm, bind it to x and then use alt+x for doing deletion bypassing NNN_TRASH. So yes, I agree with @jarun that there's no need to modify nnn for this.

tzeikob commented 2 years ago

@N-R-K you're totally right, I was about to follow up with this solution too!

jarun commented 2 years ago

In general, the Ctrl keybind variant is for users who prefer the type-to-nav mode. This type of change will violate that.

ouuan commented 2 years ago

I read the #1386 thread but I don't understand why the . problem (smart parent directory) did not prevent the patch from being merged or how to solve this problem. How am I supposed to get the . behavior now?

jarun commented 2 years ago

What is the . behaviour? What tool do you want to use?

ouuan commented 2 years ago

What is the . behaviour?

I've linked to your comment. You said "With atool I just use . and it works" so I used the word ". behavior".

What tool do you want to use?

I want to use atool, but now the default one is bsdtar.

jarun commented 2 years ago

Uninstall bsdtar and you should be fine.

ouuan commented 2 years ago

Uninstall bsdtar and you should be fine.

I'm using Arch, bsdtar is a part of libarchive, and libarchive is required by many packages including the package manager pacman.

thenoobtester commented 2 years ago

Hi, great file manager !

Is there any chance you could integrate fribidi? I ask because I regularly work with a bunch of files with names in arabic and it would make it easier for me to read them. I usually just pipe the output of commands (e.g ls or cat) to fribidi but in this case it doesn't work. It would be great but not urgent.

Thank you

jarun commented 2 years ago

@ouuan I think I got tricked. @eNV25 never mentioned that bsdtar is also installed by default on Arch.

Anyway, given both are installed by default and atool is actually smarter, I am reverting the change. Yes, even I have issues using bsdtar as default.

jarun commented 2 years ago

@thenoobtester I am not familiar with fribidi. However, I don't see why it needs integration? It should work like any other font, right?

jarun commented 2 years ago

@ouuan reverted at b76cea3a341fbb1d1525efb942cb73fa9fc03c0d.

0xACE commented 2 years ago

@thenoobtester it seems like it would be trivial to add fribidi support.

You would need to patch dentfill and SEL_RENAME to use fribidi's visual strings.

If the dentfill change slows things down too much (unlikely) you could add the visual string to the associated structure.