Hendursaga via Emacspeak <emacspeak(a)emacspeak.org> writes:
I try to shun HTML emails as much as possible - I haven't gotten
a good workflow
under "regular" Emacs, much less Emacspeak, yet, that is. I have an idea that
might work with most HTML emails I still have to interact with, however - that
of converting them to Markdown and viewing that instead..
I also try to avoid HTML email. However, I don't find any big issue with
handling HTML email these days (compared to 20 years ago when we only
had w3, lynx and later w3m for rendering). These days, I find eww/shr
work great. I still prefer plain text and will use that when available,
but the combination of eww and Emacspeak's support work well.
What exactly are the problems you find with HTML messages which you feel
conversion to markdown would resolve? My concern with this would be
added processing time and possible loss of information from the
conversion. I also dislike the lack of standardisation with markdown.
> forward-paragraph also produces an icon which I probably wouldn't do by
> preference. Is there any way I can fine-tune which icons get played or where
> when? I can imagine a hack where I remove various sound files and replace them
> with silence but I suspect there might be nicer ways of doing this.
A good portion of Emacspeak's power comes from Emacs' advice capabilities. See
TVR's article on advice for an overview of that, and then `(info
"(elisp)Advising Functions")` for the portion of the Elisp manual on advicing.
For this particular scenario, I will assume you are using the latest Emacspeak
stable release. The relevant code you should look at is . Throughout the
codebase, you'll see TVR's pattern of using `cl-loop`, `eval`, `defadvice`, and
`(when (ems-interactive-p))`. Note, however, that this is, as the aforementioned
article states, using the (quite old) advice API. I would strongly advise (pun
not intended!) to use the new `nadvice` API. See `(info "(elisp)Porting Old
Advice")` for specific advice (pun also not intended!) on that very subject.
Why would you strongly recommend that? I personally feel your better off
sticking with the old version just for consistency. I see nothing
with the new advice which is significantly better than the old advice.
There are some scenarios where the new advice may work better with
respect to lexical binding, but as I understand it, lexical binding and
either forms of advice are problematic. My feeling is the old advice has
many years of 'battle testing' and the additional cognitive load of
mixing in two different forms of advice doesn't buy much.
Should you wish to remove the auditory icons for `forward-paragraph` and, I
presume, `backward-paragraph`, run `(describe-function 'forward-paragraph)` and
scroll to the bottom, where it should state that it has an :around advice and
gives a compiled function, `ad-Advice-forward-paragraph`. To remove it, execute
`(advice-remove 'forward-paragraph #'ad-Advice-forward-paragraph)`.
`(describe-function 'forward-paragraph)` should no longer list that, or any,
advice functions. Do the same thing with `backward-paragraph` and its advice.
You will now notice that when navigating paragraphs, they aren't getting spoken
anymore. That is because the advices you removed also called
`emacspeak-speak-paragraph`, which Emacs obviously doesn't do by default.
If I was going to do something like this, I would just checkout a new
local branch in git, modify the relevant advice definitions to remove
the call to play auditory icons, re-compile and your done. The advantage
here is that when you get the next update from the upstream repository,
you can just rebase the local branch against master and you get all the
updates. Any conflicts will be flagged and you can resolve as needed.
Note the `(called-interactively-p 'any)` - I really do not know,
old and esoteric reasons, why TVR has to `eval` his `defadvice`s. Perhaps he can
chime in and enlighten us all!
The issue here is that call-interactively-p is extremely fragile and
hard to get right. In fact, Raman tried making some changes to this
function just before the last release (based on advice from Stefan
Monnier) and it caused all sorts of problems and difficult to track down
bugs. I would be extremely wary about making any changes which impact
It probably would be good to have some mechanism to adjust the
'verbosity' (not sure what the right term would be here!) of auditory
icons. There have been times I've also found them to occur too
frequently. However, the biggest issue I found was with adjusting the
volume. I found it very difficult to set a volume for auditory icons
using standard mixer apps (I use pulseAudio and/or
pipewire/wireplumber). In the end, I added CLI arguments to the play
program to reduce the volume of auditory icons so that I can still hear
them, but they are not as prominent. A better fix would probably be to
define an auditory icon channel/sink which I could set interactively
using something like pulsemixer.