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: Colors on MC 4.7.0.1 are *really* a mess, seconded
--- On Sun, 4/18/10, Frank McCormick bea...@videotron.ca wrote: From: Frank McCormick bea...@videotron.ca Subject: Re: Colors on MC 4.7.0.1 are *really* a mess, seconded To: Hugo Vanwoerkom hvw59...@yahoo.com Cc: mc@gnome.org Date: Sunday, April 18, 2010, 2:29 PM On Sun, 18 Apr 2010 12:30:17 -0700 (PDT) Hugo Vanwoerkom hvw59...@yahoo.com wrote: Hi, Mc user ever since the beginning. Running on Debian Sid. Which upgraded mc to 4.7.0.1. And the colors are a *mess* as I reported to Debian userlist: http://lists.debian.org/debian-user/2010/04/msg00315.html Nothing now works as before. As noted on this list: http://mail.gnome.org/archives/mc/2010-March/msg00028.html and a recent Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567119 My color scheme was in the ini file: [Colors] base_color=executable=blue,white:viewunderline=yellow,black:normal=red,white:selected=lightgrey,lightgreen:marked=cyan,black:markselect=white,lightgreen:directory=black,white:link=red,white:device=lightgrey,black:special=cyan,black That translates in 4.7.0.1 to something that gives an instantaneous splitting headache. Try this skin Hugo. put it in ~/.mc/skins call mc with: mc --skin=special I **think** it's what you want. [skin] description=Dark Far skin [Lines] lefttop=╔ righttop=╗ centertop=╤ centerbottom=╧ leftbottom=╚ rightbottom=╝ leftmiddle=╟ rightmiddle=╢ centermiddle=┼ horiz=═ vert=║ thinhoriz=─ thinvert=│ [core] _default_=black;white selected=black;cyan marked=yellow;black markselect=yellow;cyan gauge=white;black input=black;cyan reverse=lightgray;black [dialog] _default_=brightcyan;blue dfocus=blue;cyan dhotnormal=white; dhotfocus=white;cyan [error] _default_=white;red errdhotnormal=yellow;red errdhotfocus=yellow;lightgray [filehighlight] directory=gray; executable=brightmagenta; symlink=lightred; stalelink=brightred; device=brightmagenta; special=black; core=red; temp=gray; archive=brightgreen; doc=brown; source=cyan; media=green; graph=brightcyan; database=brightred; [menu] _default_=lightgray;blue menuhot=white;blue menusel=black;cyan menuhotsel=white;cyan menuinactive=black;white [help] _default_=black;lightgray helpitalic=red;lightgray helpbold=blue;lightgray helplink=black;cyan helpslink=yellow;blue [editor] _default_=lightgray;black editbold=yellow;brightgreen editmarked=black;white editwhitespace=brightblue;black linestate=white;cyan bookmark=white;red bookmarkfound=black;green [viewer] viewunderline=brightred;black [buttonbar] hotkey=red;white button=black;white [widget-common] sort-sign-up=↑ sort-sign-down=↓ [widget-panel] hiddenfiles-sign-show = • hiddenfiles-sign-hide = ○ history-prev-item-sign = ← history-next-item-sign = → history-show-list-sign = ↓ [widget-scollbar] first-vert-char=↑ last-vert-char=↓ first-horiz-char=« last-horiz-char=» current-char=■ background-char=▒ -- Frank McCormick bea...@videotron.ca Thanks Frank, sorry that it took a while to respond. The reason that I made the original post is that when I use: [Colors] base_color=executable=blue,white:viewunderline=yellow,black:normal=red,white:selected=lightgrey,lightgreen:marked=cyan,black:markselect=white,lightgreen:directory=black,white:link=red,white:device=lightgrey,black:special=cyan,black linux= color_terminals= which look in mc 4.6.2-pre1 like this: http://www.esnips.com/doc/fc65cf70-f688-448d-ba45-c6d6dfc1a9bf/mc-dir-menu then it looks like this in mc 4.7.0.1: http://www.esnips.com/doc/12bc56c7-953e-493e-8deb-061649b42f1e/mc-dir-menu-4701oldini. mcedit looks in 4.6.2-pre1 with those colors in ini like this: http://www.esnips.com/doc/ff64545d-2e9a-40b1-9119-027c8f9ffce8/mc-edit and like this in mcedit of 4.7.0.1: http://www.esnips.com/doc/84c1c52f-2c36-4167-b3bf-d7d2ba557a96/mc-edit-4701oldini Now your reworked darkfar looks in a directory like this: http://www.esnips.com/doc/8a085ae5-533b-4638-b8c2-f6fc28a9238a/mc-dir-copy-4701frank Note the copy menu. In 4.6.2-pre1 with my colors that looks like: http://www.esnips.com/doc/60df64d4-6bab-4837-9537-3b053cd53d8b/mc-dir-copy But the problem is bigger in mcedit. With the reworked darkfar skin that looks like: http://www.esnips.com/doc/39e00bf7-49bc-4c82-8f00-3abb316abbf6/mc-edit-4701frank Thanks again. Hugo ___ 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
