[BRLTTY] Emacspeak and Braille displays

Rich Morin rdm at cfcl.com
Wed Jun 15 11:53:42 EDT 2016


On Jun 15, 2016, at 02:51, Dave Mielke <dave at mielke.cc> wrote:
> [quoted lines by Rich Morin on 2016/06/14 at 10:31 -0700]
> 
> The only one who may need to duck his head around here is myself whenever 
> stupid bugs slip through. :-) That being said, I myself don't believe in head 
> ducking, excuse making, etc. Just simple honesty and taking responsibility.

+1

> Brltty does support the Brailliant BI 40. There've been some problems, though, 
> but they've been fixed in the development code and shall be in release 5.4 
> which should be released next week.

We can certainly wait for the release, if need be.  Alternatively, would it make
sense to get started with the current release (5.3.1) or the development repo on
GitHub (https://github.com/brltty/brltty)?

> Brltty already builds for Mac OS X.

Great!

> Its one big limitation on that platform is that it can't directly read the
> screen's content as it does on Linux. What our Mac OS X users do is to apply
> a patch that we supply to the screen program.  That patch causes screen to
> maintain an image of the screen content within a  shared memory segment that
> brltty knows how to interpret.

When you speak of the "screen program", I assume that you're talking about
screen(1), which is shipped with OSX and available from the GNU Project:

  screen - screen manager with VT100/ANSI terminal emulation

  Screen is a full-screen window manager that multiplexes a physical terminal
  between several processes, typically interactive shells. Each virtual terminal
  provides the functions of the DEC VT100 terminal and, in addition, several
  control functions from the ISO 6429 (ECMA 48, ANSI X3.64) and ISO 2022 standards
  (e.g. insert/delete line and support for multiple character sets). There is a
  scrollback history buffer for each virtual terminal and a copy-and-paste
  mechanism that allows the user to move text regions between windows.

  -- https://www.gnu.org/software/screen/manual/screen.html

> We do have Mac OS X users of brltty on this list. Perhaps one of them can offer 
> you more direct help.

That would be most helpful.  We are complete newbies at Emacs, Emacspeak, and
BRLTTY.  Also, Amanda is located in Austin, while I live near San Francisco.
So, any specific information and instructions would be golden.

From the README file, it appears that BRLTTY can be downloaded and built from
source code on any supported platform.  Are there any Mac-specific gotchas?

We also need to download the current copy of screen (4.3.1), obtain and apply
the patch, and then build a new executable.  Where might we get the patch?

Finally, we need to start up the combination of BRLTTY, Emacs, Emacspeak, and
screen.  Are there any options or settings we need to know about?

> If you're familiar with programming for Mac OS X, and if you know how brltty 
> could read the screen content directly, then your help would most definitely
> be appreciated so that this capability could finally be implemented.

Neither of us have that level of Mac programming knowledge, but I have many
friends who do.  I'll put out a call for help and let you know.

>> Alternatively, it may be that Apple's built-in Braille support can do the job:
> 
> I wouldn't be surprised if Apple's VoiceOver already supports the Brailliant
> BI 40. If it does then you may still want to use both it and brltty - i.e.
> brltty for terminal windows and VoiceOver for graphical ones. That'd be a
> matter of user preference.

I'm not sure how closely Apple's support for Braille displays is tied to
VoiceOver.  However, she has been using her BI 40 with the Macbook Air for
several months (e.g., on Safari and Terminal).  So, she may only be using
BRLTTY and screen to access Emacspeak.


On Jun 15, 2016, at 05:00, Mario Lang <mlang at delysid.org> wrote:
> Rich Morin <rdm at cfcl.com> writes:
>> ...  Emacs divides the screen into "buffers", ...
> 
> That is actually incorrect terminology.  Emacs divides the screen
> up into so-called windows, each of which can display the content
> of a buffer.

Noted.  So, the Mac display area (which can be composed of multiple
physical screens) can present multiple windows.  Each Emacs session
uses one of these, dividing it into panels (which it calls "windows").
Each Emacs window can display the content of a text buffer, which may
contain the contents of a file, command-line interactions, etc.

> I am an Emacs user since roughly 18 years, and have always used it
> with BRLTTY.  There is no Braille specific problem when it comes to
> using Emacs that I know of.  BRLTTY can easily follow the text cursor
> around the screen, and Emacs uses the typical cursor to indicate the
> position of point.  So if you move point through a buffer, BRLTTY
> should (if cursor tracking is on) automatically follow it around.
> Could you please explain in a little more detail what problem you are
> having exactly?

Amanda only got Emacs and Emacspeak working in the past few days.  She
has been trying it out using VoiceOver, but hasn't been getting output
on her Braille display.  Following a suggestion on the Emacspeak list,
I came over here to inquire about BRLTTY.

Given that Amanda is able to use her Braille display with a Terminal
session, it may be that she can use the patched version of screen(1)
to access Emacspeak, without any need for BRLTTY.  Does this seem
plausible?  Regardless, are there reasons that adding BRLTTY into the
mix would be useful to her?

-r

 -- 
http://www.cfcl.com/rdm           Rich Morin           rdm at cfcl.com
http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841

Software system design, development, and documentation




More information about the BRLTTY mailing list