Re: The new text-mode menu and the cursor in -nw mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Mario Lang <mlang@delysid.org>
> 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.