On Fri, 28 Sep 2007, Pavel Tsekov wrote:
> Hello, > > -------- Original-Nachricht -------- >> Datum: Fri, 28 Sep 2007 22:51:05 +0200 >> Von: Oswald Buddenhagen >> Betreff: Re: GNU Midnight Commander 4.6.2-pre1 > >> On Thu, Sep 27, 2007 at 11:01:27PM -0500, [EMAIL PROTECTED] >> wrote: >>> Notice the <------> things in what I just copied? >>> >>> I can kindof see why this was introduced. Presumably, it is an >>> indication that the TAB key has been used while the file from which I >>> copied was being written. >>> >> yes >> >>> But I am not sure if this is a desirable feature, or not. >>> >> it is Oswald, On what grounds? I said I can "kindof see why this was introduced." You are saying it not only has some kind of logic behind it that I could "kindof see" but it is indeed a good idea. Why? If it is a good idea then there is no doubt a good explanation. Jesus, it is written, "broke bread" with the disciples, as did his forefathers with their families and guests. Nowadays, we chase the bread with a knife, or subject it to a slicing machine. We are more complicated and sophisticated and require lots more technology to deal with the bread. Does our bread taste better or is its nutritional content improved? Does this analogy fit? That is also a good question. >> >>> I can easily think that, if I want to copy a block of C code from one >>> file to another using the mouse, I would feel quite frustrated if this >>> is what actually happens with every line where the tab key got used. >>> >> just mark the text within mcedit before marking it with the mouse. Interesting. (Checking if this really works, or not ... yes it does ... ) Yes, interesting indeed. Is this documented anywhere? >> >> but yes, this needs a fix. ctrl-w was supposed to toggle this >> *temporarily*, just like ctrl-s toggles syntax highlighting (not >> temporarily, which is a bug, imo). more on this can be found in the >> respective patch tracker entry. > Are these key combinations documented anywhere? I have looked rather carefully and I have not found any mention of them in the man page for mcedit, nor in the F1 help for mcedit, nor in the pulldown menus which the F1 help says to look at, nor in the Syntax file which users are encouraged in the F1 help to look at, nor in the c.syntax file in /usr/share/mc/syntax. Is the documentation in some other location which I should have checked? > I'll fix these... I just need some time. I am trying to extract and > describe all those changes that happened between 4.6.1 and the current > cvs version. I am also trying to fix the copyright notices in all files. > You can open an bug report in the tracker if you want... Pavel, I can understand your problems, as in a small way I have to deal with similar things occasionally, and I am not even one of the project leaders over at gphoto. So by all means take the appropriate time and get it all right. One never shoots at the piano player, because then the music stops. I will open a bug report if that is needed, so you can be the judge about that. Or Oswald could do it. As he was so kind as to answer my questions, he may be much more knowledgeable and closer to the MC project than I am. OTOH there is the perhaps deeper question about whether one is dealing with a bug or a feature, which is the focus of what follows. For, if it is a feature then it is no bug, though it still may be or may not be a feature in need of some improvement. I do have some (possibly naive) things to say about this, though, purely as a user. Perhaps someone with sufficient knowledge _and_ with the time to answer could address these things. Therefore, what follows is directed to the list, not to the maintainer and release manager who may be at this point up to his ass in alligators and not have time to think about much of anything at all except impending deadlines. 1. Perhaps the <-------> stuff for tabs is good. Me, I liked better the old syntax which used a red, colored bar but that I did not see except in a Makefile. I mean, there was no particular syntax construction to distinguish a tab or two from the repeated use of the spacebar if one was looking at a .c or .h file. And, yes, we know that indentations in a .c or .h file are to be done with the tab key and to do code indentations with the spacebar is considered as incorrect and bad practice. But since it is incorrect and bad practice to use the space bar, it would seem to me that very few people will do that (and sinners and ignoramuses will get caught and educated by the project manager the first time that they submit code, as happened to me a few years ago). So why is it exactly needed to put into an editor a special mark showing that the tab has been used? As I said, I can see why it might be thought a clever feature, but is it actually necessary? And if not necessary is it desirable? Mind, I do not have the answers nor claim to have the answers. I am merely asking the questions. I hope I am not stomping on the toes of someone, just by asking the questions, who may have spent weeks to figure out how to code this. 2. For the purposes of this second question, let us assume that the marking of tabs by ghostly, semi-visible <-----> symbols is put into the editor. Then I ask, why is it good to copy the <----->s into another file with a mouse-copy? The tabs of course ought to be copied. Naturally. But why should the <-----> which is an invisible part of the original file and a ghostly indication of tabs in the file opened by the editor, get copied as a literal and visible <------> which now uses characters that show up on the screen? I mean, in the original .c file used in the example I sent in previous e-mail, there are tabs. There are no <------>s appearing in the file if one views it, opens it with some other editor, or prints a hard copy on paper. But if one mouse-copies from the file then why do the otherwise invisible tabs have to get mapped to real < and - and > characters? Assuming that this result is anticipated and intended, then what is the reasoning which leads to doing this? Or is it the case that it would perhaps be better to copy the tabs (invisibly, as creating the appropriate whitespace) and not literally to copy the "ghost characters" which stand for tabs, and thereby make those "ghost characters" to come to life and haunt us? I did not say in my previous e-mail that this is exactly a bug. It may not be a bug, but a feature. But I am out here in userland. So why is it a feature and not a bug? Why and how does this make the internal editor more user-friendly and helpful? Who would really want to create a bunch of <-----> symbols in the copy output, and under what circumstances? I cannot visualize anyone actually wanting to do that, except for purposes of a demonstration. Am I wrong? Help me understand. 3. If you want to introduce new phenomena in the software, then it is good if these things are documented somewhere. As I have indicated above, I just now looked for the documentation of these features in what seemed to me to be the logical places and I could not find anything. Let me add that MC has got more features already built in than people know how to use. I could give several more examples of this but a long letter would get even longer. One of the reasons why the documentation needs to be dealt with, which you might not think I am thinking of, is that if people do not know features X, Y, and Z are already implemented here, then those people may go off and waste a lot of effort in writing new software to re-invent the wheel and introduce features X, Y, and Z "for the first time" because, allegedly, nobody ever thought of X, Y, or Z before. What a waste if that happens. To close, I hope that these comments are taken in the way that I meant them, in a constructive spirit. I hope that no one who reads this can find in it any negative undertones. For, I meant none. I am also aware of the fact that to keep up with a project's code and functions with the documentation is very difficult. Moreover, to provide documentation which is complete can often interfere with readability and usability by those who do not already know the answers, as witness the question about the bindings file from yesterday, which question _is_ answered in the documentation. I do think that good, complete, and truly helpful documentation is one of the greatest challenges in software development. As far as I can tell, there are no good models to emulate. Thys, I am not comparing our documentation to that produced by others. In particular, let me mention that a certain Big Software Company is often praised to the skies for its documentation, which I have found to be practically useless any time I actually tried to use it. Again, comparisons with others are no measure of what ought to be done nor of what standards ought to apply. The only valid comparison is between what is and what ought to be. Theodore Kilgore _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
