From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mario Lang Newsgroups: gmane.emacs.devel Subject: Re: The new text-mode menu and the cursor in -nw mode Date: Mon, 28 Apr 2014 20:14:37 +0200 Message-ID: <87wqe98goi.fsf@fx.delysid.org> References: <87d2g1iqzp.fsf@fx.delysid.org> <83d2g1o2lc.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1398708904 25496 80.91.229.3 (28 Apr 2014 18:15:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Apr 2014 18:15:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 28 20:14:58 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Weq4u-00075I-0m for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2014 20:14:56 +0200 Original-Received: from localhost ([::1]:45324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Weq4t-0007Ux-8Z for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2014 14:14:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Weq4l-0007It-RG for emacs-devel@gnu.org; Mon, 28 Apr 2014 14:14:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Weq4e-0007Kf-PU for emacs-devel@gnu.org; Mon, 28 Apr 2014 14:14:47 -0400 Original-Received: from fep19.mx.upcmail.net ([62.179.121.39]:61355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Weq4e-0007Ja-ED for emacs-devel@gnu.org; Mon, 28 Apr 2014 14:14:40 -0400 Original-Received: from edge03.upcmail.net ([192.168.13.238]) by viefep19-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20140428181438.LZYN5914.viefep19-int.chello.at@edge03.upcmail.net> for ; Mon, 28 Apr 2014 20:14:38 +0200 Original-Received: from fx.delysid.org ([80.109.200.215]) by edge03.upcmail.net with edge id vWEd1n01Y4fLMH403WEdjA; Mon, 28 Apr 2014 20:14:38 +0200 X-SourceIP: 80.109.200.215 Original-Received: from mlang by fx.delysid.org with local (Exim 4.82) (envelope-from ) id 1Weq4b-0001oj-MO for emacs-devel@gnu.org; Mon, 28 Apr 2014 20:14:37 +0200 In-Reply-To: <83d2g1o2lc.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Apr 2014 19:12:15 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.90 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 62.179.121.39 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171646 Archived-At: Eli Zaretskii writes: >> From: Mario Lang >> Date: Mon, 28 Apr 2014 14:21:46 +0200 >>=20 >> The new text mode menu is nice, something I have been waiting for since >> a long time. However, I have an accessibility issue with it: When I hit >> F10 to go to the menu, the menu pops up and the selected item is >> highlighted with a change of color, but the terminal cursor stays at the >> place in the currently selected buffer. I can see that this makes sense >> for some use cases (you can still see where point is while navigating >> the menu), but it is quite a problem to (some) blind users of Emacs. > > Actually, we turn off the cursor while a menu is active, because > otherwise it can show through the menu, which is ugly. We turn it > back on only when the menu pops down, i.e. the user either makes a > selection or quits the menu. As far as I am concerned, this is only a visual trick, see below. >> Screen readers on UNIX usually do only track the hardware cursor >> position, but they do not track background color changes. So my screen >> reader has currently no way to follow the currently selected menu item, >> which makes the menu as such, rather useless because it is very >> time-inefficient for me. >>=20 >> Similar to my recent request about allowing blink-matching-paren being >> set to 'jump, and therefore getting the old hardware-cursor behaviour >> back, I'd like to ask if there is a way to enhance the new text mode >> menu with a user option to have the terminal cursor jump to the >> currently selected menu item?=20=20 > > Please tell more, as I don't yet understand the requirements (and > don't have Unix screen readers anywhere near me to try this myself). > E.g., is it OK to have the cursor turned off when the menu is > displayed? IOW, are you saying that only the cursor coordinates > matter, not whether it is visible or not? Exactly. Typical screen readers do not differenciate between visiable and non-visible cursors. What they do, is to position the viewing area around the (visible or not) hardware cursor. So, if we keep the hardware cursor invisible, that is perfectly fine to me. What I need is the hardware cursor positioned at the currently selected item in the menu. Either on the first character, or the character preceding it, would be most convenient. > Next, what happens when some sub-menu is selected? When the user > does this, we redraw large portions of the screen (to remove the old > menu and display the new one), and each screen line that is partially > or fully redrawn causes cursor motion -- will this cause those > portions that are redrawn to be read, and if so, is that OK? It would be ideal to only reposition the cursor when the drawing has been complete. > Also, moving to a different menu item will generally display the > corresponding help echo in the echo area -- does it matter whether the > help echo is read before or after the newly highlighted menu item? I don't think it matters much, although it might be better to display the echo are change *after* the menu change has been redrawn. > Finally, what exactly is read by the screen reader, given a cursor > position? That is, how does the reader know when to stop reading > stuff off the screen? I'm asking this because the TTY menus overlay > the buffer text at some arbitrary place, so where the menu item ends, > there's some random text, which typically starts in the middle of a > word. If the reader will read that, you will hear a terrible > gibberish. I am a braille user. A braille display typically consists of 40 or 80 characters. When the hardware cursor position changes, my braille display is typically updated around that cursor position. As a braille user, I can make sense of text that is mixed, i.e., I can understand that a part of the text is related to the menu item, and the rest is related to the text that was displayed before the menu overlayed this area of the screen. Speech users typically can also cope with this situation. However, as mention in this thread, what is important to both groups, is that the hardware cursor position is update if the currently "highlighted" area of the screen changes, so that the screen reader can "follow" the hightlight around on the screen. > Thanks. Thanks for asking, and answering so swiftly. --=20 CYa, =E2=A1=8D=E2=A0=81=E2=A0=97=E2=A0=8A=E2=A0=95 | Debian Developer .''`. | Get my public key via finger mlang/key@db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `-