Field history in the "Find file" dialog should not impact the usability for major use cases

[birdie]

99% of the time you need to search for a certain content only *once*, thus it's absolutely inconvenient to have these fields populated with previous search requests.

Please, make the aforementioned fields reset for every new search.

If someone has a different opinion, please, implement a setting which allows to choose how these fields are presented for every new search instance.

[zaytsev]

I do have a slightly different opinion. I think that start at should be always pre-filled with "." (current directory) the way it is in FAR, file name with previous search and content kept empty. In what concerns the search dialog in viewer / editor, I find it convenient to be pre-filled with the last search clause, so it needs no changes.

Is this possible to fix this before release??? The content search be default is very annoying.

[andrew_b]

Replying to zaytsev:

file name with previous search and content kept empty.

I vote against that. It is not comfortable for me.

The content search be default is very annoying.

For you, but not for me. :P

[birdie]

Guys, have you actually? read the original bug report?

If someone has a different opinion, please, implement a *setting* which allows to choose how these fields are presented for every new search instance.

And by empty "Start at" I meant "." (the current directory) - I'm sorry for the confusion.

[andrew_b]

Too many various non-obvious and non-critical options is evil. The reason behavior should be implemented instead of optionise of each behavior nuance.

[birdie]

OK, for many years the default behaviour was to start with these fields reset, so, please, revert the old behaviour.

For those who like searching for the the same thing in different places/locations, having a search item in a buffer (so, you can middle mouse click to paste it) is an easy and affordable option.

[andrew_b]

Replying to birdie:

OK, for many years the default behaviour was to start with these fields reset, so, please, revert the old behaviour.

For many years, the Find File dialog didn't have most of current available options. Let restore the original Find File dialog?

[birdie]

Replying to andrew_b:

Replying to birdie:

OK, for many years the default behaviour was to start with these fields reset, so, please, revert the old behaviour.

For many years, the Find File dialog didn't have most of current available options. Let restore the original Find File dialog?

You obviously go to extremes.

OK, then, since my request makes no sense for developers, I humbly ask to implement a shortcut to reset all those fields.

[zaytsev]

Replying to birdie:

Guys, have you actually? read the original bug report?

I don't think that I have any disagreement with you now, other than the file name and the search directory should use the last entry or should be reset to "*" and "." as it used to be in 4.6.x, BUT the content field should be always kept empty (or, at least, filled with the last entry even if this entry was "" and shouldn't be influenced by searches in the editor/viewer).

Just express yourself more clearly.

Replying to andrew_b:

For many years, the Find File dialog didn't have most of current available options. Let restore the original Find File dialog?

No problem, please do revert to the old search dialog if this is the only alternative option you do want to leave us.

Right now, I have EL5 version of mc 4.6.x to compare with. The "Start at" field is always pre-filled with the latest entry or "." if empty (just as in FAR), the file name is always pre-filled with the latest entry "*" and the "Content" field is pre-filled with an empty string "". The first to fields do have history and the last one ("Content") does not.

These choices have been clearly made for a reason!

At the same time in the latest master, we've got the same (logical) behavior for "Start at" and "File name" field, BUT the "Content" field is always pre-filled with THE LAST STRING THAT WAS USED IN ANY OF THE SEARCH ENGINES (read editor, viewer or search for content in files).

This behavior is clearly neither "reason", nor consistent.

The point is that the Find file dialog is mostly used to FIND FILES. That is entries whose names that match a certain pattern. When you search for files and the content is pre-filled with some arbitrary string you mostly find nothing, swear and realize that you have to erase the string that has sneaked in without your express consent.

The next problem is that it's not JUST pre-filled with the last search entry you used in THIS dialog (which might have been "" in my case), BUT the entry that comes from completely different history from editor or viewer. THIS is the source of major annoyance.

When you use search in the editor or viewer on a routine basis you would NOT expect that tomorrow when you decide to search for a file, the content will be filtered according to some random phrase that you used yesterday in a completely different context.

OK, this is the motivation, but to make the long story short, the options that I see are:

1) Compromise.

a) Content field has it's own history independent from viewer and editor and if it was blank ("") last time, it is blank next time.
b) Content field has the same history as viewer and editor BUT if it was blank ("") IN THE FIND FILE DIALOG last time, it's blank next time.

2) No compromise. Revert completely to 4.6.x behavior.

Is any of these three suggestions an option for you?

[andrew_b]

Replying to zaytsev:

b) Content field has the same history as viewer and editor

Yes. The content search history is shared for file fine, editor, viewer. It's a feature.

BUT if it was blank ("") IN THE FIND FILE DIALOG last time, it's blank next time.

For a long time each history can keep the empty value (see #1814). It works fine for me. I believe that works fine for you.

[andrew_b]

Replying to andrew_b:

s/file fine/file find

[zaytsev]

Replying to andrew_b:

Replying to zaytsev:

b) Content field has the same history as viewer and editor

Yes. The content search history is shared for file fine, editor, viewer. It's a feature.
For a long time each history can keep the empty value (see #1814). It works fine for me. I believe that works fine for you.

It keeps its empty value ONLY if this is the last one used in either editor or viewer, this is my point. If I set an empty value in the Find File dialog, what happens next if I search for something in the editor or viewer is that this empty value is not here anymore.

This results in that the people that used to use "Find File" for it's initial purpose (not grepping for files that contain a specific string, but just looking for a specific file) are always forced to also limit the found files by some arbitrary string that comes from editor or viewer unless they manually clean it out.

This is:

1) A very severe deviation of how it used to be in 4.6.x
2) Other file managers don't do this and for a reason I mentioned above (not to force extra keystrokes)
3) Is on by default and can't be turned off

So it does not meet any of the "feature" criteria but is clearly a bug.

If you want to keep shared history, that's fine with me, I don't care. Actually having the access to the editor/viewer history is not a bad thing. BUT either make it configurable and off by default, OR make an exception for the Content field Find File dialog to be always pre-filled with "" (and keep the access history list if needed) in this was the last choice for the FIND FILE dialog.

So far 4:1 with the only argument of "personally, I like it".

[zaytsev]

Hey Andrew!

I think I have found a compromise solution that you will appreciate. Let's add a checkbox

[ ] Use content filter

Right below the "Content:" field. This checkbox will remember its state across sessions. If this checkbox is on ([x]), then the Find File command will search for a file that contains a specific string. If the checkbox is off, the Find File command will behave as if the "Content:" field was empty.

No extra options, no extra key strokes both for you and for us. Deal?

[ossi]

Replying to zaytsev:

Let's add a checkbox

uhm, no, that just clutters up the gui. it isn't any better than a permanent option.

andrew, what's your use case that makes repeating the previous search (after leaving the results dialog) a so much more common operation than starting an entirely distinct search that you cannot be bothered with pressing alt-h to "recover" the values you need again?

[andrew_b]

99% of all my search cases I don't use MC to find file by name. I use the magic program "locate" for that (1% is files with non-trivial mask, though. These files I find in MC). In most cases I use MC to search file by content.

Yes, I develop MC using MC, so if I found something in editor or viewer, then I want find that in other files. My file mask is "*.[ch]" and it is not changed in 99% of time. Shared content history and it current behavior are very comfortable and useful for me. I don't want call history everytime to fill an empty input line by previous content.

[ossi]

this is obviously a case where the "normal" use as a file manager conflicts with use as an IDE. you should use qt creator as the latter - then you often won't even *need* a text-based search at all. ;)

anyway, i still use mc myself as a backup, in particular for searching, because it can be "targeted" much easier and it is faster for just looking through the results. of course i have a *.[ch]* pattern myself - but it is not the only one. so often enough it's the wrong one.

but whatever, the file pattern preselection is the minor problem. what bothers me more is the pre-filling of the content pattern, as that's almost always wrong. that's particularly annoying if i want to just clear the field completely, as there is no direct shortcut for that (i think ctrl-u should work outside panel context ... in fact, swapping the panels is rather uncommon, so one could map it to shift-ctrl-u instead and use ctrl-u for the more standard function). the line edits' initial auto-overwrite behaves completely differently than in "proper" GUIs, so it isn't immediately obvious how to just replace the text, either (it should highlight somehow, delete should clear, re-entering the field should re-activate the mode irrespective of prior changes).
i think only these cases should propage content patterns: search results => search again and search results => editor/viewer (in fact, it would be really useful if the viewer had a file-crossing "search next" in that mode, so going back to the search results would be unnecessary).

fwiw, modern locates can do regexp search and such, so you don't need mc for that, either.
actually, mc could gain an option in the search dialog to use locate/mlocate/slocate automatically if the pattern matches the tool's capabilities. of course that's not applicable to quickly changing directory hierarchies like the current working set.

[zaytsev]

The “GUI clutter” argument doesn't cut it and so does the suggestion to move the option that I am proposing to introduce to the “Configuration” dialog. Obviously you didn't take your time to think about the use cases and implications of your suggestions at all.

Let's talk about clutter first. Right now we have 5 options for each field. The options on the left are generally useful, but obviously, these items will not be toggled back and forth very often. In fact I have to admit that I've never changed the defaults on this left side of the dialog, although I definitively would want to have the option to do so directly shall the need arise. I have to agree, that the items on the right side are much more frequently used, however.

Having this said, you seemingly don't have any problems with having at least half of the checkboxes (and in most of the cases even more) bearing cryptic names, being rarely used and adding clutter to the dialog. Take for instance “Using shell patterns”. It's not obvious to me at all, that if I uncheck this tick, the search engine will use a RegExp? and not an exact string as it would do if I uncheck the “Regular expression” tick.

Now in what concerns the Configuration dialog. Please tell me how it is supposed to work according to you? ~75% of the times, I don't care about the contents of the files and I just search for the file name. In 25% of the cases I would want to filter my search results with a specific string. Same seems to be true for gotar and other participants of the discussion. For Andrew, however, the proportions are opposite, but it does not make any difference (see below).

You want to place “Search for content” in the Configuration dialog. Every time I want the search engine to take the string, coming from the editor into account, instead of typing “h” and Space I have to close the dialog, evoke the menu, evoke the Configuration dialog, check the tick, save it and re-open the search dialog again. This is a perfect example of a completely useless solution that does not actually address the problem,whereas my suggestion will save keystrokes both for me and Andrew.

If you really want to move something to the Configuration dialog, try the “All charsets” ticks out, that I have never ever actually used. I imagine that a person that is using them would either want to always or never use them, and I am not sure whether it makes any sense to introduce the distinction for the search file name and file contents.

Now to the locate etc. You probably know that locate does not actually *search* for files, but rather consults a pre-generated database, which is typically updated on a daily basis? What I usually do is to search in the archives I've just unpacked or sources that I have reorganized. They are just not into the locate database yet and there is no way of regenerating the database every 10 minutes on an underpowered laptop (my mlocate update takes about half an hour on nice -n19 and lowest possible ionice to not to distract me from work)...

You are suggesting mc to use locate or whatever front-end that is available to search for files without adding an option to turn off this behavior, to keep the level of “complexity” to the minimum? Ah, thank you so much for suggesting to fix something that is not broken.

Did you know about “External panelize” command? Add your locate call there and if you need to search for contents use the find file dialog after the locate output has been panelized instead of reinventing the wheel and adding unnecessary complexity to the code...

Z.

[zaytsev]

Andrew, Gotar et al. :

Please check out this out:

Branch: 2046_find_file (parent: master)
Changeset: 4c5ed337686355cad18734bb97028f35012fff62
I have added a “Search for content” checkbox which is off by default to stick to the pre-4.7 behavior. If the checkbox is unchecked, the Content field is just not taken into account.

To toggle the checkbox press h and Space. The checkbox remembers its state across sessions. I would keep it off and turn on when needed which is much quicker than erasing the stuff that got into the Content field manually and Andrew would typically keep it checked.

The look of the dialog is a bit ugly, but if you have better suggestions please let me know. In the last commit I have reorganized the checkboxes for the to look more logical. Please check out the commit messages.

Hope we can consider this as a kick-off in the direction of closing this ticket.

[ossi]

Replying to zaytsev:

you seemingly don't have any problems with having at least half of the checkboxes [...] being rarely used and adding clutter to the dialog.

says who?

You want to place “Search for content” in the Configuration dialog.

says who?

You probably know that locate does not actually *search* for files,

what you say ...?

You are suggesting mc to use locate [...] without adding an option to turn off this behavior

says who?

all in all, your writ is an impressive list of straw mans and other logical fallacies. i have better things to do than debunking it. like sleeping. good night.

[zaytsev]

Replying to ossi:

Replying to zaytsev:

you seemingly don't have any problems with having at least half of the checkboxes [...] being rarely used and adding clutter to the dialog.

says who?

This was the only point you didn't make explicitly :)

You want to place “Search for content” in the Configuration dialog.

says who?

Says you:

uhm, no, that just clutters up the gui.
it isn't any better than a permanent option.

You probably know that locate does not actually *search* for files,

what you say ...?

Says man locate.

You are suggesting mc to use locate [...] without adding an option to turn off this behavior

says who?

See ^{clutter the GUI.}

i have better things to do than debunking it. like sleeping. good night.

Cool~! Have a good night sleep.

[birdie]

I like Yury's solution. ;)

[ossi]

Replying to zaytsev:

Replying to ossi:

Replying to zaytsev:

You want to place “Search for content” in the Configuration dialog.

says who?

Says you:

no, i don't. i said that unnecessary options in the search dialog are just as bad as unnecessary options in the configuration dialog. it may have been ambiguous, but when you choose to imply incompetence and ignorance as you did you better make damn sure that it's not you who's misunderstanding things.

You probably know that locate does not actually *search* for files,

what you say ...?

Says man locate.

learn some english, dude.
and then re-read my original posting.

You are suggesting mc to use locate [...] without adding an option to turn off this behavior

says who?

See ^{clutter the GUI.}

you are seeing things which aren't there. i wonder whether you should worry. ;)

[andrew_b]

New initial changeset:5470ba1a8c5a189fe2026daa3fb72bee262a7c11
Now content search widgets are enable/disabled by 'Search for content' checkbox. Also some search optimization was made.

[andrew_b]

Rebase to recent master. Changed checkbox locations and order.
Initial changeset:541cb9c04f7b797ba68ad09f6b164fa08b0fea21

[angel_il]

Branch: 2046_find_file (forced update)

[zaytsev]

+ 46a0fdc...39e9b9a 2046_find_file -> 2046_find_file (forced update)

Rebased on top of latest master and solved conflicts, as well as updated the commit messages. To me it looks good. Could you guys please review and vote?

Thanks.

[zaytsev]

Committed to master. Merge changeset: 17a2f7116962ace2d42e23a5b65e062e7ac501f6.

[ossi]

so i pulled these changes now. that additional checkbox is even worse than i expected.

• the disabled lineedit looks bizarre (at least in the default color scheme)
• having the checkbox below the lineedit it disables is illogical, and the tabbing order is confusing. you could instead put a checkbox in front of the "Content:" label and change the label to "Search for content:". however, then it would also have to come before the lineedit in the tabbing order, which would enlarge the "distance" to the filename edit again
• the checkbox is useless. especially now that you improved the behavior of line edits, clearing the search text is a matter of pressing <del> (*), and getting it back is <alt-p> as ever (both after pressing <tab> or <down> - hardly a biggie).

(*) it's still inconsistent with regular guis, as they return to "<del> clears" mode every time you navigate into the field, not only before the first edit.

as i'm already at it, here's my idea of sane accelerators: "find _recursively", "regular e_xpression", "_first hit".

fwiw, i don't understand what the "start at:" line edit (incl. the "tree" button) is good for - the natural workflow in mc is navigating to the start directory first (where you have all the usual features like directory hotlist, history, command line - and tree mode if you really want to) and only then hitting <alt-?>. so why create a nested mini-navigator?