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 _______________________________________________ mc mailing list http://mail.gnome.org/mailman/listinfo/mc