On Fri, 28 Sep 2007, Pavel Tsekov wrote:
> -------- 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, [email protected]
>>> 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.
>>> But I am not sure if this is a desirable feature, or not.
>> it is
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.
(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...
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
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
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.
Mc mailing list