emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proofreading man/custom.texi


From: Joakim Verona
Subject: proofreading man/custom.texi
Date: Mon, 15 Aug 2005 13:45:49 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Here is my attempt at proofreading man/custom.texi.

Its pretty good, and I didnt find anything really obvious from NEWS missing.

I have lots of opinions though, which can mostly be safely
disregarded, that I offer below.


* man/custom.texi

** minor modes

The chosen minor modes are well presented, but it would be nice with a
short comment saying that there are many other minor modes available.

If there was something like a "minor mode" browser, one could point to
that, but I guess there isnt something like that in emacs currently.

*** line 82
the concept "a file's local variables list" hasnt been defined and
could be a link here. 


** custom

*** line 221, 

the "small example" doesnt match what I get in my custom
buffer. Here is what I get:

/- Emacs group: ---------------------------------------------------------\
      [State]: visible group members are all at standard settings.
   Customization of the One True Editor.
   See also [Manual].

Editing group: [Go to Group] 
Basic text editing facilities.

External group: [Go to Group] 
Interfacing to external utilities.

*** line 255
very minor point:
"either click on it with @kbd{Mouse-1}, or move point to it and type
@key{RET}"

I think keybindings should always be described first, and mouse
bindings later, to emphasize emacs keyboard oriented paradigm.

*** keyboard navigation

I find the description of keyboard navigation in custom a bit
confusing.

I guess the confusion is because custom doesnt behave as I would
expect, as compared with other emacs features, so its no real problem
with the manual, more with custom itself.

Let me just briefly explain what I mean, and you can choose to
disregard this comment if you choose.

- I expect "custom" to behave somewhat like "info mode" with regard to
  navigation.

"u" moves "up" the tree as in info. 

"n" and "p" moves to the next and previous editable fields, which
relates to how info behaves, but there is a small problem. If I use
"n" to move to an editable text field, I cant use "n" again to go to
the next. "n" gets inserted in the text field.

"tab" and "shift-tab" seems to work as i expect though. 



In "emacs-w3m" mode, M-] and M-[ keys are used to jump between
editable fields, and TAB moves between all fields, like how
"customize" behaves. IMHO moving in custom buffers would be much
faster if some binding like this existed in custom also, and other
packages would benefit if core emacs set a standard.

The "n" and "p" bindings could be removed, because they dont really
work.

I expect "l" to move to the previous custom node I visited, like in
"info", but it doesnt, and I dont always get to the place I've been
with "u"

*** hooks
around l859, description of adding hooks. To reset hooks you set the
hook variable to nil. Maybe instead describe a recipy using
remove-hook?

** rebinding 

around 1435: the manual states that prefix key "c-c" is
reserved for users, and will never get in the way of anything. I find
that statement odd, since many modes bind keys with prefix c-c.

**  Keyboard Translations
the section describes the problem new users face with "c-h".

Many emacs packagings define "f1" as a help key, which is pretty
convenient. Maybe this can be described in this section?

Very often when I use emacs on a new machine through a  ssh terminal,
the "c-h" binding doesnt work as expected. One can then try "f1" to ee
if that works instead. if not, one can do the rebindings.

** terminal init
in NEWS there is a description of new features to work around TERM
entries that dont report available colors properly:

"The new command-line option --color=MODE lets you specify a standard"

Maybe this could be described in this node.

i didnt get this option working though, so I dont know what the text
should say.





-- 
Joakim Verona
www.verona.se







reply via email to

[Prev in Thread] Current Thread [Next in Thread]