On Wed, 21 May 2008, Felix Miata wrote:
> On 2008/05/21 14:26 (GMT+0300) Ian Brown apparently typed: > >>> Do you mean realy the string "<------>" or do you mean the RED >>> Hilighting? > >> I mean really the string. It is not in RED. (it is in light blue). > >> I am using mc for 5 years and also did not encounter a thing like this. >> Moreover, this is a fresh install on fc9, without any tweak or configuration. > >> I would appreciate if somebody can give it a try (installing by yum >> install mc on fc9). > >> On fc8 this does ***not*** happen, > > I really don't understand your complaint. Nothing in the file you are editing > is changed. All that's different is that you see on screen a representation > of the nature of whitespace instead of naked whitespace. When you see blue > dots, you're seeing space characters. When you see <---->, you're seeing a > tab that is 6 spaces long. If you do a setterm -background blue before > starting mc (I have it in.bashrc), you'll hardly be able to tell they are > there. Felix, You say that "Nothing in the file you are editing is changed." That is true. You also say, "All that's different is that you see on the screen a representation of the nature of the whitespace instead of naked whitespace." This is also true, up to a point. However, beyond that point this is *not* true. And there is the problem. Please envision the following, or try it yourself: You have two xterms open, and you are going about your business. In one of these xterms you are running a mail program, say, pine. You are corresponding with the development list of your project, or with another developer. In the second window you are working on some code, which you have opened with the MC editor because you are working on that file and otherwise you like the MC editor. You mouse-copy a section of code and put it into your e-mail message. Lo and behold, you now have every tab marked with these arrows. The individual on the other end may not be using your favorite editor, and he may not understand what has just happened. So you have two undesirable choices. either you now have to go and edit out from your mail message every one of those marks for the Tab characters, which you say are not in fact part of the file but which are present there in what you copied nevertheless, or you have to explain to the person on the other end that what is happening here and that you are sorry for the inconvenience. Now, these are not very good choices, are they? If you do not believe that what I describe will happen, try it yourself. As I said in an earlier message on this topic, the feature of marking the tabs has obvious good in it, and also obvious bad. For those who just could not see the bad previously, I hope that the above sequence explains it. The good in it is also pretty obvious, in that when writing code one really is not supposed to use a bunch of space characters on such occasions when one is supposed to use tabbing. So it is nice to have those things marked differently. Thus, from my perspective the way to go about this would be to figure out how to keep the good without committing the bad. Me, I think there ought to be a way to do that. I seem to recall that the method of marking tabs was done in a different way, at least some of the time, in previous versions of the editor. I seem to recall that in a Makefile there was color coding for tabs. They were, as I recall, bright red bars in front of the tabbed line of the text. Now, even in a Makefile, the bright red bars have been replaced with the <----> kind of thing. I am not so much in favor of bright red. Perhaps the bright red ought to be replaced with some more neutral color, such as pea green or pastel blue, or something like that. But I think that to color-code the tab spaces would be a far better solution than to indulge in using characters which are not part of the file but which sometimes show up most inconveniently, as if they were part of the file. Another way to solve the problems would be, as I said in the earlier post, to make sure that the arrow-for-tabs characters really do not show up in a mouse-copy. Because I cannot imagine, though, how one would go about that, I come up with the alternative suggestion to revive and to expand the formerly-used practice of color coding. Now let me say something else. I think that programming things to make them user-friendly is one of the most difficult things that we do. One of the traps into which we can easily fall is to believe that we have taken everything into account, when we have not. In such circumstances it is often very difficult for us, being mere humans, to be able to imagine what is bothering someone who is offering criticism, is finding our excellent product somehow to be deficient, or is finding our latest progressive innovation to be an interference. Sometimes, we also do not do our work in the same way that a user might do, who is out there using our product, and thus we have never encountered the situation which is aggravating that user. These are traps into which we should not fall. I am to a great extent spared from this particular dilemma, because most of my work is not on the user interface but upon hardware support. Hardware does not talk back and does not complain. Pretty much, it either works or it does not. Therefore, lucky me. Nobody ever has the chance to say to me something like what I put in the previous paragraph. However, I do have to pay attention to the users. While trying to do my work I do sometimes notice inconveniences and glitches like what I have described above. Felix, I am curious. Did you ever encounter what I have described, or do you do your work in such a way that the situation just never came up, as I describe it? Wouldn't you agree, now that the issue has been pointed out, that there is a problem? Theodore Kilgore _______________________________________________ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
