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

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


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" 

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

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 

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 

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 

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]