Emacspeak discussion list

[<bart AT bunting.net.au>]

Hi Lex,

 

Welcome, and thanks for sharing this. Your Windows-native DTK server and emacspeak-plus overlap with several things I have been exploring.

 

For context, Robert Melton originally created Emacsvox as an Emacs 31 modernization of Emacspeak. My repository started from that work but has since diverged substantially, particularly around semantic presentation, package integrations and Omnivox:

 

https://github.com/bartbunting/emacsvox

 

I do not want to imply that Robert has endorsed all the directions I have taken. I hope it may eventually be possible to merge or reconcile the work with his repository, if he is happy with where it has gone.

 

The comparison below is with the Emacspeak revision from which Emacsvox was forked; upstream Emacspeak has continued independently. Emacsvox currently requires Emacs 31, so it would not be a drop-in replacement for your Emacs 30.2 setup.

 

The original modernization replaced legacy defadvice with named advice-add functions, removed obsolete APIs, and moved the Lisp to lexical binding and current cl-lib conventions. The project was also given its own emacsvox-* namespace, and the generic speech layer was renamed from dtk-* to tts-*, reserving DTK names for actual DECtalk backends. Existing Emacspeak configuration therefore needs conversion.

 

Since taking my branch further, I have added or expanded speech support for Corfu, Vertico, Marginalia, Embark, Which-Key, gptel, mu4e, Avy, Ace Window, Multiple Cursors, Helpful, Denote and Org-srs. Markdown has a cleaner reading mode and better structural feedback.

 

Agent Shell now has an end-to-end integration covering responses, thoughts, plans, tools, permission requests, source blocks, tables, folded content and prompt editing. Decorative chat glyphs are translated into useful spoken state rather than being passed to the synthesizer.

 

EAT has also received a substantial terminal-accessibility layer. It speaks meaningful screen changes, completions, prompts, command history and terminal application transitions while coalescing noisy background updates. It provides frozen-screen review and takes care not to retain or speak concealed password content.

 

I have also done detailed work on existing integrations including Org, Notmuch, Gnus, Dired, Magit, Shell/Comint, Vertico and EWW. Much of this concerns the same class of problems you described: duplicate or stale speech, decorative or invisible display text leaking into output, package API changes, and feedback getting out of step with rapid navigation.

 

The largest architectural addition is “Aural Presentation”. Its purpose is to separate what something means from how it should sound. For example, a package can identify an unread message, heading, tool result or folded section without permanently deciding which voice or sound must represent it.

 

Users can present that meaning through combinations of speech, logical voices, auditory cues, tones, pauses and stereo placement. Choices can be applied globally, per package, per major mode, per session or per buffer. Named profiles combine presentation options, sound packs, voice palettes and spatial settings. There are spoken interfaces for editing and previewing these, an explanation/history browser showing exactly why something sounded as it did, and an Aural Doctor for diagnosing configuration and backend problems. The default presentation retains familiar Emacspeak behaviour unless the user enables additional options or overrides.

 

Two concrete examples are capitalization and indentation. Capitalization can be represented by speech, a short beep, or both, so it is no longer necessary to insert the spoken word “cap” into the text. Indentation can be spoken as a column number, represented by the duration of a fixed-pitch beep, or represented by a fixed-duration tone whose pitch rises with indentation depth. Speech and tones can also be combined, replaced by personal presentation rules, or disabled.

 

The other major part is Omnivox:

 

https://github.com/bartbunting/omnivox

 

Omnivox began as Robert’s cross-platform speech server. My own reason for working on it was much less grand: I was having trouble getting Outloud or Software DECtalk to respond quickly enough when Emacspeak was running inside WSL. The immediate goal was to get a genuinely responsive speech engine for Emacspeak under WSL.

 

Having Windows perform the synthesis and audio playback, while Emacs continued to run inside WSL, turned out to be a very good result for me. Most of the subsequent work has been driven by scratching that particular itch.

 

On Windows, Omnivox supports Windows’ built-in native text-to-speech through the WinRT SpeechSynthesizer and keeps eSpeak available as another engine and fallback.

 

If JAWS has installed its normal 32-bit Freedom Scientific ECI library in the standard location, Omnivox discovers it automatically and makes the familiar Eloquence voices available. It does not copy or redistribute the JAWS library.

 

Software DECtalk can be fetched by the accompanying Emacsvox build from a pinned release of the community-maintained DECtalk project. The build verifies its SHA-256 checksum and extracts the DLL and dictionary for Omnivox to stage. This avoids having to locate an old DECtalk installer, although anyone redistributing that runtime should review its upstream terms. Piper is also available as an experimental opt-in helper.

 

On macOS, Omnivox is intended to support AVSpeechSynthesizer and eSpeak, while Linux currently uses eSpeak with optional Piper support. The broader aim is to produce working speech on all the major platforms where people run Emacs.

 

I should emphasize, however, that I have mainly tested my current branches with Emacs inside WSL and Omnivox performing synthesis and playback through Windows. I have not yet had the opportunity to test the complete setup with native Emacs on Windows or under native Linux. Those paths are intended to work, but need real users to exercise them.

 

Since you are already using WSL2, your setup is closest to the path I use every day and is therefore probably the one most likely to work if you would like to try my Emacsvox and Omnivox branches.

 

Omnivox can keep multiple engines available and route different logical voices to different engines and physical voices. Missing voices or failed engines fall through to configured alternatives. An accessible Voice Workbench discovers installed voices, previews and compares them, tunes their styles and effects, and saves portable preferences without assuming every machine has the same voice catalogue.

 

One concrete benefit is that C-e i now reads from point to the end of the buffer while moving point forward as speech is played. If you issue another command to stop reading, point is left at the sentence-sized chunk that speech had reached, rather than remaining where reading began. This is made possible by Omnivox reporting tracked playback and marker information back to Emacs.

 

For richer presentations, Omnivox can receive complete timelines containing speech, sounds, tones, pauses and spatial actions. This keeps cues attached to their intended speech boundaries and lets rapid navigation cancel obsolete output without clearing unrelated notifications or ordered speech.

 

There is a definite trade-off here. Logical-voice registration, engine discovery, structured timelines, playback callbacks and marker reporting have added considerable complexity to the speech protocol. This is a very different approach from the original Emacspeak design, where the speech-server protocol was intentionally small and simple. I see it as an experiment in a different direction, rather than suggesting that the original approach was wrong.

 

Omnivox still implements the traditional Emacspeak line protocol and includes a separate adapter for upstream Emacspeak. The additional protocol is negotiated only by the richer Emacsvox integration.

 

The WSL build stages a reproducible native Windows runtime, including eSpeak data and the optional helper programs. Diagnostic logs are bounded and private, and spoken text is excluded unless explicitly enabled.

 

Your Rutts work also sounds like the kind of engine Omnivox ought to be able to host. If you are interested in giving it a go, I would welcome a contribution adding Rutts as an Omnivox engine or isolated helper. Your existing DTK-compatible server may provide a useful starting point.

 

There are doubtless many bugs, rough edges and assumptions inherited from my own setup. Nevertheless, this is not just a demonstration project: I use Emacsvox and Omnivox every day as my normal Emacs and speech environment.

 

Emacsvox does not currently cover Telega or general image description, so those modules fill genuine gaps and seem complementary. I would also be interested in seeing the Emacspeak fixes you mentioned published. Several sound very familiar, and comparing approaches would be useful.

 

Finally, none of this would have been possible without Raman’s extraordinary work creating and sustaining Emacspeak over so many years, or without Robert’s modernization and cross-platform work providing the foundation from which I started. My sincere thanks to both of them.

 

Kind regards

 

Bart

 

From: emacspeak-request AT emacspeak.net <emacspeak-request AT emacspeak.net> On Behalf Of Oleksii Sadovyi (via emacspeak Mailing List)
Sent: Thursday, 27 August 2026 9:30 PM
To: emacspeak AT emacspeak.net
Subject: [Emacspeak] New emacspeaker

 

Hi list,

My vanilla blind-programmer a11y setup has been getting on my nerves lately, so I figured I'd peek over the fence and see how green the grass is over here. Thankfully the learning curve is much less steep nowadays, with AI agents and such.

 

Currently I'm on vanilla GUI Emacs 30.2, running under WSL2 with Windows 11 as the host (yes, I know, I know).

Inspired by prior art from Bart Bunting, Robert Melton and others, I wrote myself a speech server that speaks the DTK protocol, produces native Windows audio, and uses rutts - a popular 'robot-sounding' workhorse in Eastern Europe - as its synthesizer. That part is admittedly a bit niche for this list; I doubt many of you read Ukrainian or Russian.
But as I'm trying to move most of my computer interaction into Emacs + Emacspeak, I've also been speech-enabling a few packages and fixing bugs in existing ones along the way.

So I wanted to share emacspeak-plus: https://github.com/osadovy/emacspeak-plus - where I plan to collect the parts of this work that can be maintained without forking Emacspeak itself.

It currently has three modules:
- emacspeak-plus-telega - speech-enables Telega, a client for Telegram, which is a very popular IM protocol in my part of the world. It includes message navigation, spoken action feedback, multiple styles of automatic incoming message reading and such.
- emacspeak-plus-vertico - minibuffer completion that doesn't get in your way.
- ai-describe - land on an image, press a key, get an AI description of it. Built on gptel. I mostly use it in Telega, where people love to post images.

 

I've also been patching Emacspeak itself in a few places - small fixes, plus filling in some gaps in existing modules . Nothing dramatic - C-e = goes quiet on the second press, typing a speech rate at the prompt breaks the rate-adjust keys, M-g in a Customize buffer doesn't move, shell output that gets dropped or read back with escape codes sometimes, oddities when arrowing through fragments containing invisible text etc.

As I understand emacspeak repo does not accept contributions for now, so if there is interest, I can tidy those up and publish a fork on github.

 

Overall, Emacspeak has been well worth the effort, and I'm still constantly finding new things. Thanks to Raman and the many people whose work got it to this point!

 

Lex