On Thu, 11 Oct 2012, chris glur wrote:
> Can we switch-off mcedit's <ghost tab marks> ? > So that when we paste like:----------- > -i --ignore-case > <------> Ignore case differences in file contents. > > --ignore-file-name-case > <------> Ignore case when comparing file names. > ------------------------------------------ > we don't carry the spurious > "<------>" > which are apparently supposed to show that <tabs> were used. Yes, they do represent <tabs> and they are not exactly spurious. There is a problem which I wish were fixed, as described in the next paragraph, but they are quite useful nevertheless. Have you ever written code using mcedit? For example, code for the kernel, where using the space bar to create indentation is a big no-no, an explicit violation of the kernel coding style, and it will get your code patch rejected? And as to the question of sticking in invisible characters, such as a small "." to signify one use of the space bar, that can be important, too. For example, if you indentation looks like ........ instead of <--------> you have used eight hits on the space bar instead of two tabs. Fix it. Moreover, another of the big no-nos in kernel coding is a "trailing whitespace" at the end of a line. If you have committed this, which is very easy to do, then your one whitespace character shows up at the end of the line as a trailing "." in mcedit. Delete it. For kernel coding style, the last visible character on the line is supposed to be followed immediately by a carriage return and then you see nothing trailing the text at the end of the line. But in both of these circumstances if the invisible characters show up in the file in no way at all, then how is it possible to find them and fix the mistakes? It isn't. The above issues are reason enough to have these two items to show up in an editor, if that editor is going to be used for coding. They are thus definitely not present "for artistic only reasons." This being said, imagine the following scenario in which the presence of these features is definitely bad: You are writing some program, where the two features I itemized are a big help in doing everything right. You want to extract some lines of code from that work and mouse-copy it into an e-mail which you are sending to someone else, perhaps intending for the receiving party either to make some intelligent comments about those lines, or asking him to drop it into his local copy and try out what you did. So, you copy into the e-mail using the mouse. And lo and behold every indented line of the code starts with <--------> because somehow the mouse is not able to distinguish this, which shows up in faint white characters in mcedit, from text which "really is there and is visible." Most definitely, that is an irritation. Similar bad afflictions occur if one is going to mouse-copy some lines of code from one file to another, too. Thus, to me what would appear to be the very nicest solution that I can imagine would be to have a setting where the invisible characters show up in mcedit but if one is going to do mouse cut-and-paste then the mouse does not "see" the invisible characters and makes no attempt to copy them. I understand that it is possible to turn the showing of invisible characters on or off, but I would ask for more, possibly a third setting in which they show up and then automatically they do not get sent along as ordinary, visible characters if portions of the file are copied with the mouse. > > Too smart-ass facilities, which are for artistic only reasons, > and can't be switched off are of NEGATIVE value: like auto-indent, > or absurdly breaking words, like "be-cause" just to get > news-paper-like uniformly-spaced-columns, or *.pdf when. > plain-text is adequate and better. > > BUG !! After using <spell check> via mcedit,. > cursor-moving-keys cause characters to be written. > And amazingly this fault stays with the file, even after > it's saved and re-opened later. So it looks as if an > attribute, like. > <interpret all cursor-arrows as eg. "AB"..> > is <carried> with THAT previously ispelled-file. Yes, that does sound bad. I never experienced it. I tend to avoid using spell-check because I am old-fashioned and do not trust a program to do that kind of work. But if what you describe is happening I would agree it is a bug. However, my main point was that there are good, user-friendly reasons for having some of the invisible characters in a file to be "semi-visible" in an editor. Now if only the mouse could be trained not to copy them ... Theodore Kilgore _______________________________________________ mc mailing list https://mail.gnome.org/mailman/listinfo/mc