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

[Theodore Kilgore <kilgota banach math auburn edu>]

On Mon, 26 Apr 2010, Yury V. Zaytsev wrote:

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

Note that this made it possible for the two search functions to be used 
independently of each other.

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. 

Please take seriously my comments about that and try to think of 
situations where you might wish for the same kind of functionality. I 
suspect it would not be difficult to imagine that "If only I could do 
this" and if you stop and think about it, there is probably not any other 
easy way which is readily available. At least, I do not know of such. I 
ask you and the rest of the team please to think about this issue again.

> > [...] 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? 
>
> 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.

Thank you for this description. I was not fully aware how bad the 
situation is. I have certainly done enough coding of my own to be aware of 
what can happen, and you have my sympathy. 

You would also have my help, except that we all must specialize to some 
extent. Sorry that I can not do more than I can do, actually.
 
> 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.

This seems to make sense, only one has to take care about what is 
"reasonable" in a program which is a heavily-used and popular user 
interface. 

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

Yes, and no. It also makes sense to have a discussion about just why one 
would want new-feature X or want old-feature Y back again, since just to 
send in a bug report or feature request does not always explain why. For 
example, you said a couple of posts back

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

I have spent a lot of effort trying to convince you otherwise. I have 
tried to explain why it is a good idea to be able to do two independent 
searches while viewing the same file.

But if you (and, clearly, others actually working on the code) are 
absolutely convinced that the new behavior "seems logical" and "is a 
welcome unification" then what good does it do, exactly, to file an 
official bug report?


Theodore Kilgore