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 21:14:35 +0200 Message-ID: <87lhup5kro.fsf@fx.delysid.org> References: <87d2g1iqzp.fsf@fx.delysid.org> <83d2g1o2lc.fsf@gnu.org> <87wqe98goi.fsf@fx.delysid.org> <831twhnvnq.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 1398712497 4675 80.91.229.3 (28 Apr 2014 19:14:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Apr 2014 19:14:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 28 21:14:52 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 1Wer0s-0003A7-QI for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2014 21:14:51 +0200 Original-Received: from localhost ([::1]:45568 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wer0s-0006x7-CX for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2014 15:14:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wer0l-0006wz-7p for emacs-devel@gnu.org; Mon, 28 Apr 2014 15:14:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wer0g-0003ZI-EH for emacs-devel@gnu.org; Mon, 28 Apr 2014 15:14:43 -0400 Original-Received: from fep28.mx.upcmail.net ([62.179.121.48]:62487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wer0g-0003Yy-4x for emacs-devel@gnu.org; Mon, 28 Apr 2014 15:14:38 -0400 Original-Received: from edge03.upcmail.net ([192.168.13.238]) by viefep28-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20140428191436.LHCK23681.viefep28-int.chello.at@edge03.upcmail.net> for ; Mon, 28 Apr 2014 21:14:36 +0200 Original-Received: from fx.delysid.org ([80.109.200.215]) by edge03.upcmail.net with edge id vXEc1n0024fLMH403XEcDG; Mon, 28 Apr 2014 21:14:36 +0200 X-SourceIP: 80.109.200.215 Original-Received: from mlang by fx.delysid.org with local (Exim 4.82) (envelope-from ) id 1Wer0d-0001sG-Uj for emacs-devel@gnu.org; Mon, 28 Apr 2014 21:14:35 +0200 In-Reply-To: <831twhnvnq.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Apr 2014 21:42:01 +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.48 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:171648 Archived-At: Eli Zaretskii writes: >> From: Mario Lang >> Date: Mon, 28 Apr 2014 20:14:37 +0200 >>=20 >> > 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? >>=20 >> It would be ideal to only reposition the cursor when the drawing has >> been complete. > > I don't think we can do that. I'm not an expert, but I think text > terminals must move the cursor to where they are going to write stuff, > before actually writing it. Yes, sorry, I was unclear on that. I know what you describe. I ment to say: After the screen has been drawn, set the cursor to the beginning of the highlighted area. >> > 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. >>=20 >> 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. > > The menu is displayed in different colors. But since you say that > colors are "lost in translation", I wonder whether it is indeed as > easy as you describe to understand where the menu item ends and the > overlaid text begins. Trust me, it is, this is something that blind users have to cope with, and we know how to do that. >> 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. > > That's exactly what bothers me: updating a menu might, and generally > will, change more than one place on the screen. As a trivial example, > moving to the next menu item will redraw both the one which was > highlighted before and the one that is to be highlighted now. Screen > readers will probably read both (and the help echo in between them), > and I'm not sure the user will understand what is going on, not > without some training. I am not really sure about speech based screen readers, but some have ways to cope with very fast screen updates, and present the changes in a "meaningful" way. All I know, as a braille user, is that the hardware cursor position is essential to indicate the highlighted area. Screen update ordering is totally irrelevant to me, since the screen updates happen way to fast to actually "see" them. However, what I need is the hardware cursor on the highlighted item, such that my screen reader shows the text "around" the highlight area, instead of going stuck in the middle of the currently active window. --=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 `. `' `-