It is always hard providing suggestions/advice of this type as we all have very different levels of knowledge, requirements and abilities. I'm perhaps able to appreciate these differences a little more as I've gone from havbing poor vision i.e. around 10%, to no vision for 15 years to now having around 5%. My interface requirements for those three stages were all very different. When I had 10%, I could be productive with no speech and a configuration using large fonts. When I had no sight, without speech I was dead in the water and even small omissions or gaps in the auditory interface could be extremely frustrating. Now, I find speech helps a lot, but I can get by without it in most situations, though my productivity can suffrer. However, I now use the auditory interface to augement my interaction rather than completely determine it. I mention this merely to highlight that my needs and experience are likely very different from others and what follows is just one perspective. I agree elisp-mode will do most of the heavy lifting. I also like to use ielm, which provides an interactive REPL where you can execute elisp forms. Often, the easiest way to understand how something works or what arguments do in elisp is to just execute the command and see what happens or what is returned. I also like the whole REPL driven development model. Being proficient with the emacs help system and the info documentation is extremely important. There is also a good elisp introduction available in the info system and the elisp referencve manual is good. Another mode which can be useful, but often needs a little tweaking using the customize-group interface is eldoc. The default configuration is definitely focused on a visual interface, but you can moldify some of the default settings to make it more useful under emacspeak. If your coming from a less functional language background, elisp can seem very strange. Functional programming does have a different mindset from more imperative approaches that are often the first programming paradigms people learn. The waters are further muddied by the fact that in functional programming, you try to avoid managing 'state' and try to write functions which avoid side effects, but in an editor, this is difficult to avoid. In some respects, the buffers we are operating on are really just chunks of state, which means that often, functions are not as 'pure' as the functional paradigm would like. Despite this, the basic approach stays the same i.e. achieve your objective by the composition of many simple functions which do one thing, which avoid side effects and which always return the same value when given the same input. Diving right into trying to modify emacspeak or marginalia may be overwhelming if your not familiar with either elisp or functional programming. You might find it better to start of with something a little easier, such as writing some custom commands to streamline some common tasks you perform regularly or adding some simple functionality which helps in your workflow. Identify some 'pain point' in your workflow and see if you dcan improve on it by writing some elisp. With regards to your questions concerning marginalia, I really don't know what is the best approach. Persoanlly, I like to find ways to limit/reduce the amoujnt of spoken feedback and when I do want more info on a command, I will likely just use C-h f. I tend not to use packages like vertico to find a command, but rather just to get to the command and execute it with as few keystrokes as possible i.e. I don't do M-x and then up/down arrow looking for a command. Instead, I do M-x and start typing the command I want, letting vertico reduce the number of options and then maybe use down/up to narrow to the final one. As such, additonal text describing the command is not of much value and can in fact just add audio 'clutter' to my interface. The concepts underlying marginalia seem far more suitable to a visual interface than an audio one. If I was wanting support from marginalia, for me, it would be the ability to have a key I could press that would speak the additional 'margin' notes rather than an inhterface which would automatically speak the whole line of command and notes. There are really only a very small subset of emacs commands I use regularly. The most frequently used ones are already bound to some shortcut key and the remaining handful are sorted nicely using vertico and orderless. When I find myself doing a similar action multiple times, I will likely just use the help system and apropos to find a suitable command rather then M-x and up/down in vertico. I can see how marginalia might be useful when first starting with emacs, but I suspect that within a few weeks, that benefit will diminish. For example, when I now do M-x the command I am looking for has an over 80% chance of being within the first 10 commands in the list, all of which are familiar and don't require additional help info. The other thing to consider is that there is a very high probability that the sort of information provided by marginalia is also provided by other, often built-in, modes or commands in emacs. It is possible that one of these other commands could be configured to provide the same information provided by marginalia, but in a format or way that is far more suitable to an auditory interface than marginalia. In other words, make sure adding speech support to marginalia is worth the effort compared to just using something else what also provides the same functionality, but in a format more suitable to emacspeak or to being speechified. With regards to the 'newish' transient menu approach, I haven't really looked into it yet. While I'm familiar with the approach and agree that having a standard implementation will be useful in making things more consistent rather than having ad hoc similar implementation scattered through different packages, it hasn't yet been something which has needed my attention. My workflow is pretty solid and meets my needs. I find these days, I spend very little time tweaking my emacs environment or trying out new things. I'm lucky that for my use case, things 'just work' and I tend to focus on my projects more than tweaking my environment and workflow. As Pascal wrote "sorry this letter is so long, I didn't have time to write a short one". Unfortunately, my current projedct to integrate ellarma and an AI assistant isn't quite ready yet. However, I suspect that once it is, my messages will have improved grammar and will be more concise, albeit at the cost of correctness! Tim "Parham Doustdar" (via emacspeak Mailing List) <emacspeak@xxxxxxxxxxxxx> writes: > Hi, > I always use elisp-mode, which is super well documented and well supported with > Emacspeak. Just follow the usual documentation, and Emacspeak will give you > context-sensitive information. > Transient buffers are one of the more annoying parts of Emacs because they don't fit > within the usual model of exploring the buffer/screen and making a choice. However, > Emacspeak does support some packages, like the Transient package used by packages like > Magit. I haven't dug deep enough into this to see how much of the support is on transient > itself, versus Magit's usage of transient. > Either way, I'd say elisp is required learning for anyone using Emacs and > Emacspeak. Unfortunately, per my subjective standards, subjective being the keyword, it is > not as plug and play as I'd expect. > Hope this helps, > Parham > Sent from my iPhone > >> On 7 Apr 2025, at 08:35, Dhruv <emacspeak@xxxxxxxxxxxxx> wrote: >> >> >> Hello: >> >> 1. For people who substantively work on elisp, what does your workflow look like? do you >> use a particular mode? is there anything in emaspeak which enhances the experience? >> >> 2. A bunch of different packages seem to open transient popups/minibuffers with >> additional details (which-key for example, or Embark). Has anyone worked with these? is >> there a way to read them? >> Emacspeak discussion list -- emacspeak@xxxxxxxxxxxxx >> To unsubscribe send email to: >> emacspeak-request@xxxxxxxxxxxxx with a subject of: unsubscribe > > Emacspeak discussion list -- emacspeak@xxxxxxxxxxxxx > To unsubscribe send email to: > emacspeak-request@xxxxxxxxxxxxx with a subject of: unsubscribe
|Full archive May 1995 - present by Year|Search the archive|
If you have questions about this archive or had problems using it, please contact us.