-
-
Notifications
You must be signed in to change notification settings - Fork 769
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 #427
Comments
My absolutely biggest usability problem at the moment is that I search, don't find what I want and press "up" to access the search history. In nnn this means that you don't access the search history but move up in the file-list, the status bar is displayed again and your previous search-term is gone for good. So a big gain for me would be for nnn to at least remember the last search item, so you could search, see what you find, move around, and then maybe slightly tweak your search without having to retype everything. It would be even better if maybe the last 5 items or so could be kept - maybe even saved to disk so that they would be accessible again after a restart. I don't know if the string-search as it currently works is intended to work across directories, because I could live very well with typing "/" to start a search, then if the next char is again a "/" it will be a regex search (which should be case-sensitive as you can build case-insensitivy into the regex if you want it) and if not it's a string. So "/hubba" would search case-insensitive for "hubba", while "//h[0-9]{2}" would regex-search for a lower-case h followed by 2 digits. If I also wanted to include upper-case "H", I would simply do "//[hH][0-9]{2}" I would not really need all the powers of pcres, that would be silly in a file manager, but to be able to search for patters of digits and letters in a simple way would be very handy - so I would like to have things like "\d" or "\w" etc. One idea would be to allow occurances of \d in a typed-in regex and then translate this regex into a POSIX-compatible version. That would mean a user could type in "//\d{2}-\d{2} and nnn would in a first step replace all occurances of "\d" with "[[:digit:]]" before it's handed over to the regex-library. |
Oh - to your idea about triggering case-sensitivtiy via capital-letters - I think that's not bad. "/hubba" => case insensitive So how would I search for an all-lower case word in a case-sensitive way? If regexes would be case-sensitive (as I proposed above) and started with "//" you simply do "//hubba" All cases covered I believe. |
@ghistes I have added the line items. These are up for grabs now. If possible, please get your hands dirty with the code, understand how it is today and raise PRs. |
The last filter is remembered at commit 0e20328. |
@ghistes I sent you 2 invites - for |
is not possible without redesigning search. Filters are search as you type - you type the next char and the scan happens. This also helps in having a very efficient algorithm wrt. performance. So if you wanna come back, you have to delete chars and come back. Another advantage is the left and right key work as they should in normal mode.
No, it's not. We can have what you are proposing with some modification I guess.
This is hacky. Tomorrow there might be another case. I wouldn't want to parse and modify input provided by users. That warrants documentation and may take users by surprise. Compiling in the PCRE lib option is really not that scary. Probably give it a shot yourself.
It wouldn't work. Say the string is "abcDeF". If you erase Similarly I think it would be best to have a toggle like |
regex and string toggle is implemented at 8588b3f. |
Toggle filter case-sensitivity is implemented at 70dcbf4. |
Wow, quick progess again. This is really getting very useful very fast. There seems to be a little bug (or at least an inconsistent behaviour) with the history: Press "/" to search. Then enter "n". Files are filtered. Press backspace. Filter is now empty, all files are visible. Press backspace again. Filter-prompt is replaced with status-bar. Press "/" to search again. Now "up" to access history (should either result in an empty filter or "n", depending on whether an empty search should go to history) but what happens is that the filter-prompt is closed and instead a file is selected. So sometimes "/" + "up" accesses history and sometimes not. I would want predictable behaviour. When you are in the prompt for a filter "up" should never leave this prompt. When the history is empty then simply nothing should be done. The current key-bindings have a certain logic, but please keep in mind that "" and "|" are both a bit awkward to enter on non-us keyboards. What I ultimately would like to have is remembering maybe 5 history-entries, so you could easily re-run previous searches. But to do that the history would need to remember not just the filter-expression but also how to interpret them (ie if they should be seen as string or regex, and with what sort of sensitivity). At the moment (as far as I understand it) the modes seem to be a state not of the individual filter, but of nnn. So if I do a regex-search and then a string-search (assuming I had more than one history) and then wanted to repeat the regex-search I would have to change the mode first - recalling the history would not be enough. Ideally I would like to have something like booksmarks for filter, where I could specify a specific filter including all the modes, eg. "=|hubba" to mean a case-insensitive string search for hubba or "/-abc[0-9]*" to mean a case-sensitive regex-search and associate such filter-expressions with a key (like the regular bookmarks) so that these filters could be accessed very fast. Finally I started to look at the code a little bit and noticed that the dependency on dbg.h is missing from the Makefile and that in the DPRINTF_D-macro there seems to be a spurious LINE at the end that is absent from the other debug-macros. Do you want a PR for that? |
@ghistes please join the nnn-dev discussion. |
The filter is gone.
The filter is empty, meaning there is no filter in history, so the Up arrow's original behaviour picks up. It's the correct behaviour.
Yes, you should predict and expect that when you erased the filter with backspace, the filter is gone. ;) Let's word it this way - the Up arrow shows the last filter if one exists.
Suggest alternatives. I changed
Yes. Maybe a better option is to add custom filters with a keybind and use the same keybind to add a filter when the prompt is empty.
We are talking about a structure with a char pointer and 2 bools here.
I had something to push. To removed the spurious arg. Leave the Makefile dep. Not super-important. |
Should they be pre-defined in your rc file or you would dynamically add and forget during a run? Maybe we can have 5 fixed and 5 dynamic? |
Forget I asked. Maybe we are over-complicating this thing with filtering. @0xACE @KlzXS @annagrram what do you think? |
Ideally (for christmas maybe?) I would like to have nnn remember the last 5 seaches/filters. Also I would like to define searches/filters in the same way as bookmarks work today - every one When the search-prompt is open you should be able to navigate through the history with up and down keys. And there should be a way to fast-acess them by having some hot-key where <KEY>+<letter> : run the bookmarked filter associated with Also I would like to have a way to edit the filter-prompt so you can iteratively build expressions. What I am striving for would be a workflow where you open nnn. Go to a bookmark. Run a pre-defined filter (eg list all log-files) with two keystrokes. Then you realise you've got the wrong dir. No problem. You navigate to the proper dir and just re-run your search with two keystrokes. etc etc etc But clearly this won't happen overnight any maybe you have a different vision... |
And if I delete all chars from a filter I still have a filter (it's the emtpy filter showing all files). What I am trying to say is that when you're in the search-prompt and press "up" you should NEVER select a file as (conceptually) the history is never empty. I really dislike the behaviour that my search-history determines what happens when I press "Up". But it's a big step forward as it is. |
Regarding getting list of files as input. Is it final that we create a subtree with symlinks in I wanted to discuss what we get for input. Does the user give absolute or relative paths, if absolute, do I assume that they point to something in the subtree of the current working dir i.e. relative paths but with cwd as prefix? Also can I assume that the paths don't contain |
I think the tmp dir is the simplest solution. Note that the symlinks may point across volumes. We need to handle that. Regarding absolute and relative, there can be a mix. We already handle that in main(). |
What do you mean we already handle it?
Should I make a dir and put symlinks to d, e and f, should I make a dir c and in it make links to the files, should I go even higher? I would need to assume that they are pointing to something in the subtree of the cwd in which case just skip cwd prefix and pretend they are relative paths. |
Okk, put symlinks to d, e, f in the same dir. |
Ok. I'll make minimal assumptions and we'll see how it behaves. |
It should work. Because in this particular mode, for each file we will stat with follow_symlink and get the details of the target file. |
It will. How does this sound:
I don't like the second point, but I don't like resolving symlinks even more, because that would make the result look confusing. |
How does this help? |
Say I have
I would display the following
I could display everything, but I think this way is more compact and straight to the point. |
Sounds good to me! |
Some notes on the algos to avoid re-work (you can suggest better ones, of course): I think to get the common path you'll use an algo like: get first file and take it's dirname, get second one, see how far they match (I am not sure if there's an API to do that already) and now this is you minimum common. Match third file's dirname with minimum common and so on... In case there's no API to find matching parts of strings, check |
Where should we draw the limit to the size of input? I need to allocate some memory for the input, but how much the first time, and when do I stop and say that's too much? I think we can start with 256 paths which translates to 1MiB, and go up to 216, which is 256MiB. If you need more than that you probably know how to use xargs. What do you think? |
Chunks of 4Kb would be fine with 0 gap. See dentfill on how we do this for file names today. |
Ahh OK. The input. I think we should go in steps of 512 KB. |
Yes. Did you try to hit
I have
|
Oh, that is what I was missing. Ty @jarun , didn't think of |
Yes, for the basic formats you don't even need to install anything or set any config. As we mentioned, v2.9 has several smart workflows. |
if you like the project do award a star and share with your friends. We invest a lot of our personal time on contributing to open source software for free. ;) |
I'd like to see a force umount option - often stuck with the normal umount and force helps :) (Really like v2.9 - thanks a lot!) |
Unfortunately |
@pat-s are you talking about the |
Yes, the one bound to |
Ok, I'll check what can be done. |
@pat-s please search a little and let me know the option for |
One can pass mount options via So far I use This usually happens when there is a network disconnect and I didn't manually disconnect the drive beforehand. I sometimes also get
when unmounting via |
I tried Try this: when the unmount from
and see if it works. Share the command which works for you. |
Also see if |
Please don't make any forced unmount by default, normally there is some process blocking the resource and it makes sense to get an error and investigate this manually. Maybe if unmount failed, show prompt "retry with force? y/n" ? |
I am thinking of the following workflow: u -> force? -> if y, force, else don't @pat-s we can't use |
@pat-s I think what we are looking for is Can you please confirm? |
@pat-s please confirm if the following patch works.
|
Just found that Do you handle os-dependent calls in Thanks for tackling this. |
Then it's a problem. I think mount requires superuser permissions. Are you able to unmount the directory as a normal user? I'm on Ubuntu and it fails. That's the reason we use |
Also, please share the following commands:
|
Are you using Looking at the linked issue and the fact that there were no updates since 2017 in
Normal cases work fine with Can't replicate the other case right now even though I tried. Let me get back to you when it happens the next time? I used |
We are using I think we can have a mac-specific handling where we use |
@pat-s please test the following patch and confirm unmounting works for both remote mounts and mounted archives. diff --git a/src/nnn.c b/src/nnn.c
index ecf17e1..e38841c 100644
--- a/src/nnn.c
+++ b/src/nnn.c
@@ -473,8 +473,9 @@ static char * const utils[] = {
#define MSG_BOOKMARK_KEYS 35
#define MSG_INVALID_REG 36
#define MSG_ORDER 37
+#define MSG_LAZY 38
#ifndef DIR_LIMITED_SELECTION
-#define MSG_DIR_CHANGED 38 /* Must be the last entry */
+#define MSG_DIR_CHANGED 39 /* Must be the last entry */
#endif
static const char * const messages[] = {
@@ -516,6 +517,7 @@ static const char * const messages[] = {
"bookmark keys:",
"invalid regex",
"toggle 'a'u / 'd'u / 'e'xtn / 'r'everse / 's'ize / 't'ime / 'v'ersion?",
+ "unmount failed! try lazy?"
#ifndef DIR_LIMITED_SELECTION
"dir changed, range sel off", /* Must be the last entry */
#endif
@@ -3518,18 +3520,24 @@ static bool remote_mount(char *newpath, int *presel)
*/
static bool unmount(char *name, char *newpath, int *presel, char *currentpath)
{
+#ifdef __APPLE__
+ static char cmd[] = "umount";
+#else
static char cmd[] = "fusermount3"; /* Arch Linux utility */
static bool found = FALSE;
+#endif
char *tmp = name;
struct stat sb, psb;
bool child = FALSE;
bool parent = FALSE;
+#ifndef __APPLE__
/* On Ubuntu it's fusermount */
if (!found && !getutil(cmd)) {
cmd[10] = '\0';
found = TRUE;
}
+#endif
if (tmp && strcmp(cfgdir, currentpath) == 0) {
mkpath(cfgdir, tmp, newpath);
@@ -3554,9 +3562,24 @@ static bool unmount(char *name, char *newpath, int *presel, char *currentpath)
return FALSE;
}
+#ifdef __APPLE__
+ if (spawn(cmd, newpath, NULL, NULL, F_NORMAL)) {
+#else
if (spawn(cmd, "-u", newpath, NULL, F_NORMAL)) {
- printwait(messages[MSG_FAILED], presel);
- return FALSE;
+#endif
+ int r = get_input(messages[MSG_LAZY]);
+
+ if (r != 'y' && r != 'Y')
+ return FALSE;
+
+#ifdef __APPLE__
+ if (spawn(cmd, "-l", newpath, NULL, F_NORMAL)) {
+#else
+ if (spawn(cmd, "-uz", newpath, NULL, F_NORMAL)) {
+#endif
+ printwait(messages[MSG_FAILED], presel);
+ return FALSE;
+ }
}
return TRUE; |
Works, even with a conflict I think. I think I spotted a short glimpse of the typical error I got but it was skipped immediately and the unmount worked. Thanks!! |
Thanks for the confirmation! |
I am assuming you are used the lazy unmount version of the patch. If not sure, please test master. |
Rolled at #448. |
Rolled from #386.
For next release
-e
replacesNNN_USE_EDITOR
-t
replacesNNN_IDLE_TIMEOUT
umount
on macOS to unmountglow
as Markdown viewer innuke
Proposed features and tasks (up for grabs)
nnn.vim
plugin to show a persistent bar (Support vim popup mcchrish/nnn.vim#46)nnn
pluginsAnything else which would add value (please discuss in this thread).
List of completed features and tasks.
The text was updated successfully, but these errors were encountered: