From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.bugs,gmane.emacs.help,gmane.emacs.devel Subject: Re: read-key-sequence(-vector) on Shift left/right gives[left]/[right], not [S-left]/[S-right] ? Date: Tue, 07 Sep 2004 10:47:16 -0400 Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1094568509 24808 80.91.224.253 (7 Sep 2004 14:48:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 7 Sep 2004 14:48:29 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, Kai Grossjohann , Emacs-Devel , bug-gnu-emacs@gnu.org, rms@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 07 16:48:08 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C4hGS-0005P3-00 for ; Tue, 07 Sep 2004 16:48:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C4hLg-0004g4-FW for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Sep 2004 10:53:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C4hLe-0004fM-PS for bug-gnu-emacs@gnu.org; Tue, 07 Sep 2004 10:53:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C4hLb-0004bl-QA for bug-gnu-emacs@gnu.org; Tue, 07 Sep 2004 10:53:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C4hLb-0004bi-OB; Tue, 07 Sep 2004 10:53:27 -0400 Original-Received: from [206.47.199.163] (helo=simmts5-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C4hFe-00044T-8Z; Tue, 07 Sep 2004 10:47:18 -0400 Original-Received: from empanada.home ([67.71.118.162]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040907144527.TFOU1635.simmts5-srv.bellnexxia.net@empanada.home>; Tue, 7 Sep 2004 10:45:27 -0400 Original-Received: by empanada.home (Postfix, from userid 502) id EEADF2DEFD8; Tue, 7 Sep 2004 10:47:16 -0400 (EDT) Original-To: "Drew Adams" In-Reply-To: (Drew Adams's message of "Tue, 7 Sep 2004 07:32:50 -0700") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (darwin) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:8955 gmane.emacs.help:20479 gmane.emacs.devel:26854 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:20479 > 3) The Emacs manual says, in node Window Handling Convenience Features and > Customization: "Not all terminals support shifted arrow keys". Without > knowing that the read-key-* functions drop the shift modifier if that key > sequence is currently unbound, someone could easily think that the terminal > just doesn't support shifted arrow keys. Convenience or confusion? Under X11, if I do C-h k S-up, I get a hel buffer that starts with: (translated from ) runs the command previous-line so it tells you right there. But it admittedly, doesn't show you that S-up intermediate step when running on a terminal (and it doesn't show you the ESC sequence either because RMS thought it would be confusing). > 4) Is this really a good thing, anyway? If I want a command that reads key > sequences, should I really have to pre-bind (and later unbind, to clean up) > such "exceptional" keys, just to be able to read the input key sequence > correctly (to see what the user pressed)? At the least, shouldn't there be > an option in read-key-sequence and read-key-sequence-vector to _not_ ignore > the shift modifier? Read-key-sequence does not return "what the user pressed", because of things like function-key-map, key-translation-map, input-methods, events and modifiers dropped, ... and also because it has to decide "when is it finished" and it does that based on the currently active keymaps. If you want to see what the user presses, try something like read-event or this-command-keys. But on a terminal, this will not tell you S-up either, instead you'll get the ESC sequence. > 5) What does key binding have to do with reading key input? Shouldn't code > be able to read user input without paying attention to key bindings (and > whether or not keys are bound)? When do you stop? After one key, two keys, three? Stefan