From: Mario Lang <mlang@delysid.org>
To: emacs-devel@gnu.org
Subject: Re: The new text-mode menu and the cursor in -nw mode
Date: Mon, 28 Apr 2014 21:14:35 +0200 [thread overview]
Message-ID: <87lhup5kro.fsf@fx.delysid.org> (raw)
In-Reply-To: <831twhnvnq.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Apr 2014 21:42:01 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
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.
>>
>> 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.
--
CYa,
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang/key@db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
next prev parent reply other threads:[~2014-04-28 19:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 12:21 The new text-mode menu and the cursor in -nw mode Mario Lang
2014-04-28 16:12 ` Eli Zaretskii
2014-04-28 18:14 ` Mario Lang
2014-04-28 18:42 ` Eli Zaretskii
2014-04-28 19:14 ` Mario Lang [this message]
2014-04-29 14:24 ` Eli Zaretskii
2014-04-29 15:20 ` Mario Lang
2014-04-29 15:36 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lhup5kro.fsf@fx.delysid.org \
--to=mlang@delysid.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.