Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Daniel Molina Newsgroups: gnu.bash.bug Subject: Re: apparent inconsistencies in readline documentation Date: Tue, 28 Jul 2020 10:21:45 +0200 Lines: 115 Approved: bug-bash@gnu.org Message-ID: References: <74580fd0-3f5c-6aab-ec65-815ec18d6781@autistici.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: usenet.stanford.edu 1595924518 5912 209.51.188.17 (28 Jul 2020 08:21:58 GMT) X-Complaints-To: action@cs.stanford.edu To: chet.ramey@case.edu, bug-bash@gnu.org Envelope-to: bug-bash@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=autistici.org; s=stigmate; t=1595924507; bh=F0eKJjFH66dyTAZbVbop44vq02cqyBgkN7GZqk6XRNE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pGBp1uTCiFhOvgn+6at9LvAGrwUqhKUwHnh+7+O0oFhN9Uco4ORrYOvJ2M5Wv5TwV PiJiXRIrajFolQj6XdVwqmysmftKYCWK6aDt7XnGQmwpDApFnqEXK8dg0CdDlLO09x MTmVa2XfK0GECu+6ia30MvkeclL3v4T9Vcc1x10Q= Autocrypt: addr=lluvia@autistici.org; keydata= mDMEXoeR3RYJKwYBBAHaRw8BAQdAmr3tZyvyItPdG+8oatTGRhfNtufi1UNhrp2Rkv76HAu0 JERhbmllbCBNb2xpbmEgPGxsdXZpYUBhdXRpc3RpY2kub3JnPoiWBBMWCAA+FiEEHm1z74XJ mJ4BKDf35qT7BGKNX8EFAl6Hkd0CGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQ5qT7BGKNX8HgDwEA5tK60QwM95BRbN2RG2VLnjk4Ot8RCzyA9pAJ4DVfQ1sBAKNBZr+g D6oNVbZFTwQWs+dgsDqzKzDrhZgu6Z2QN1sOuDgEXoeR3RIKKwYBBAGXVQEFAQEHQEQyX/6Y G3vNha9Zl0B7hcrRR76r2Cnsqv7EbODDZidSAwEIB4h+BBgWCAAmFiEEHm1z74XJmJ4BKDf3 5qT7BGKNX8EFAl6Hkd0CGwwFCQlmAYAACgkQ5qT7BGKNX8E6FwD/eutehycYLRbp1PpsfGs4 SbTA7zxHtYgxfecD4lyMxosBAMbpgEEOhQs4wl+S+Azu9E8HxC8l2WENAZiwLD8He7oC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=198.167.222.108; envelope-from=lluvia@autistici.org; helo=devianza.investici.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/28 04:21:47 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <74580fd0-3f5c-6aab-ec65-815ec18d6781@autistici.org> Xref: csiph.com gnu.bash.bug:16632 On 27/7/20 22:09, Chet Ramey wrote: > On 7/25/20 12:21 PM, Daniel Molina wrote: >> Hi, >> >> I found some aspects of readline documentation that seem inconsistent to >> me and I wanted to share them. >> >> 1. The difference between backward-kill-line and unix-line-discard >> readline commands. >> >> Documentation states: >> >>        backward-kill-line (C-x Rubout) >>               Kill backward to the beginning of the line. >> >>        unix-line-discard (C-u) >>               Kill backward from point to the  beginning  of  the  >> line.   The >>               killed text is saved on the kill-ring. >> >> In both cases they kill from the point and killed text is saved in the >> kill-ring. > The difference is what happens with numeric arguments. I see. > Maybe that is what > should be added to the backward-kill-line description. I think that would be useful for that an similar commands. I found the question asked on the web too. >> 2. Default key sequences vs. emacs key bindings [the default]. >> >> It is confusing to me that there are two defaults. Firstly, it can be read: >> >> EDITING COMMANDS >>        The  following  is  a list of the names of the commands and >> the default >>        key sequences to which they are bound.  Command names without >> an accom‐ >>        panying key sequence are unbound by default. >> >> On the other hand, emacs editing command are default: >> >> readline  offers  editing  capabilities  while the user is entering the >>        line.  By default, the line editing commands are similar  to  >> those  of >>        emacs.  A vi-style line editing interface is also available. >> >> An explicit list of emacs commands is maintained and commands do not >> always coincide (both being valid defaults in practice). For example, >> instead of C-x Rubout for backward-kill-line, emacs has >> >>              "C-XC-?"  backward-kill-line > Rubout/DEL[ete]/C-? are the same key. I see. >> 3. Key-bindings in the emacs/vi list are written with capital letters >> (C-A), but not in the section with the description (C-a). > It's a writing convention. The behavior doesn't differ. Are there places > where this convention is used inconsistently? > Convention is not followed strictly in the same document doc/readline.0, but I suppose that it is intentional to keep a different convention in the DEFAULT KEY BINDINGS (emacs and vi list) where uppercase is used, and the rest of the document, where mainly lower case is used with very few exceptions: In SEARCHING: If that variable has not been assigned a value the Escape  and C-J characters will terminate an incremental search.  C-G will abort an incremental search and restore the original line. In INITIALIZATION FILE -> Variables        isearch-terminators (``C-[ C-J'')               The string of characters that should  terminate  an  incremental               search  without  subsequently  executing the character as a com‐               mand.  If this variable has not been given a value, the  charac‐               ters ESC and C-J will terminate an incremental search. Maybe a confusing part is Section "1.3.3 Sample Init File" of doc/readline.info where there are lines like      # Arrow keys in keypad mode      #      #"\M-OD":        backward-char      #      # Arrow keys in ANSI mode      #      "\M-[D":        backward-char and "\C-xr": redraw-current-line but in that case maybe it is not a convention but a parsing rule of INITRC (?), I do not understand well the conventions in that section. Regards, Daniel