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
