Re: Irritations and frustrations with improved(?) search functionality
On Sun, 2010-04-25 at 20:22 -0500, Theodore Kilgore wrote: As I said, the problem is that forward search does not display the dialog which you say is supposed to pop up. It just wraps without any warning at all. This may be fixed in a more recent version than I am using, of course. As to wrapping the backward search, well, as I said in my other message, I do not think that is so terribly important. I would much rather have things fixed which I used to use and they quit working. Than version that you are using is outdated. We are putting a lot of effort to maintain a stable 4.7.0.x branch (relatively) bug free, so if you want an experience that matches 4.6.x as closely as possible in terms of the behavior and stability you should use this instead of random git snapshots of the work in progress. In what concerns backwards wrapping, I checked out on 4.6.x and it didn't wrap either way. I will file a bug for you. I will parse the second message later as I get time. -- Sincerely yours, Yury V. Zaytsev ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Irritations and frustrations with improved(?) search functionality
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 ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Irritations and frustrations with improved(?) search functionality
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
Re: Irritations and frustrations with improved(?) search functionality
Hi! Sorry for breaking the thread, but your initial post was eaten by my Bogofilter (was 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. http://www.midnight-commander.org/ticket/2046 Subject to change. 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. Backwards search does not wrap, which might be considered as a bug. Open a ticket for that. 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. 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. Being more terse will also help a lot. -- Sincerely yours, Yury V. Zaytsev ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Irritations and frustrations with improved(?) search functionality
On Sun, 2010-04-25 at 21:46 +0200, Yury V. Zaytsev wrote: Assuming that you are talking about viewer, its forward search does wrap, but displays a dialog (Search done, continue from the beginning?) beforehand. Backwards search does not wrap, which might be considered as a bug. Open a ticket for that. http://www.midnight-commander.org/ticket/1917 http://www.midnight-commander.org/ticket/2091 -- Sincerely yours, Yury V. Zaytsev ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Irritations and frustrations with improved(?) search functionality
On Sun, 25 Apr 2010, Yury V. Zaytsev wrote: On Sun, 2010-04-25 at 21:46 +0200, Yury V. Zaytsev wrote: Assuming that you are talking about viewer, its forward search does wrap, but displays a dialog (Search done, continue from the beginning?) beforehand. Backwards search does not wrap, which might be considered as a bug. Open a ticket for that. http://www.midnight-commander.org/ticket/1917 http://www.midnight-commander.org/ticket/2091 Yuri, As I said, the problem is that forward search does not display the dialog which you say is supposed to pop up. It just wraps without any warning at all. This may be fixed in a more recent version than I am using, of course. As to wrapping the backward search, well, as I said in my other message, I do not think that is so terribly important. I would much rather have things fixed which I used to use and they quit working. Theodore Kilgore ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
