ToDo list #1133
Comments
|
Small nitpick, but I think having the ascii logo above the version/license would be better. Reasoning is that the help screen should prioritize showing useful information like keybinding more. |
|
Nah. I want to show it off. |
|
Hello,
The first two doesn't work anymore (but they used to); probably something has changed but i'm unable to find the documentation. |
|
Please try master. If they do not work, please find the commit that may have broke them. I'm sorry but I don't have the time to find that out for you. |
|
I'm on master, it may have happen in the last two days, i will take a look which is the guilty commit and report back. I've asked to know if plugin syntax have changed without being documented. |
|
We recently fixed #1162. Can you check that works for you? |
|
@jarun |
|
Thanks for confirming! |
|
As always, thanks to you! |
|
Unfortunately, i was wrong. |
|
Make sure you single quote the exports for |
|
They are already single quotes. export NNN_PLUG='a:mp3conv;b:oldbigfile;c:fzcd;d:-!git diff;e:-!&emacs $nnn;f:-!&pickOne;g:-!git status;i:imgview;o:fzopen;p:-preview-tui;r:rsynccp;t:-preview-tabbed;x:xdgdefault' |
|
Please try to debug this as I will be very busy for a while. |
|
@CantoroMC any update on this? |
|
Unfortunately, I don't have enough experience/time in order to deal easily with this issue. |
|
@CantoroMC please confirm if commit 046d676 fixes the issues. |
|
It seems so. |
|
Don't you think the wiki footer should be upgraded from a dolphin to a horse? ♞♘ |
|
Done! Thanks! |
|
Can we please have rebindable keys? I'm aware it's a somewhat systemic change but we'll have to do it eventually, it's just part of maturing as a program. |
|
@pfdint I'm not responsible for the development of nnn and I may be wrong. |
|
Keybind overrides can be read from environment variables. |
|
@pfdint we are not working on a script here. Keybinds can be changed easily if you are OK to compile the program. If not, choose a file manager which suits your needs. There's nothing wrong in that. |
|
Sounds fair. |
Just out of curiosity, can you name a couple of these rare wacky ones? @pfdint |
|
Definitely the weirdest ones I saw were |
We never claim that we are vim-like in every aspect. Also, now I remember there was another reason behind the decision to allow users to re-configure only through compilation (note the option |
|
Think it's acceptable to disable e on picker mode? When using One other problem I've had with the picker mode was l opening file instead of picking them. Using |
We can do that.
I think that behaviour is documented in nnn.vim. It was discussed before we left it that way. |
|
@pfdint Unfortunately we cannot implement that feature for in the state the program is today. E.g. If keybindings were to be implemented it'd make sense to make a config parser first. Instead we lazily rely on environmental variables... I think we are a long way from doing this. Make peace with it and learn to live with it. I agree that some mindings are weird, but I patch them locally and pull my branch to all my machines, I've been disconnected from If you insist i wrote you a stupid concept 2 nights ago, beware, not much effort was put into this: enum action {
SEL_BACK = 1,
SEL_OPEN,
SEL_NAV_IN,
SEL_NEXT,
};
struct key {
int sym;
enum action act;
};
struct key bindings[200] = {
{'h', SEL_BACK}
};
char *cstr = "65,1;92,3;";
const size_t maxparse = 64;
char keybuffer[maxparse];
int key,act;
char *ptr = cstr;
size_t count = 0;
while(*ptr && sscanf(ptr, "%d,%d;", &key, &act) == 2){
printf("read: %d,%d\n",key,act);
bindings[count++] = (struct key){key,act};
while(*(++ptr)) {
if (*ptr == ';'){
ptr++;
break;
}
}
}It's prone to exploits and would require a bash script that translate the original keystrokes into parseable numbers. It's also require some patching in other parts of the code as |
|
@0xACE If they're going to compile from source then at that point might as well just change the binding in the source itself, much less effort that way. But anyhow, if not wanting to compile is huge priority then it's probably best to use another FM that allows configurable key-binding. There's a huge list of cli FMs to pick from. |
Yeah, though there are differences of behavior on my different machines. on my phone i use a ipod-esque scrolling behaviour and context aware clicking behavior, i dont remember how i made my android aware of patching this: my nnn branch has been stale for a while now. But other than that all my machines use the same static setup To make it clear. I wouldn't advocate anyone actually implements a keybind parser, but if he so wishes: a concept has now been provided. I'm guessing he comes from the usergroup that relies on the distros package manager. Honestly i rarely ever change upstream keybindings, it makes me agnostic to working on machines that i dont own. Unrelated to the keybindings: I'll try to go through some of my minor changes that are compatible with upstream and supply patches |
I should emphasize that it translates into: A large group of our (potential) userbase are affected by compile time decisions. Which may hurt our adoption rate. |
@0xACE I am OK with that. After years of contributing to open source, I have come to realize that the RoI for spending 100s of hours on things that I don't need myself is negligible. A large group of users come back with trivial issues and the disclaimer that they either can't code or can't compile a program. However harsh it may sound, they should not use the terminal. And it's proven by the fact that Windows is used by > 90% users. We have to accept reality. Latest example, do you think the guy who wanted There's a saying from Buddha that goes like - things that we hold dearest hurt us the most. And I clearly see why it's important to prioritize things in life and let go of the cruft. |
|
Hello! Commit d772223 (fix gitstatus and rebase patches), which coincide with tag: v4.3, broke the git patch (i only use the git patch so have no information on the other patches) Description of the problem:
|
|
It's been a while since I made the change to the patch(just didn't push it) but it was supposed to improve the git signs representation, not break it.
Could you show a screenrecording of what you mean? I've been using the new patch for the last few months but never encountered something that seems random.
The new patch indeed tries to show more information about directories when possible, showing i.e. The new patch is taking advantage of the dual columns by not overwriting an already filled column while updating, which was previously the case. It shouldn't be incorrect or random though. |
|
I post some picture:
Sorry, if I haven't embedded images The difference between after and before of dotfiles directory show the problem reported on above post issue nr 2 |
|
What does the output of look like in those directories? |
|
Home directory is not a git directory so |
|
Alright, I'm able to reproduce the issue. The issue pops up for directories not tracked by git. My home directory is tracked by git so never noticed it 🤣 |
|
So, I'm right regarding the "persistence" but the second issue is instead a wanted behaviour? |
|
I would say so yeah. It's not showing any incorrect information, just more. |
|
I understand your point of view, i was concerned of a possible mistake, due to the presence of the first mistake and because i remember then when the author of the patch posted it he/she stated that the sign resemble the output of |
|
https://github.com/luukvbaal/nnn/tree/gitstatus seems to fix it. Can you confirm? Don't quite remember why I changed it in the first place. |
|
No more sign in my home directory. |
|
I would suggest also to not let coincide the new tag with a broken patch. |
This is still true but I think the new strategy shows the most information possible whereas the old one just discarded cumulative changes by overwriting the columns. |
I would agree, not sure how @jarun feels about it. |
Many package managers do hash-checks on tarballs. So I don't think you can just change tags around, if that's what you're suggesting. |
|
Yes, it would lead to downstream issues. Please wait for the next release. |
|
Rolled at #1193. |
Rolled from #1122.
Cooking
Up for grabs
For anything else please discuss in this thread.
Contribution guideline.
The text was updated successfully, but these errors were encountered: