Closed jarun closed 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.
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
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.
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
.
Final version of Colemak-DH key binding patches is done. colemak-dh-patches_final.tar.gz
Move here
Manage session
Select range/clear
Edit sel list
Edit file
Key binding | Action |
---|---|
m | Parent |
n | Down |
e | Up |
i | Open |
Ctrl + E | Top |
Ctrl + N | End |
Key binding | Action |
---|---|
s | Select range/clear |
l | Edit sel list |
c | Create new/link |
y | Edit file |
Key binding | Action |
---|---|
h | Connect remote |
Ctrl + F | Toggle type-to-nav |
k | Manage session |
@luukvbaal please plan to add to the patch framework. Once you are done, I'll plan for the next release.
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.
@N-R-K please confirm commit f4f4e1a97b7539f5dcd21eb07c6284b6153b1c3f. This is the latest version.
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?
Any good reasoning against fzy?
It's a dead tool - https://github.com/jhawthorn/fzy/issues/135
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).
@vaygr I have a problem with a maintainer not even responding to feature requests. Period.
@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.
@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.
@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.
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.
Yes, there are users. Please retain.
Is it possible to set up archive extraction to open extracted folder in the current context?
No, don't want to change the behaviour. But extract to .
and a new context will not be opened. Thanks!
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.
@egrain you can use NNN_OPTS
to set A
to be default. See the manpage for more details.
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.
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.
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.
@N-R-K @luukvbaal what do you guys say?
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.
@N-R-K you're totally right, I was about to follow up with this solution too!
In general, the Ctrl
keybind variant is for users who prefer the type-to-nav mode. This type of change will violate that.
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?
What is the .
behaviour? What tool do you want to use?
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
.
Uninstall bsdtar and you should be fine.
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
.
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
@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.
@thenoobtester I am not familiar with fribidi. However, I don't see why it needs integration? It should work like any other font, right?
@ouuan reverted at b76cea3a341fbb1d1525efb942cb73fa9fc03c0d.
@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.
Rolled from #1348.
Cooking
atool
as the default archive handler-B
to usebsdtar
as the archive utilityUp for grabs
None open at the time.
For anything else please discuss in this thread.
Contribution guideline.