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: The new text-mode menu and the cursor in -nw mode Date: Mon, 28 Apr 2014 21:42:01 +0300 Message-ID: <831twhnvnq.fsf@gnu.org> References: <87d2g1iqzp.fsf@fx.delysid.org> <83d2g1o2lc.fsf@gnu.org> <87wqe98goi.fsf@fx.delysid.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1398710550 21129 80.91.229.3 (28 Apr 2014 18:42:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Apr 2014 18:42:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Mario Lang Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 28 20:42:20 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 1WeqVN-0006fl-9d for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2014 20:42:17 +0200 Original-Received: from localhost ([::1]:45449 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WeqVM-0002Jg-U2 for ged-emacs-devel@m.gmane.org; Mon, 28 Apr 2014 14:42:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WeqV9-00027P-4x for emacs-devel@gnu.org; Mon, 28 Apr 2014 14:42:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WeqV3-0000yc-98 for emacs-devel@gnu.org; Mon, 28 Apr 2014 14:42:03 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:47191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WeqV2-0000yJ-Tn for emacs-devel@gnu.org; Mon, 28 Apr 2014 14:41:57 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N4R00I007AQ7I00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 28 Apr 2014 21:41:55 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N4R00HBG7XUTA90@a-mtaout20.012.net.il>; Mon, 28 Apr 2014 21:41:55 +0300 (IDT) In-reply-to: <87wqe98goi.fsf@fx.delysid.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:171647 Archived-At: > From: Mario Lang > Date: Mon, 28 Apr 2014 20:14:37 +0200 > > > 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. 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. > > 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. 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. > 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.