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[1] 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 [2]. 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, beyond probably > 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 this. 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.
|May 1995 - Last Year|Current Year|
If you have questions about this archive or had problems using it, please contact us.