* rcirc manual @ 2006-01-09 17:47 Björn Lindström 2006-01-13 11:21 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Björn Lindström @ 2006-01-09 17:47 UTC (permalink / raw) Cc: kensanata, rcyeske [-- Attachment #1: Type: text/plain, Size: 435 bytes --] Here's a manual for the recently included rcirc IRC client. The responsible parties are Alex Schroeder Björn Lindström (me) Alex is already an Emacs developer, and I have just sent a request for a form to assign@gnu.org. I hope that my first attempt at Texinfo isn't too awful, and that it can be included in Emacs as soon as the paperwork is done. Suggestions for improvements are much welcomed. Here it is: [-- Attachment #2: rcirc manual --] [-- Type: application/x-texinfo, Size: 17915 bytes --] [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-09 17:47 rcirc manual Björn Lindström @ 2006-01-13 11:21 ` Eli Zaretskii 2006-01-13 14:10 ` Alex Schroeder ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Eli Zaretskii @ 2006-01-13 11:21 UTC (permalink / raw) Cc: rcyeske, kensanata, emacs-devel > From: bkhl@member.fsf.org (=?utf-8?Q?Bj=C3=B6rn_Lindstr=C3=B6m?=) > Date: Mon, 09 Jan 2006 18:47:56 +0100 > Cc: kensanata@gmail.com, rcyeske@gmail.com > > Here's a manual for the recently included rcirc IRC client. Thanks! > Suggestions for improvements are much welcomed. Below. > @setfilename rcirc.info Manuals bundled with Emacs need to say this: @setfilename ../info/rcirc to produce the Info manual in the `info' subdirectory. We also usually drop the .info extension, to minimize file-name related problems in restricted environments. > rcirc is an Emacs IRC client. I suggest to use @code{rcorc} throughout the manual, so that the name of the package stands out of the other text. > * Skipping @code{/away} messages using handlers:: Using @-commands in node names is an absolute no-no in Texinfo. Look at the Index node, and you will see that the name of this node loses the `..' markup (produced from @code) in the Index references. This means that index entries in this node will not work. You need to remove the @code markup from the node name and from all its references in all the menus and cross-references. > Since this is so common, you can use TAB to do nick completion. I'd suggest @kbd{TAB} here, since this is what the user types. > This is the reference section of the manual. It is not complete. For > complete listings of rcirc features, use Emacs built-in documentation. Please make sure there are two blanks after each dot that ends a sentence. > IRC buffers are constantly growing. If you want to see as much as > possible at all times, you would want the prompt at the bottom of the > window when possible. The following snippet uses a local value for > @code{scroll-conservatively} to achieve this: Options and features explained elsewhere in the Emacs documentation should have an @xref cross-reference leading to them. Suppose that whoever reads this does not know what scroll-conservatively is--we won't want them to waste their time searching the entire Emacs documentation suite, right? The same comment is relevant to Flyspell you mention. Finally, I'd suggest to invest some more effort in indexing. The current indexing covers the commands and options, but it Needs More Work (tm) in the concept index area. To add more helpful indexing, re-read the manual, and for each paragraph, ask yourself what phrases would the reader think about if she wanted to find this specific information. Then add @cindex entries for those phrases. For example, here: > @item C-c C-r > @kindex C-c C-r > @cindex /nick > This changes your nick to some other name. Your nick must be unique > across the network. Most networks don't allow too many nick changes in > quick succession, and have restrictions on the valid characters in nick > names. (Also @code{/nick alex-test}) I'd add 2 entries: @cindex change nick @cindex nick, how to change because, if I were to look for a way to change my nick, these are the phrases I'd think about. When done in this way, an index will help people use the manual as a reference, when they need to quickly find a specific piece of information without wading through the whole document. > @node Reference, Hacking and Tweaking, Basic Usage, Top > @chapter Reference > @cindex reference This index entry is too general to be useful. Reference to what? > @node rcirc commands, Useful IRC commands, Reference, Reference > @section rcirc commands > @cindex commands Too general. A better index entry would be @cindex rcirc commands > ignoring. All messages by ignored nicks are -- you guessed it -- You want an em-dash here, so you should use ---, three dashes in a row, not two. > @node Useful IRC commands, Configuration, rcirc commands, Reference > @section Useful IRC commands > @cindex irc commands > @cindex commands First, you already had a "@cindex commands" before. Having multiple index entries which have the same names is not a very good idea, since the reader will not easily know which entry to choose. It is better to qualify each one of such entries with some additional info. For example: @cindex commands, frequently-used However, in this case, just removing this entry is good enough, since the other one, @cindex irc commands, does the job. > @node Configuration, , Useful IRC commands, Reference > @section Configuration > @cindex configuration Again, this index entry is too general. "configuring rcirc" would be better. I'd also add @cindex rcirc options or some such. > @node Hacking and Tweaking, Key Index, Reference, Top > @chapter Hacking and Tweaking > @cindex hacking and tweaking > > Here are some examples of stuff you can do to configure rcirc. This chapter is nice, but without good indexing for each trick, there's no hope that users will ever be able to find this information when they most need it, i.e. in a hurry. > @cindex defining commands > @cindex commands Again, the second index entry is redundant and should be removed. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 11:21 ` Eli Zaretskii @ 2006-01-13 14:10 ` Alex Schroeder 2006-01-13 15:08 ` Eli Zaretskii 2006-01-14 16:14 ` Richard M. Stallman 2006-01-13 15:48 ` Thien-Thi Nguyen 2006-01-23 0:09 ` Alex Schroeder 2 siblings, 2 replies; 23+ messages in thread From: Alex Schroeder @ 2006-01-13 14:10 UTC (permalink / raw) Cc: Björn Lindström, rcyeske, emacs-devel Thanks for the feedback on the manual, Eli. As for the em dash suggestion: Is there a convention or tradition for the GNU manuals to prefer em dashes? I'm reading The Elements of Typographical Style by Robert Bringhurst, at the moment. On p 80 he says: "The em dash is the nineteenth-century standard, still prescribed in many editorial style books, but the em dash is too long for use with the best text faces. [...] Used as a phrase marker -- thus -- the en dash is set with a normal word space either side." I think in European typography in general, em dashes are rarely used. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 14:10 ` Alex Schroeder @ 2006-01-13 15:08 ` Eli Zaretskii 2006-01-13 15:11 ` Alex Schroeder 2006-01-14 16:14 ` Richard M. Stallman 1 sibling, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2006-01-13 15:08 UTC (permalink / raw) Cc: bkhl, rcyeske, emacs-devel > Date: Fri, 13 Jan 2006 15:10:13 +0100 > From: Alex Schroeder <kensanata@gmail.com> > > Thanks for the feedback on the manual, Eli. You're welcome. > As for the em dash suggestion: Is there a convention or tradition for > the GNU manuals to prefer em dashes? What would you use instead? en-dash? The Texinfo manual says that en-dash is used in numerical ranges, which is not what we want here. And yes, GNU manuals use em-dash, although I don't know whether this is mandatory. The Texinfo manual, which is a de-facto standard for GNU manuals, says to use em-dash. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 15:08 ` Eli Zaretskii @ 2006-01-13 15:11 ` Alex Schroeder 0 siblings, 0 replies; 23+ messages in thread From: Alex Schroeder @ 2006-01-13 15:11 UTC (permalink / raw) Cc: bkhl, rcyeske, emacs-devel > What would you use instead? en-dash? The Texinfo manual says that > en-dash is used in numerical ranges, which is not what we want here. Yeah, I would use SPC en dash SPC, or SPC -- SPC in texinfo. But using em dash is fine with me as well, if that is the recommendation for the GNU project. I was just curious because I had recently read the Bringhurst book which said that using em dash in this situation was "old school". ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 14:10 ` Alex Schroeder 2006-01-13 15:08 ` Eli Zaretskii @ 2006-01-14 16:14 ` Richard M. Stallman 1 sibling, 0 replies; 23+ messages in thread From: Richard M. Stallman @ 2006-01-14 16:14 UTC (permalink / raw) Cc: bkhl, eliz, rcyeske, emacs-devel As for the em dash suggestion: Is there a convention or tradition for the GNU manuals to prefer em dashes? We use em dashes following generally TeX recommendations. I'd rather not consider the question of changing this practice. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 11:21 ` Eli Zaretskii 2006-01-13 14:10 ` Alex Schroeder @ 2006-01-13 15:48 ` Thien-Thi Nguyen 2006-01-13 15:55 ` Eli Zaretskii 2006-01-23 0:09 ` Alex Schroeder 2 siblings, 1 reply; 23+ messages in thread From: Thien-Thi Nguyen @ 2006-01-13 15:48 UTC (permalink / raw) Cc: Björn Lindström, kensanata, rcyeske, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I'd suggest @kbd{TAB} here, since this is what the user types. i also see @key{TAB} in several places in the other .texi files, at least an order of magnitude more frequently, too. thi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 15:48 ` Thien-Thi Nguyen @ 2006-01-13 15:55 ` Eli Zaretskii 2006-01-13 22:16 ` Robert J. Chassell 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2006-01-13 15:55 UTC (permalink / raw) Cc: bkhl, kensanata, rcyeske, emacs-devel > Cc: bkhl@member.fsf.org (=?iso-8859-1?q?Bj=F6rn_Lindstr=F6m?=), > rcyeske@gmail.com, > kensanata@gmail.com, emacs-devel@gnu.org > From: Thien-Thi Nguyen <ttn@gnu.org> > Date: 13 Jan 2006 10:48:42 -0500 > > Eli Zaretskii <eliz@gnu.org> writes: > > > I'd suggest @kbd{TAB} here, since this is what the user types. > > i also see @key{TAB} in several places in the other .texi files, > at least an order of magnitude more frequently, too. @key{TAB} is typeset to show an image of a key on a keyboard. I think it is not the right markup in this case, because this manual does not talk about keys, it talks about typing a TAB. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 15:55 ` Eli Zaretskii @ 2006-01-13 22:16 ` Robert J. Chassell 2006-01-14 8:51 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Robert J. Chassell @ 2006-01-13 22:16 UTC (permalink / raw) @key{TAB} is typeset to show an image of a key on a keyboard. I think it is not the right markup in this case, because this manual does not talk about keys, it talks about typing a TAB. >From the Texinfo Manual: (texinfo)kbd Use the `@kbd' command for characters of input to be typed by users. For example, to refer to the characters `M-a', write: @kbd{M-a} and to refer to the characters `M-x shell', write: @kbd{M-x shell} (texinfo)key Use the `@key' command for the conventional name for a key on a keyboard, as in: @key{RET} You can use the `@key' command within the argument of an `@kbd' command when the sequence of characters to be typed includes one or more keys that are described by name. For example, to produce `C-x <ESC>' you would type: @kbd{C-x @key{ESC}} -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 22:16 ` Robert J. Chassell @ 2006-01-14 8:51 ` Eli Zaretskii 2006-01-14 12:20 ` Robert J. Chassell 2006-01-15 7:49 ` Richard M. Stallman 0 siblings, 2 replies; 23+ messages in thread From: Eli Zaretskii @ 2006-01-14 8:51 UTC (permalink / raw) Cc: karl, emacs-devel > Date: Fri, 13 Jan 2006 22:16:23 +0000 (UTC) > From: "Robert J. Chassell" <bob@rattlesnake.com> > > @key{TAB} is typeset to show an image of a key on a keyboard. I > think it is not the right markup in this case, because this manual > does not talk about keys, it talks about typing a TAB. > > >From the Texinfo Manual: Bob, I know what the Texinfo manual says about this issue, I just think it's not 100% clear what it means in practice. For example, you could use either @kbd{M-@key{x}} or @kbd{M-x} (since `x' ``describes a key by name''), but the Texinfo manual doesn't touch this dilemma. Over the years, I formed a personal opinion about this, based on the way @key typesets its argument in print, and that opinion was what I wrote: @key is appropriate when talking about keys on the keyboard, like in the Emacs manual chapter which explains the Backspace/Delete/DEL issue or in the "Inserting Text" section that explains the basics. Everywhere else, with rare exceptions, I think the effect of @key is not what you want; in particular @kbd{M-@key{x}} looks ugly. So, in the situation like the one which led to this discussion, if the text is something like "press the TAB key", then @key{TAB} is the right markup, but if the text says "you can use TAB for completion", I'd use @kbd{TAB}. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-14 8:51 ` Eli Zaretskii @ 2006-01-14 12:20 ` Robert J. Chassell 2006-01-14 15:10 ` Eli Zaretskii 2006-01-15 7:49 ` Richard M. Stallman 1 sibling, 1 reply; 23+ messages in thread From: Robert J. Chassell @ 2006-01-14 12:20 UTC (permalink / raw) Cc: emacs-devel, karl > @key{TAB} is typeset to show an image of a key on a keyboard. I > think it is not the right markup in this case, because this manual > does not talk about keys, it talks about typing a TAB. Use the `@kbd' command for characters of input to be typed by users. ... Use the `@key' command for the conventional name for a key on a keyboard ... Bob, I know what the Texinfo manual says about this issue, I just think it's not 100% clear what it means in practice. For example, you could use either @kbd{M-@key{x}} or @kbd{M-x} (since `x' ``describes a key by name''), but the Texinfo manual doesn't touch this dilemma. My keyboard has a key labelled "Tab" but conventionally, its input can be sent either by pressing that key or by pressing C-i. So it seems to be that in the question of the rcirc manual, @kbd{TAB} makes most sense. ... @key is appropriate when talking about keys on the keyboard, like in the Emacs manual chapter which explains the Backspace/Delete/DEL issue ... Yes, I agree. I think the effect of @key is not what you want; in particular @kbd{M-@key{x}} looks ugly. I just tested the example, @kbd{C-x @key{ESC}}, in Texinfo. (No one that I know would write @kbd{M-@key{x}}. Instead, he or she would write either @kbd{M-x} or @key{M-x}.) For @kbd{C-x @key{ESC}}, both the Info and the DVI outputs look fine to me. I particularly like this output since it tells me, perhaps wrongly, that I am supposed to press the <ESC> key and not C-[. ... if the text is something like "press the TAB key", then @key{TAB} is the right markup, but if the text says "you can use TAB for completion", I'd use @kbd{TAB}. Yes. I agree. Of course, everyone must check lest someone say "press the TAB key" when he or she really means "you can use TAB ...", but that is a different issue. -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-14 12:20 ` Robert J. Chassell @ 2006-01-14 15:10 ` Eli Zaretskii 2006-01-14 17:47 ` Robert J. Chassell 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2006-01-14 15:10 UTC (permalink / raw) Cc: emacs-devel, karl > Date: Sat, 14 Jan 2006 12:20:30 +0000 (UTC) > From: "Robert J. Chassell" <bob@rattlesnake.com> > CC: karl@freefriends.org, emacs-devel@gnu.org > > I think the effect of @key is not what you want; in particular > @kbd{M-@key{x}} looks ugly. > > (No one that I know would write @kbd{M-@key{x}}. Instead, he or she > would write either @kbd{M-x} or @key{M-x}.) AFAIU, @key{M-x} is wrong, since there's no key labeled "M-x". > Yes. I agree. Of course, everyone must check lest someone say "press > the TAB key" when he or she really means "you can use TAB ...", but > that is a different issue. If there's _any_ justification for using @key outside the keyboard description, it's to make a point that "C-x ESC" does not mean one must type "C-x E S C", i.e. type the literal characters E, S, and C. I don't think there could be such confusion in the phrase "you can use TAB". ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-14 15:10 ` Eli Zaretskii @ 2006-01-14 17:47 ` Robert J. Chassell 2006-01-15 23:07 ` Richard M. Stallman 0 siblings, 1 reply; 23+ messages in thread From: Robert J. Chassell @ 2006-01-14 17:47 UTC (permalink / raw) Cc: karl, emacs-devel AFAIU, @key{M-x} is wrong, since there's no key labeled "M-x". Ah ... I think of this as pressing the Meta key and the `X' key simultaneously. Thus, the Texinfo Manual does talk of these instances: (texinfo)key Use the `@key' command for the conventional name for a key on a keyboard ... However, this terminology may be confusing. Some people refer to a `keychord' when they speak of C-x or M-C-f. Perhaps the Texinfo node should be changed to `for a key or keychord' rather than simply `for a key'. However, the word `key' does have an established meaning. When I run `describe-bindings' in this *mail* buffer, `C-x' is labeled `key' and `Prefix Command' is labeled `binding'. Perhaps the phrase `keychord' should be used occasionally, as in (eintr)Note for Novices Sometimes a combination like this is called a keychord, since it is similar to the way you play a chord on a piano. But it seems to me that most of the time, the Texinfo Manual should follow the regular meaning of `key'. -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-14 17:47 ` Robert J. Chassell @ 2006-01-15 23:07 ` Richard M. Stallman 0 siblings, 0 replies; 23+ messages in thread From: Richard M. Stallman @ 2006-01-15 23:07 UTC (permalink / raw) Cc: eliz, emacs-devel, karl @key should be used for an individual key on the keyboard, whenever you refer to it. It should not be used for "keychords". Thus, the correct way to refer to typing TAB while holding down META is @kbd{M-@key{TAB}}. And the way to refer in the text to typing just TAB is _always_ with @key{TAB}. Karl, if this isn't clear in the Texinfo manual, could you clarify it? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-14 8:51 ` Eli Zaretskii 2006-01-14 12:20 ` Robert J. Chassell @ 2006-01-15 7:49 ` Richard M. Stallman 2006-01-15 19:48 ` Eli Zaretskii 1 sibling, 1 reply; 23+ messages in thread From: Richard M. Stallman @ 2006-01-15 7:49 UTC (permalink / raw) Cc: bob, emacs-devel, karl For example, you could use either @kbd{M-@key{x}} or @kbd{M-x} (since `x' ``describes a key by name''), but the Texinfo manual doesn't touch this dilemma. For key names that are spelled out, such as TAB, always use @key. That includes @kbd{M-@key{TAB}}. You will see that in the Emacs manual. There is an exception for index entries. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-15 7:49 ` Richard M. Stallman @ 2006-01-15 19:48 ` Eli Zaretskii 2006-01-15 22:23 ` Karl Berry ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Eli Zaretskii @ 2006-01-15 19:48 UTC (permalink / raw) Cc: bob, emacs-devel, karl > From: "Richard M. Stallman" <rms@gnu.org> > CC: bob@rattlesnake.com, karl@freefriends.org, emacs-devel@gnu.org > Date: Sun, 15 Jan 2006 02:49:56 -0500 > > For example, you > could use either @kbd{M-@key{x}} or @kbd{M-x} (since `x' ``describes a > key by name''), but the Texinfo manual doesn't touch this dilemma. > > For key names that are spelled out, such as TAB, always use @key. > That includes @kbd{M-@key{TAB}}. You will see that in the Emacs > manual. That's mostly true, but the manual also has @kbd{TAB} and @kbd{C-c TAB}, for example. In any case, the explanation in the Texinfo manual should be more clear on this, IMHO. It should explain what keys are suitable for @key, and why. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-15 19:48 ` Eli Zaretskii @ 2006-01-15 22:23 ` Karl Berry 2006-01-16 4:26 ` Eli Zaretskii 2006-01-15 22:29 ` Robert J. Chassell 2006-01-16 14:15 ` Richard M. Stallman 2 siblings, 1 reply; 23+ messages in thread From: Karl Berry @ 2006-01-15 22:23 UTC (permalink / raw) Cc: bob, rms, emacs-devel In any case, the explanation in the Texinfo manual should be more clear on this, IMHO. It should explain what keys are suitable for @key, and why. Here is what the `key' node says now. Documentation improvements are always welcome, of course. I'm not too clear myself on exactly how to make it better. @node key @subsection @code{@@key}@{@var{key-name}@} @findex key Use the @code{@@key} command for the conventional name for a key on a keyboard, as in: @example @@key@{RET@} @end example You can use the @code{@@key} command within the argument of an @code{@@kbd} command when the sequence of characters to be typed includes one or more keys that are described by name. [...] There are subtleties to handling words like `meta' or `ctrl' that are names of modifier keys. When mentioning a character in which the modifier key is used, such as @kbd{Meta-a}, use the @code{@@kbd} command alone; do not use the @code{@@key} command; but when you are referring to the modifier key in isolation, use the @code{@@key} command. For example, write @samp{@@kbd@{Meta-a@}} to produce @kbd{Meta-a} and @samp{@@key@{META@}} to produce @key{META}. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-15 22:23 ` Karl Berry @ 2006-01-16 4:26 ` Eli Zaretskii 0 siblings, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2006-01-16 4:26 UTC (permalink / raw) Cc: bob, rms, emacs-devel > Date: Sun, 15 Jan 2006 16:23:45 -0600 > From: karl@freefriends.org (Karl Berry) > Cc: rms@gnu.org, bob@rattlesnake.com, emacs-devel@gnu.org > > @node key > @subsection @code{@@key}@{@var{key-name}@} > @findex key > > Use the @code{@@key} command for the conventional name for a key on a > keyboard, as in: > > @example > @@key@{RET@} > @end example > > You can use the @code{@@key} command within the argument of an > @code{@@kbd} command when the sequence of characters to be typed > includes one or more keys that are described by name. > > [...] This still doesn't spell out what I think it should: that @key is for keys whose names are more than 1 character long. And the reason for that is to avoid the user confusion, since @kbd{RET} _could_ be interpreted as @kbd{R E T}. There's no such confusion in the single-character key case. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-15 19:48 ` Eli Zaretskii 2006-01-15 22:23 ` Karl Berry @ 2006-01-15 22:29 ` Robert J. Chassell 2006-01-16 14:15 ` Richard M. Stallman 2 siblings, 0 replies; 23+ messages in thread From: Robert J. Chassell @ 2006-01-15 22:29 UTC (permalink / raw) Cc: karl In any case, the explanation in the Texinfo manual should be more clear on this, IMHO. It should explain what keys are suitable for @key, and why. Yes. In the past I thought the explanation was clear enough, but I'm wrong. Eli is right. -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-15 19:48 ` Eli Zaretskii 2006-01-15 22:23 ` Karl Berry 2006-01-15 22:29 ` Robert J. Chassell @ 2006-01-16 14:15 ` Richard M. Stallman 2006-01-21 13:01 ` Eli Zaretskii 2 siblings, 1 reply; 23+ messages in thread From: Richard M. Stallman @ 2006-01-16 14:15 UTC (permalink / raw) Cc: bob, emacs-devel, karl That's mostly true, but the manual also has @kbd{TAB} and @kbd{C-c TAB}, for example. All the occurrences of @kbd{TAB} should be @key{TAB}, except for this one vip.texi:1571:@kindex 011 @kbd{TAB} (@code{indent-for-tab-command}) which should be just TAB (we don't use @key in index entries, and @kbd inside @kindex is redundant). Could you fix them? Both occurrences of @kbd{C-c TAB} should be @kbd{C-c @key{TAB}}. Would you please fix them? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-16 14:15 ` Richard M. Stallman @ 2006-01-21 13:01 ` Eli Zaretskii 0 siblings, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2006-01-21 13:01 UTC (permalink / raw) Cc: bob, emacs-devel, karl > From: "Richard M. Stallman" <rms@gnu.org> > CC: bob@rattlesnake.com, karl@freefriends.org, emacs-devel@gnu.org > Date: Mon, 16 Jan 2006 09:15:26 -0500 > > That's mostly true, but the manual also has @kbd{TAB} and @kbd{C-c TAB}, > for example. > > All the occurrences of @kbd{TAB} should be @key{TAB}, except for > this one > > vip.texi:1571:@kindex 011 @kbd{TAB} (@code{indent-for-tab-command}) > > which should be just TAB (we don't use @key in index entries, > and @kbd inside @kindex is redundant). > > Could you fix them? > > Both occurrences of @kbd{C-c TAB} should be @kbd{C-c @key{TAB}}. > Would you please fix them? Done. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-13 11:21 ` Eli Zaretskii 2006-01-13 14:10 ` Alex Schroeder 2006-01-13 15:48 ` Thien-Thi Nguyen @ 2006-01-23 0:09 ` Alex Schroeder 2006-01-27 18:48 ` Eli Zaretskii 2 siblings, 1 reply; 23+ messages in thread From: Alex Schroeder @ 2006-01-23 0:09 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 96 bytes --] I've updated the rcirc manual according to Eli's suggestions and added a lot of index entries. [-- Attachment #2: rcirc.texi --] [-- Type: application/texinfo, Size: 21329 bytes --] [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: rcirc manual 2006-01-23 0:09 ` Alex Schroeder @ 2006-01-27 18:48 ` Eli Zaretskii 0 siblings, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2006-01-27 18:48 UTC (permalink / raw) Cc: emacs-devel > From: Alex Schroeder <alex@gnu.org> > Date: Mon, 23 Jan 2006 01:09:17 +0100 > > I've updated the rcirc manual according to Eli's suggestions and added > a lot of index entries. Thanks, I installed it in CVS. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2006-01-27 18:48 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-01-09 17:47 rcirc manual Björn Lindström 2006-01-13 11:21 ` Eli Zaretskii 2006-01-13 14:10 ` Alex Schroeder 2006-01-13 15:08 ` Eli Zaretskii 2006-01-13 15:11 ` Alex Schroeder 2006-01-14 16:14 ` Richard M. Stallman 2006-01-13 15:48 ` Thien-Thi Nguyen 2006-01-13 15:55 ` Eli Zaretskii 2006-01-13 22:16 ` Robert J. Chassell 2006-01-14 8:51 ` Eli Zaretskii 2006-01-14 12:20 ` Robert J. Chassell 2006-01-14 15:10 ` Eli Zaretskii 2006-01-14 17:47 ` Robert J. Chassell 2006-01-15 23:07 ` Richard M. Stallman 2006-01-15 7:49 ` Richard M. Stallman 2006-01-15 19:48 ` Eli Zaretskii 2006-01-15 22:23 ` Karl Berry 2006-01-16 4:26 ` Eli Zaretskii 2006-01-15 22:29 ` Robert J. Chassell 2006-01-16 14:15 ` Richard M. Stallman 2006-01-21 13:01 ` Eli Zaretskii 2006-01-23 0:09 ` Alex Schroeder 2006-01-27 18:48 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).