Re: Irritations and frustrations with improved(?) search functionality

[Theodore Kilgore <kilgota banach math auburn edu>]

On Sun, 25 Apr 2010, Yury V. Zaytsev wrote:

> Hi!
>
> Sorry for breaking the thread, but your initial post was eaten by my
> Bogofilter (was too long?)...

Catch 22. I am supposed to give a complete description of a problem, and 
then the message is too long. 

> > The F9 menu gives a "Find file" option.
>
> It always used to be the case, but now that the history has been
> unified, it pre-fills the content field be default. 

Why? It appears to me it just gets in the way. Perhaps you need more than 
one content field?

> http://www.midnight-commander.org/ticket/2046
>
> Subject to change.

Quoting a comment there:

"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."

Remarks:

This does not exactly cover everything.

You say above, "now that the history has been unified, it pre-fills the 
content field be default," but the consequence is that "content" appears 
in that "content" window even if the hapless user never did anything to 
put it there. Rather, it has been somehow fetched from God-knows-where, by 
mysterious agencies. Well, actually not from God-knows-where. But still by 
mysterious agencies.

Example:

I am working on a camera driver. I save some debug output. I search for 
the Start of Frame marker ff ff ff ff 55 (using F3 view and then using F7 
or "/"). Lo and behold, next time I use the Find-file option, the file I 
want to find should also contain ff ff ff ff 55. (??!)

My suggestions:

1. The two different kinds of searches are different kinds of searches. 
They should not share the same buffer or history and thus mix things 
together.

2. Search for file by name only is a useful and time-honored feature. It 
was not broken and did not need fixing.

3. Search for file by name, or search for content, or the two combined 
together, may also be a useful feature to somebody. But it should be 
separately enabled from item 2, so that people who just want to search for 
a file can live in peace. How about a specific "Find file with content" 
option?

> > Behavior of content search within a file using "/" or F7 seems to 
> > me to have been seriously degraded from what for years used to 
> > "just work."
>
> Assuming that you are talking about viewer, its forward search does
> wrap, but displays a dialog ("Search done, continue from the
> beginning?") beforehand. 

No, the version I am currently using is wrapping the search without 
warning. That is the problem. I'm fine with a dialog like what you 
describe. But it is not happening. Since we agree completely about what 
ought to happen, consider this a bug report.

Backwards search does not wrap, which might be
> considered as a bug. Open a ticket for that.

So long as there is no dialog about wrapping, I am glad to have one search 
option which does not wrap. Thanks for letting me know. Under the 
circumstances, I am not sure I consider it a bug.


> > This is not a new one. I have mentioned it before on this list but
> > somehow  it has not been fixed. Namely, the two options F7 and "/" in
> > the good old days used to work separately, but now they work
> > together. 
>
> This is arguable. I haven't seen any viewer that explicitly maintains
> two separate search buffers for some weird reason (I guess this mc
> "feature" has not been documented either). The new behavior seems
> logical to me and is a welcome unification.

All I can say is, the old behavior was well liked and well appreciated by 
at least one user -- while it lasted. And the new behavior is not 
necessarily logical or helpful, at all. Have you never wanted to look 
through a file full of C code or assembler for more than one thing at 
once? Something like, search for foo, then bar, then foo then bar ... If 
you have never wanted to do that, can you see why someone else might want 
to? Believe me, it was very nice to have a pair of handy search tools 
which would permit one to do a thing like that. And now they are gone, 
victims of "a welcome unification."

> > So let me say that another thing I found very frustrating did get 
> > fixed in the release I am using. Namely, during several recent
> > versions of MC the content search functions F7 and "/" were 
> > forgetting what one was searching for if one closed one file 
> > and opened another
>
> The magic mantra is "Open and follow a Trac ticket and thine wish shall
> come true".

Well, it's very easy, really. New functionality is all well and good. But 
it should never interfere with old. 

Theodore Kilgore