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

["Yury V. Zaytsev" <yury shurup com>]

Hi!

On Sun, 2010-04-25 at 20:17 -0500, Theodore Kilgore wrote:

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

I think you know very well what I am talking about. It's just the
question WHO makes the effort. Either you express your thoughts in a
condensed form, e.g.:

Subject line summarizing each individual annoyance

4.6.x behavior: XXX
4.7.x behavior: YYY

Motivations for keeping consistency with the old behavior. Alternative /
compromise suggestions.

OR I will have to do it for you and subsequently file a Trac ticket, so
that other people can digest it, triage the report and fix the bug. 

The point is that this is certainly much easier for you, being a native
English speaker to make this effort. Also it will leave me with more
time to maybe actually come up with a fix or push these changes in the
development team. 

As you might imagine I'm neither working full time on supporting mc nor
getting paid for it, so it's crucial to optimize the efficiency of the
time I spend triaging bugs.

It's not all about the length per se, it's all about the entropy and the
information transfer function.

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

Because of the technical issues. Before there were three different
search engines with their own set of features and their own bugs. Now we
have just one, but as a side-effect the history of all three is shared
even if it should not be the case.

> 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?

See my last comment to this bug with the historical analysis of this
situation and three suggestions which would probably satisfy both of us
and hopefully the other developers. 

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

It turns out, that / and F7 functions in 4.6.x were documented,
different and didn't share buffers for a reason. In fact, F7 was
"normal" search, while / was explicitly a RegExp search. Now that the
search engine is the same for everybody you can do RegExp searches from
F7.

I am in favor of submitting a Trac ticket to ask to

1) Make / call a RegExp search by default, no matter what was the
previous choice

2) Make separate buffer for /, but keep the history unified.

This leaves us with the question on which buffer should Shift+F7 use and
how to justify efforts to re-implement 2) as apparently you were the
only person using it. 

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

The problem here is that the old code was maintained by the old
developers it wouldn't be an issue. But what happened in fact is that
they have left the code to rot for some five years until it became
completely unmaintainable and now for every small change we need a huge
rewrite instead of a small incremental patch.

There's a huge amount of code duplication, copy and paste bugs and so on
and so forth. And it is not possible to extend this code or even make it
work with newer software stack unless you re-write some parts of it,
e.g. replace three different search engines with one.

What happens is that these rewrites introduce bugs, which is inevitable,
but this is the only way to move forward, because if you don't move
forward you don't stay were you are, but fall behind.

The consensus has been reached that once the transitions have been
completed the reasonable behavior of 4.6.x should be by default mimicked
as closely as possible with only few exceptions in case if it was
clearly buggy or inconsistent.

For this reason terse Trac tickets would be of much more help than the
long rants on the mailing list that only I will read. Does it make any
sense to you?
 
-- 
Sincerely yours,
Yury V. Zaytsev