Thank you for your reply. Stephen.
Documentation is important to me. When suggesting that we do something
about the documentation, I'm willing to be a part of fixing it and I am
keeping a list of boulders in the road that I experience so when I get
past them I can leave a sign
for the next guy.
I am willing to be a part of fixing the documentation. But I can only
fix documentation on the (few) things I have explored so far and if I
tried to fix other documentation I would surely get it wrong in some
point and create the problem
I am trying to solve.
I hadn't realized there are 16 variations/configuration decisions of
where things get installed. I started making the ascii chart (that I
was wishing I had in my email, and did think of 4 variations). I will
still finish my chart, because I need it, but I see it will be much less
useful in general than I thought (and maybe only useful to me, at this
point).
I am happy to be told to read the manual. As long as it is specific,
instead of just to read the whole thing. Or if the relevant info is on
a web page, point me to it, please!
Looking back, I probably should have chosen different examples of
documentation that I stumble over. Those were just some that came to
mind in my moment of frustration and were true examples but probably not
the best or clearest ones.
The example of the sumo tarball misunderstanding was just something that
was on my mind because I got the wrong idea a few years a ago from
reading the documentation and only that day I wrote the email figured
out the truth of it. It was from reading the (old?) documentation that
I got the original idea in my head, which was corrected by reading your
email that I quoted yesterday, after I went and looked
at that specific question.
I think you are right about the timing of my example of the wrong Idea I
had for
sumo tarballs. I have the timing wrong in some way there. At one
point on that system I discovered that I had the documentation that I
downloaded from who knows
where and was old when I downloaded it. That may be where I got the
timing wrong, but it is wrong in some way. Sorry. Badly chosen example.
When I said I was looking for variable name help in 2 places "by
different keystrokes" I was referring to the command line help C-h v to
get variable help vs the menu [help][commands, variables, keys][describe
variable] which lists M-? v as the command to do the same thing (but I
wasn't sure it was the same thing after experiencing 3 ways to command
printing that are not the same thing). At the time I didn't have XEmacs
open and didn't want to be too specific without checking and listing the
keystrokes from the menu.
I am glad I suggested 2 new categories of documentation, or I would not
have heard of Phil Sung's Guided Tour. I'm going to look it up as soon
as I get 21.5 up again.
I am encouraged to hear someone else had a problem with getting a valid
ssh key accepted. Being new to open source projects, I just figure it
is me or what I'm doing/not doing when I come across problems like the
ssh key being invalid.
You wrote in your first footnote:
[1] If they are; these days I'm inclined to accept the argument
that
defaulting to the traditional Emacs keymap vs. CUA is a bug, but in
1995 it was not, and even today there are a lot of Emacs users who
believe that the Emacs keymap is more efficient than CUA, so new users
should be "encouraged" to use traditional Emacs keymaps.
I'd like to venture an opinion; I think the choice that shows XEmacs to
be the superior editor in this case is not to "encourage" traditional
XEmacs keymaps, but to have the position that XEmacs is so powerful an
editor that we have many ways to let you work:
--we have an excellent Emacs keymap, it is the default--try it
--you like CUA? XEmacs can do that too, and it is on the menu.
--and we will let you make your own! Here's how...
Make your own is what I eventually did. Making my own is possible
because XEmacs is *so powerful* that I can adapt it to the way I want to
work (which is a moving target as I learn new ways of working).
A person trying out XEmacs might find there are so many of these new
(better) features presented at once that it is daunting, and all the
"encouragements" to use new ideas/ways of working may keep the new
person from answering the question "is this an editor that I can work
with?" with a "yes".
Same with the kill-ring. I see that it has advantages in some
situations, but XEmacs
doesn't "know better" and force me to use it. Because XEmacs is *so
powerful* I can implement a menu+icon bar system for multiple copy/paste
operations. I don't have to use the kill ring if that is not the way I
want to work.
Sometimes there is a delay between presentation of an idea and embracing it.
I am saying that making strange (as in not-familiar) defaults which are
arguably more powerful (and better), may showcase different ideas about
how to work, but if it doesn't _also_ have a familiar way to work, they
may not stick around long enough for the idea to take root that the new
way is better.
You do risk them never choosing to learn/use the new, better features of
XEmacs, but that is part of having a programmable, configurable editor,
eh? That everybody chooses to use it a different way?
Steve Mitchell
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta