From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Interactive hat. (Patch) Date: Tue, 14 Apr 2009 23:47:54 +0300 Message-ID: <83eivvm079.fsf@gnu.org> References: <20090326124453.GC3358@muc.de> <20090326152738.GF3358@muc.de> <20090326190603.GH3358@muc.de> <20090326233257.GA1008@muc.de> <20090413193255.GA2332@muc.de> <83bpr0nuwo.fsf@gnu.org> <20090414201538.GA3425@muc.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1239742106 29776 80.91.229.12 (14 Apr 2009 20:48:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Apr 2009 20:48:26 +0000 (UTC) Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 14 22:49:45 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LtpZf-0001kr-Ix for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 22:49:43 +0200 Original-Received: from localhost ([127.0.0.1]:50464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtpYG-0008SV-Ls for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 16:48:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtpYA-0008Q1-Jo for emacs-devel@gnu.org; Tue, 14 Apr 2009 16:48:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtpY9-0008Pp-Jd for emacs-devel@gnu.org; Tue, 14 Apr 2009 16:48:10 -0400 Original-Received: from [199.232.76.173] (port=44779 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtpY9-0008Pm-EQ for emacs-devel@gnu.org; Tue, 14 Apr 2009 16:48:09 -0400 Original-Received: from mtaout7.012.net.il ([84.95.2.19]:32818) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LtpY8-0000oO-Tu for emacs-devel@gnu.org; Tue, 14 Apr 2009 16:48:09 -0400 Original-Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KI300600Z2RUC00@i-mtaout7.012.net.il> for emacs-devel@gnu.org; Tue, 14 Apr 2009 23:47:48 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.34.97]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KI3009LLZ3MEZC0@i-mtaout7.012.net.il>; Tue, 14 Apr 2009 23:47:47 +0300 (IDT) In-reply-to: <20090414201538.GA3425@muc.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:110279 Archived-At: > Date: Tue, 14 Apr 2009 20:15:38 +0000 > Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Alan Mackenzie > > That was some impressive proof-reading. Thank you very much indeed! Thank _you_ for working on this in the first place. > > Why did you add whitespace between the menu items and their > > descriptions? now the lines are too long, IMO. Suggest to reduce the > > whitespace back. > > I didn't add the whitespace, as such. C-c C-u C-m `texinfo-make-menu' > did it for me, so I wasn't fully aware of it. Anyhow, I've taken all but > one of the spaces out, to leave the minimum gap (1 space) between > "Interactive::" and "Non-string" That's good. Yes, `texinfo-make-menu' is known for adding gratuitous whitespace. > > > ! The @samp{*} checks that the buffer is writable, signaling an error if > > > "buffer is writable" sounds strange. How about > > > The @samp{*} checks that the buffer is read-only, and signals an > > error if so. > > > or simply > > > The @samp{*} signals an error if the buffer is read-only. > > It seems a bit negative. "Writable" seems more positive than "not > read-only". I'll think a bit more about this. There was no "not" in the text I suggested. > In the end, I moved the footnote to near the start of the pargraph. I'm > (still) getting trouble from makeinfo 4.7, though. It generates this for > the end of that paragraph: > > Shift-translation is controlled on the user level by > `shift-select-mode'; see Shift Selection(emacs) > . Special. > > , with that oddly placed full stop. The corresponding bit of .texi is: > > Shift-translation is controlled on the user level by > @code{shift-select-mode}; @xref{Shift Selection,,, emacs, The GNU > Emacs Manual}. Special. > > Have you any idea what's going wrong? Nothing's wrong; you are looking at the result of info.el's attempt to beautify the Info cross-reference syntax, and failing spectacularly when it spans more than a single line. Please visit the produced Info file literally, and you will see that the text produced by makeinfo is perfectly okay. > > It is usually a good idea to have one or more @cindex entries at the > > beginning of each section that gives the main subject of the section. > > Imagine yourself a year from now looking for this stuff, and ask > > yourself what phrases you'd think about -- these are the phrases you > > need to put in the @cindex entry for the section. The name of the > > node, or some trivial transformation of it, is usually the first > > choice. > > Hmm. Difficult! My first attempt was more like a sentence and was far > too long. The best I can manage right now is: > > @cindex Non-string interactive code Well, this is related to Miles's comments. Maybe if we find a better term for this, the index entry could use that. > > This rationale for the functionality doesn't really explain it. In a > > nutshell, it says "You will want the non-string equivalents when you > > need the non-string interactive form." That's a tautology. Can you > > come up with a better rationale? > > Very good point! How about something like: "These should help you when > you need to combine the effect of a standard code character with lisp > code which is specific to your command."? Wasn't your motivation primarily portability to versions of Emacs that don't support some of the newer characters? If so, why not say that? > "Many of the code characters are equivalent to a single Lisp function. > These are: > > `*` - `barf-if-readonly' > `d' - `point' > .... > `z' - `read-coding-system' > > The other code characters need more involved coding to emulate, for > example: > > `K' - key sequence (no case conversion) > (interactive > (let ((prompt "Key binding: ") > (ks) last-event) > .... > > "? That's a very good idea, IMO.