Re: Seeing <------> instead of tabs - how to disable ?

[kilgota banach math auburn edu]

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