Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ToDo list #1193

Closed
17 tasks done
jarun opened this issue Oct 10, 2021 · 86 comments
Closed
17 tasks done

ToDo list #1193

jarun opened this issue Oct 10, 2021 · 86 comments
Labels

Comments

@jarun
Copy link
Owner

jarun commented Oct 10, 2021

Rolled from #1133.

Cooking

Up for grabs

None open at the time.

For anything else please discuss in this thread.

Contribution guideline.

@jarun jarun added the bug label Oct 10, 2021
@jarun jarun mentioned this issue Oct 10, 2021
4 tasks
@jarun jarun added planning and removed bug labels Oct 10, 2021
@jcfk
Copy link

jcfk commented Oct 17, 2021

Any chance you'll end up including some way to remember the hover position within a child directory?

If I'm hovered over dir1/dir2/file1 inside dir2, jump out to dir1, and then back into dir2, I should end up hovered over file1 instead of at the top of dir2.

@jarun
Copy link
Owner Author

jarun commented Oct 17, 2021

Sorry, no plans to memorize as it's very use-case specific. Also, it makes nav-to-type mode management extremely complex.

@keiviv
Copy link

keiviv commented Oct 19, 2021

Nnn is so perfect that I actually had to fanboy-google the author. I very (very) rarely do that - last one I googled was Fabrice Bellard, years ago.

The best todo is to cherish and keep this rare combination of power, simplicity and clear vision. These days it's so rare (sadly) it feels almost magical.

I see 3 areas of possible long-term improvements:

  1. Wider OS inclusion via a curses alternative. This is clearly not a priority, but should be considered long-term. More users, more sponsors, worldwide domination.
  2. Nvim plugin. While most useful, it can be improved. Sometimes it's empty. sometimes it has own plans. Clicking its window traps. No auto-next on select (as if -J). I use it every day, very grateful to luukvbaal for it, but also very excited to see it on the improvements list. Nvim + nnn is majestic.
  3. Archivemount is not a great piece of software. The author even mentions he is not proud of the code. It's in a sense the opposite of nnn - limited, slow and chaotic. Since most usage cases are rather simple (list, add, delete, rewrite), maybe a 7z wrapper would be more practical, performant and clean. It also would allow Windows and non-rooted Termux users to enjoy the full power of nnn (due to fuse they can't atm).

Keep being cool!

@jarun
Copy link
Owner Author

jarun commented Oct 19, 2021

Thanks for the compliment!

Regarding your notes:

  1. Windows does support curses through PDCurses. I think post let me try dual-boot phase, most users choose a single path - the GUI or the CLI, the former being more in number. Those who pick the GUI are predominantly on Windows. So as long as no one tries nnn with PDCurses we have to understand there's no need for it on Windows.
  2. It's new, so it would have its quirks. Please raise defects on the project with clear reproduction steps and we will actively work on them. Auto-proceed on selection is not implemented as it would be an issue when you don't want to select anything and just want to pick the current file on Enter. Maybe we can improve the flow that when there a selection we don't pick the last hovered file. But in any case, it would be confusing and need documentation. @luukvbaal please have a look at the other notes.
  3. I didn't understand what you mean by 7z wrapper. You can use 7z independently with nnn without installing archivemount.

@jarun
Copy link
Owner Author

jarun commented Oct 19, 2021

Commit 24b71bc takes care auto-proceed and pick on Enter.

@luukvbaal please take a note for nnn.nvim. Note that we still support -J to disable auto-proceed.

@keiviv
Copy link

keiviv commented Oct 19, 2021

I suggested to increase / ease OS support as I only want more people to enjoy nnn - benefiting both them and you. Some have to use Windows not because they love it. But this is of a low priority - just global plans for the future to make things as easy as possibru if you have time for it.

By 7z wrapper I meant maybe some non-archivemount, alternative way to transparently access archives. Suggested it because I often forget I can't use fuse on Termux without root, and instinctively press m. Also - Windows (fuse is painful there). It is debatable if this a core or plugin functionality, and fully up to your vision.

P.S. I just want to make it clear that I highly respect @luukvbaal, and that those minor imperfections I mentioned in no way preventing me and everyone else from using and loving his hard work every day. I'm simply glad it will get more awesome.

@jarun
Copy link
Owner Author

jarun commented Oct 19, 2021

On Linux you can install p7zip-full, override NNN_ARCHIVE to include more extensions and list, extract or open them on Enter independently of archivemount (it's an optional dependency).

@keiviv
Copy link

keiviv commented Oct 19, 2021

Yes, that's what I use. But a transparent in-nnn access via 7z (or other) would be way cooler, I think. But it's up to you, and of course is not essential or priority.

I'm trying my best, man... You shouldn't have written such a perfect piece of software that it's so hard to add something to a todo list. No one to blame here but you 😄.

@jarun
Copy link
Owner Author

jarun commented Oct 19, 2021

But a transparent in-nnn access via 7z (or other) would be way cooler

You mean you want to open it by default using 7z? That's not possible because many archive formats are not supported by 7z also e.g. rar. We wouldn't hard-code more utilities for archive handling. Already we do that for bsdtar, tar and patool which are more of less generic.

@keiviv
Copy link

keiviv commented Oct 19, 2021

7z supports rar reading (edited). Its format support is extremely wide. Igor really made a swiss knife of archiving - I doubt anyone can name a practically used format it does not support - that's why I suggested it as an all-in-one optional archive handler. Thought - if it's just one single entry point & logic for everything - why not.

It shares the same ideology as nnn - small & powerful.

Not insisting though, just something for you to consider for later.

@jarun
Copy link
Owner Author

jarun commented Oct 19, 2021

  1. I don't really have the time to explore another utility. atool uses 7z internally anyway.
  2. 7z cannot auto-detect archives by extension (tried rar and tgz) at least when creating:
1 ~/GitHub/nnn$ 7z a archive.tgz CHANGELOG Makefile

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (806E9),ASM,AES-NI)

Scanning the drive:
2 files, 53413 bytes (53 KiB)

Creating archive: archive.tgz

Items to compress: 2



System ERROR:
E_INVALIDARG
1 ~/GitHub/nnn$ 7z a archive.rar CHANGELOG Makefile

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (806E9),ASM,AES-NI)



System ERROR:
E_NOTIMPL

@keiviv
Copy link

keiviv commented Oct 19, 2021

Yep, rar is read-only, I've edited right after posting. But firstly rar is closed source commercial (and rather rare usage-wise last ~10 years due to 7z rise), plus reading is better than nothing. It's basically one single edge case.

Not pushing it, just trying to evaluate pro and contra. Well, just keep it in the back of your head then, maybe one day you'd want it.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Oct 20, 2021

@keiviv

Sometimes it's empty. sometimes it has own plans. Clicking its window traps.

Can you explain what you mean by this if the issues are still present and/or open issues on nnn.nvim? First issue might have been fixed by luukvbaal/nnn.nvim#6?

@keiviv
Copy link

keiviv commented Oct 21, 2021

@luukvbaal - sometimes (rarely) the window is empty, need to close & re-open. I did not submit the issue as I cannot find any logical correlations yet (due to the rarity), and was afraid to waste your time. Same for the 2nd. I'll submit if I find more useful info for you.

The clicking issue you can ignore if you are busy - as most vim people don't usually even use mouse. But on Termux it's sometimes easier to touch. Most floating windows plugins (e.g. Telescope etc) process touches correctly, but nnn traps the cursor (as it's a terminal) - and you cannot exit unless :q. When deep into work I sometimes forget that.

None of those are critical, and I love you. Nvim + nnn + your plugin is a dream combo. I was simply glad to see it on this list - as opposed to forgotten. My remarks were clumsy, and came out way more snarky than it was in my head. Even added a P.S. in the next post when I re-read it and blushed.

Just do your things. You guys know what you are doing.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Oct 21, 2021

Alright, thanks for the kind words. I'm not sure about mouse behavior either, although pressing i (to go back to insert mode) should be sufficient to get out of the trapped state. There is no need to :q.

According :h terminal-input mouse events are supposed to be forwarded to terminal buffers:

Mouse input has the following behavior:

- If the program has enabled mouse events, the corresponding events will be
  forwarded to the program.
- If mouse events are disabled (the default), terminal focus will be lost and
  the event will be processed as in a normal buffer.
- If another window is clicked, terminal focus will be lost and nvim will jump
  to the clicked window
- If the mouse wheel is used while the mouse is positioned in another window,
  the terminal wont lose focus and the hovered window will be scrolled.

I'm positive this worked properly at one point in nnn.nvim for NnnPicker but not for NnnExplorer. I assumed at the time that this had to do with the floating window but according to the docs it's supposed to forward mouse events for all terminal buffers.

The thing is that I can't find any commit where mouse events are being forwarded now, has this ever worked properly for anyone in nnn.vim @mcchrish? For me it doesn't work in any terminal buffer anymore even without any plugin, i.e. :e term://nnn doesn't work despite mouse=a being set..

I agree it isn't the most important but if is supposed to work according the the docs I would like to have it work.

@keiviv
Copy link

keiviv commented Oct 21, 2021

Wrote :q just as I was quickly testing it before posting - and closed without selecting. Posted the wrong brain register 😄. Yes, i to restore the keys functionality. But you've got the gist - an extra quirk to remember. Sometimes when deep into work you press keys in auto-pilot and forget it.

But this is not important, only if you are in a Sherlock Holmes mood.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Oct 21, 2021

It turns out running tmux inside the terminal buffers makes mouse support working on my setup lol. So changing nnn cmd override to tmux new-session nnn lets you interact with nnn with the mouse and prevents the "trap" as well.

@luukvbaal
Copy link
Collaborator

Wonder why this is necessary, I usually use st but the same behavior is present on xterm and kitty.

@keiviv
Copy link

keiviv commented Oct 21, 2021

Err. I am running tmux though.
Added: Do you have termux + tmux to test?
Added: If not - install from Github or F-Droid, the Store version exists, but is discontinued.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Oct 21, 2021

Running neovim inside tmux makes no difference for me, you need to actually set the cmd override for nnn.(n)vim to tmux new-session nnn.

I suppose this results in some sort of nested tmux session if you're already running tmux outside of nnn.(n)vim but it's what works (for me) 🤷🏻‍♂️

Edit: haven't tested termux.

@keiviv
Copy link

keiviv commented Oct 21, 2021

Ah. Anyway I already feel guilty for bothering you. Just maybe put it into a low priority and do your things, this is not really important.

@N-R-K
Copy link
Collaborator

N-R-K commented Oct 21, 2021

It turns out running tmux inside the terminal buffers makes mouse support working on my setup lol.

Same here on vim. sfeed_curses works fine however, don't have any other interactive terminal apps to test on. So I am assuming this is an nnn issue.

@luukvbaal
Copy link
Collaborator

I'm not sure, I see the same behavior with htop.
:e term://htop no mousef forwarding, :e term://tmux -> htop mouse forwarding.

@N-R-K
Copy link
Collaborator

N-R-K commented Oct 21, 2021

I'm not sure, I see the same behavior with htop.

Ahh, forgot about htop. Yes same here. I guess tmux and sfeed_curses are "signaling mouse events" while nnn and htop aren't?

@luukvbaal
Copy link
Collaborator

I'm not sure why one terminal application works and the other doesn't. Imo this should be agnostic the the terminal applications and instead just work if mouse events work outside of the vim terminal if events are properly forward as claimed by the docs. No idea though.

@N-R-K
Copy link
Collaborator

N-R-K commented Oct 21, 2021

Looked into the sfeed_curses source. This patch works:

diff --git a/src/nnn.c b/src/nnn.c
index 8499489..ac1b802 100644
--- a/src/nnn.c
+++ b/src/nnn.c
@@ -2079,6 +2079,8 @@ static bool initcurses(void *oldmask)
 	//intrflush(stdscr, FALSE);
 	keypad(stdscr, TRUE);
 #ifndef NOMOUSE
+	printf("\x1b[?1000h\n"); /* xterm X10 mouse mode */
+	printf("\x1b[?1006h\n"); /* extended SGR mouse mode */
 #if NCURSES_MOUSE_VERSION <= 1
 	mousemask(BUTTON1_PRESSED | BUTTON1_DOUBLE_CLICKED | BUTTON2_PRESSED | BUTTON3_PRESSED,
 		  (mmask_t *)oldmask);

I have no clue how it works, or what it's doing though 😄

P.S tmux seems to be doing something similar.
https://github.com/tmux/tmux/blob/ee9885a40ced1fd34fe2eed879a40975a0691ac8/tty.c#L770-L773

@62832
Copy link
Contributor

62832 commented Nov 4, 2021

That might be it. I do have kdialog installed on this machine, but I have also just tried it on another machine without the kdialog package installed at all and only the fake script from above. On that machine, it still opens nnn just as I'd want it to, but my main one must have an issue with the env var the way I have set it.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Nov 4, 2021

Like I said, chromium will not use your custom kdialog script if it finds the kdialog package proper earlier in your PATH. Doubt the issue is the env var, just try it with XDG_CURRENT_DESKTOP=KDE chromium/chrome/brave.

@62832
Copy link
Contributor

62832 commented Nov 4, 2021

GOT IT. It seems like also having GTK_USE_PORTAL=1 exported was causing conflicts with that. Removing that var and uninstalling any desktop portal package I had fixed it when running Brave as just suggested.

@luukvbaal
Copy link
Collaborator

I see, but are you now actually able to use nnn as the picker for chromium? Doesn't seem to work for me.

@62832
Copy link
Contributor

62832 commented Nov 4, 2021

Well, yes in the sense that nnn now opens on my main machine too with the right var exported. Of course, actually using the picker functionality like this isn't quite going to work, so maybe the script could do with some more fleshing out to use the picker functionality properly (unless this simply wouldn't work at all).

@luukvbaal
Copy link
Collaborator

Well like @N-R-K said, the python script you linked just writes to stdout which is what nnn -p - does. So if the original script works, I'm not sure why this doesn't.

@jarun
Copy link
Owner Author

jarun commented Nov 4, 2021

Guys, when you are done, probably update the Wiki with the steps.

@N-R-K
Copy link
Collaborator

N-R-K commented Nov 4, 2021

Well like @N-R-K said, the python script you linked just writes to stdout which is what nnn -p - does. So if the original script works, I'm not sure why this doesn't.

Some weird shenanigan is going on. The following works for me.

#!/bin/sh
pick() {
	st -e nnn -p /tmp/pick
	cat /tmp/pick
}
pick

@N-R-K
Copy link
Collaborator

N-R-K commented Nov 4, 2021

I guess you need to write to stdout of the script itself and somehow invoking st breaks that?

This also works btw:

#!/bin/sh

tmp="${TMPDIR:-/tmp}/nnn_pick"
pick() {
	st -e nnn -p "$tmp"
}
pick && cat "$tmp"

@62832
Copy link
Contributor

62832 commented Nov 4, 2021

Perfect. Uploading files works just fine. Now it might be worth ironing out / making sense of the other direction (Save As...) in this way.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Nov 4, 2021

I checked /proc/$$/fd of the kdialog script which contains a pipe for stdout. This works as well:

#!/bin/sh
st nnn -p /proc/$$/fd/1

It writes to the pipe that is used by chromium I presume.

Indeed some parts of the original script you posted are required to distinguish between upload and save as, I could check it out tomorrow.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Nov 4, 2021

This works for upload, save to folder with filename from chromium(select and quit) and save to new file created in nnn(select with enter or select and quit).

#!/bin/sh
while :; do case $1 in
    --getsavefilename) file="$2" break ;;
    --*) shift ;;
    *) break ;;
esac done
file="${file##/*/}"
st sh -c "nnn -p - | awk '{print system(\"[ -d \" \$0 \" ]\") ? \$0: \$0\"/$file\"}' > /proc/$$/fd/1"

Added some sh -c and quote shenanigans along the way, I'll check if any of those can be avoided tomorrow and add it to the wiki.

Edit: used st -c chromiumdialog to make it floating in my window manager🔥

Unfortunately this broke my current solution for chromium "show in folder" with nnn. I guess XDG_CURRENT_DESKTOP=KDE makes chromium look for some KDE program for "show in folder".

@jarun
Copy link
Owner Author

jarun commented Nov 4, 2021

@luukvbaal please add the details to wiki. ;) also does this work with my browser, firefox? ;)

@N-R-K
Copy link
Collaborator

N-R-K commented Nov 4, 2021

@luukvbaal please add the details to wiki. ;) also does this work with my browser, firefox? ;)

Afaik firefox needs some other var GTK_USE_PORTAL=1 maybe, you might also need to mess around in about:config with some "portal" related settings. Haven't tried it though.

@jarun
Copy link
Owner Author

jarun commented Nov 4, 2021

Thanks!

@luukvbaal
Copy link
Collaborator

Added instructions here. I'm not sure how to adapt to firefox if possible @jarun.

@luukvbaal
Copy link
Collaborator

Also not sure why and how to fix the "Show in folder" button stops using xdg-open for inode/directory which is set to nnn on my system.

Guess we need to know what chromium is trying to open with XDG_CURRENT_DESKTOP=KDE.

@jarun
Copy link
Owner Author

jarun commented Nov 4, 2021

Thank you! Don't worry about Firefox. Someone willing to try it out will show up someday. 👍

@N-R-K
Copy link
Collaborator

N-R-K commented Nov 4, 2021

I can't figure out what's going on with firefox either. Which is unfortunate, because I'm using it as my primary browser where this feature would be pretty useful. If I do figure it out, I'll update the wiki and give a ping.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Nov 4, 2021

It seems like XDG_CURRENT_DESKTOP=KDE completely disables xdg-open on chromium. Not only "Show in folder" stops working but also just trying to open any downloaded file 😞

Tried looking through chromium source but haven't found yet what it's trying to do instead...

@luukvbaal
Copy link
Collaborator

luukvbaal commented Nov 4, 2021

The issue lies in xdg-open itself not chromium, which makes more sense.

Creating a xdg-open wrapper that unsets XDG_CURRENT_DESKTOP restores xdg-open functionality on my system.

Edit: added instructions here.

@62832
Copy link
Contributor

62832 commented Nov 4, 2021

It seems like XDG_CURRENT_DESKTOP=KDE completely disables xdg-open on chromium. Not only "Show in folder" stops working but also just trying to open any downloaded file disappointed

Tried looking through chromium source but haven't found yet what it's trying to do instead...

Strangely enough, even opening any file through nnn itself with that var exported is completely broken since xdg-open just refuses to run then. Unless I have some other package interfering with it or I'm missing some other package, that wrapper script is probably gonna be the way to go.

@62832
Copy link
Contributor

62832 commented Nov 4, 2021

Well now that the wrapper scripts are set up and everything is going according to plan, the only minor annoyance is that the nnn picker always runs twice on first use every time the browser starts. I imagine it could get annoying after a little bit and I'm not really experienced enough to know how to suppress that, but it's not really a huge issue for the moment.

@luukvbaal
Copy link
Collaborator

luukvbaal commented Nov 4, 2021

Yep XDG_CURRENT_DESKTOP=KDE borks xdg-open if you're not actually in a KDE environment (just run XDG_CURRENT_DESKTOP=KDE xdg-open <file>.

The issue to me seems that xdg-open has no fall back for XDG_CURRENT_DESKTOP=KDE. See for example KDE vs Gnome in xdg-open:

open_kde()
{
    if [ -n "${KDE_SESSION_VERSION}" ]; then
      case "${KDE_SESSION_VERSION}" in
        4)
          kde-open "$1"
        ;;
        5)
          kde-open${KDE_SESSION_VERSION} "$1"
        ;;
      esac
    else
        kfmclient exec "$1"
        kfmclient_fix_exit_code $?
    fi

    if [ $? -eq 0 ]; then
        exit_success
    else
        exit_failure_operation_failed
    fi
}

open_gnome3()
{
    if gio help open 2>/dev/null 1>&2; then
        gio open "$1"
    elif gvfs-open --help 2>/dev/null 1>&2; then
        gvfs-open "$1"
    else
        open_generic "$1"
    fi

    if [ $? -eq 0 ]; then
        exit_success
    else
        exit_failure_operation_failed
    fi
}

The gnome case has an open_generic fallback which the KDE case lacks.

Perhaps using a different XDG_DESKTOP_SESSION will allow to use one less wrapper.

@luukvbaal
Copy link
Collaborator

the only minor annoyance is that the nnn picker always runs twice on first use every time the browser starts.

Hmm that is annoying, I see it too.

@luukvbaal
Copy link
Collaborator

Chromium asks for the version of kdialog the first time it is run. Changing the opt parser to

while :; do case $1 in
    --getsavefilename) file="$2" break ;;
    --version) printf ""; exit ;;
    --*) shift ;;
    *) break ;;
esac done

fixes the issue.

@jarun jarun mentioned this issue Nov 4, 2021
@jarun
Copy link
Owner Author

jarun commented Nov 4, 2021

Rolled at #1219.

@jarun jarun closed this as completed Nov 4, 2021
Repository owner locked and limited conversation to collaborators Nov 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests