On Sun, 25 Apr 2010, Yury V. Zaytsev wrote:
> 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?
> 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."
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
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. (??!)
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
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"
> > 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.
mc mailing list