Re: GNU Midnight Commander 4.6.2-pre1

[kilgota banach math auburn edu]

On Fri, 28 Sep 2007, Pavel Tsekov wrote:

> Hello,
>
> -------- Original-Nachricht --------
> > Datum: Fri, 28 Sep 2007 22:51:05 +0200
> > Von: Oswald Buddenhagen
> > Betreff: Re: GNU Midnight Commander 4.6.2-pre1
>
> > On Thu, Sep 27, 2007 at 11:01:27PM -0500, kilgota banach math auburn edu
> > wrote:
> > > Notice the <------> things in what I just copied?
> > >
> > > I can kindof see why this was introduced. Presumably, it is an
> > > indication that the TAB key has been used while the file from which I
> > > copied was being written.
> > yes
> >
> > > But I am not sure if this is a desirable feature, or not.
> > it is

Oswald,

On what grounds? I said I can "kindof see why this was introduced." You 
are saying it not only has some kind of logic behind it that I could 
"kindof see" but it is indeed a good idea. Why? If it is a good idea then 
there is no doubt a good explanation.

Jesus, it is written, "broke bread" with the disciples, as did his 
forefathers with their families and guests. Nowadays, we chase the bread 
with a knife, or subject it to a slicing machine. We are more complicated 
and sophisticated and require lots more technology to deal with the bread. 
Does our bread taste better or is its nutritional content improved? Does 
this analogy fit? That is also a good question.

> > > I can easily think that, if I want to copy a block of C code from one
> > > file to another using the mouse, I would feel quite frustrated if this
> > > is what actually happens with every line where the tab key got used.
> > just mark the text within mcedit before marking it with the mouse.

Interesting.

(Checking if this really works, or not ... yes it does ... )

Yes, interesting indeed. Is this documented anywhere?

> > but yes, this needs a fix. ctrl-w was supposed to toggle this
> > *temporarily*, just like ctrl-s toggles syntax highlighting (not
> > temporarily, which is a bug, imo). more on this can be found in the
> > respective patch tracker entry.

Are these key combinations documented anywhere? I have looked rather 
carefully and I have not found any mention of them in the man page for 
mcedit, nor in the F1 help for mcedit, nor in the pulldown menus which the 
F1 help says to look at, nor in the Syntax file which users are encouraged 
in the F1 help to look at, nor in the c.syntax file in 
/usr/share/mc/syntax. Is the documentation in some other location which I 
should have checked?

> I'll fix these... I just need some time. I am trying to extract and 
> describe all those changes that happened between 4.6.1 and the current 
> cvs version. I am also trying to fix the copyright notices in all files. 
> You can open an bug report in the tracker if you want...

Pavel,

I can understand your problems, as in a small way I have to deal with 
similar things occasionally, and I am not even one of the project leaders 
over at gphoto. So by all means take the appropriate time and get 
it all right. One never shoots at the piano player, because then the music 
stops.

I will open a bug report if that is needed, so you can be the judge about 
that. Or Oswald could do it. As he was so kind as to answer my questions, 
he may be much more knowledgeable and closer to the MC project than I am. 
OTOH there is the perhaps deeper question about whether one is dealing 
with a bug or a feature, which is the focus of what follows. For, if it is 
a feature then it is no bug, though it still may be or may not be a 
feature in need of some improvement.

I do have some (possibly naive) things to say about this, though, purely 
as a user. Perhaps someone with sufficient knowledge _and_ with the 
time to answer could address these things. Therefore, what follows is 
directed to the list, not to the maintainer and release manager who may be 
at this point up to his ass in alligators and not have time to think about 
much of anything at all except impending deadlines.

1. Perhaps the <-------> stuff for tabs is good. Me, I liked better the 
old syntax which used a red, colored bar but that I did not see except in 
a Makefile. I mean, there was no particular syntax construction to 
distinguish a tab or two from the repeated use of the spacebar if one was 
looking at a .c or .h file. And, yes, we know that indentations in a .c or 
.h file are to be done with the tab key and to do code indentations with 
the spacebar is considered as incorrect and bad practice. But since it is 
incorrect and bad practice to use the space bar, it would seem to me that 
very few people will do that (and sinners and ignoramuses will get caught 
and educated by the project manager the first time that they submit code, 
as happened to me a few years ago). So why is it exactly needed to put 
into an editor a special mark showing that the tab has been used? As I 
said, I can see why it might be thought a clever feature, but is it 
actually necessary? And if not necessary is it desirable? Mind, I do not 
have the answers nor claim to have the answers. I am merely asking the 
questions. I hope I am not stomping on the toes of someone, just by asking 
the questions, who may have spent weeks to figure out how to code this.

2. For the purposes of this second question, let us assume that the 
marking of tabs by ghostly, semi-visible <-----> symbols is put into the 
editor. Then I ask, why is it good to copy the <----->s into another file 
with a mouse-copy? The tabs of course ought to be copied. Naturally. But 
why should the <-----> which is an invisible part of the original file 
and a ghostly indication of tabs in the file opened by the editor, get 
copied as a literal and visible <------> which now uses characters that 
show up on the screen? I mean, in the original .c file used in the example 
I sent in previous e-mail, there are tabs. There are no <------>s 
appearing in the file if one views it, opens it with some other editor, or 
prints a hard copy on paper. But if one mouse-copies from the file then 
why do the otherwise invisible tabs have to get mapped to real < and - and 
> characters? Assuming that this result is anticipated and intended, then 
what is the reasoning which leads to doing this? Or is it the case that it 
would perhaps be better to copy the tabs (invisibly, as creating the 
appropriate whitespace) and not literally to copy the "ghost characters" 
which stand for tabs, and thereby make those "ghost characters" to come to 
life and haunt us? I did not say in my previous e-mail that this is 
exactly a bug. It may not be a bug, but a feature. But I am out here in 
userland. So why is it a feature and not a bug? Why and how does this make 
the internal editor more user-friendly and helpful? Who would really want 
to create a bunch of <-----> symbols in the copy output, and under what 
circumstances? I cannot visualize anyone actually wanting to do that, 
except for purposes of a demonstration. Am I wrong? Help me understand.

3. If you want to introduce new phenomena in the software, then it is good 
if these things are documented somewhere. As I have indicated above, I 
just now looked for the documentation of these features in what seemed to 
me to be the logical places and I could not find anything. Let me add that 
MC has got more features already built in than people know how to use. I 
could give several more examples of this but a long letter would get even 
longer. One of the reasons why the documentation needs to be dealt with, 
which you might not think I am thinking of, is that if people do not know 
features X, Y, and Z are already implemented here, then those people may 
go off and waste a lot of effort in writing new software to re-invent the 
wheel and introduce features X, Y, and Z "for the first time" because, 
allegedly, nobody ever thought of X, Y, or Z before. What a waste if that 
happens.

To close, I hope that these comments are taken in the way that I meant 
them, in a constructive spirit. I hope that no one who reads this can find 
in it any negative undertones. For, I meant none. I am also aware of the 
fact that to keep up with a project's code and functions with the 
documentation is very difficult. Moreover, to provide documentation which 
is complete can often interfere with readability and usability by those 
who do not already know the answers, as witness the question about the 
bindings file from yesterday, which question _is_ answered in the 
documentation. I do think that good, complete, and truly helpful 
documentation is one of the greatest challenges in software development. 
As far as I can tell, there are no good models to emulate. Thys, I am not 
comparing our documentation to that produced by others. In particular, let 
me mention that a certain Big Software Company is often praised to the 
skies for its documentation, which I have found to be practically useless 
any time I actually tried to use it. Again, comparisons with others are no 
measure of what ought to be done nor of what standards ought to apply. The 
only valid comparison is between what is and what ought to be.


Theodore Kilgore