Re: mc Digest, Vol 102, Issue 3

[Theodore Kilgore <kilgota banach math auburn edu>]

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