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: 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