Hi All,
Over the last couple of weeks I've been looking at using helm-mode with emacspeak. Thanks to some work done by Raman, helm-mode does work with emacspeak. However, I suspect that helm mode will only have very limited benefits for emacspeak users. I thought I would outline some of what I found, just in case it is useful for other users.
Helm mode is a very different approach to completion compared to other emacs solutions. In general, most other completion approaches, such as company or auto-complete, use a key, such as tab, to trigger a compleiton function which will build a list of candidates and then present them, either in a completions buffer, the minibuffer or perhpas a tooltip. While these methods usually have some type of fuzzy matching, the completions are generally done in a fairly linear stuyle i.e. matches based on the characters as you type them. In general, if you only know the last part of the command, you may need to use a pattern or globbing at the start and enter the bit you know from the end. This approach works well when you have a pretty good idea of what your looking for and when you have been an emacs user for some time and know some of the common namiing conventions and patterns.
Helm approaches things from a different perspective. It does not use a 'trigger' key, such as tab and in fact, does not work well with functions which mimic this pattern (in fact, it is quite hard to get helm to work with some of emacspeak's built in functions without losing some of the benefits, such as tab completion in google web searches. However, in some cases, helm does provide quite usable alternatives, such as it's built-in version of google-suggest.).
However the move away from using a tab character to trigger completions is only part of how helm is different. Helm refers to itself as a narrowing and completion framework which allows you to find what you want without having to know anything about emacs command names, naming conventions etc. It uses a window of candidates, which narrows to a list which is generated from what it calls sources. There are some nice aspects to the approach. You can just type keywords and it will find related things based on those keywords. Howeever, the big selling point is that it is very much a visual completions mechanism. It provides lots of visual clues to assist the user in identifying or finding what they are looking for. If you can see these visual clues, it is quite nice as often spotting the one ou want can be much faster. However, I found if you have to iterate through the options to listen to each one, then much of this benefit is lost. In some cases, I found help actually made me slower because when you start moving through the various completions to find the one you want, it adds the completion text to your input. This means that if you realise an earlier option was the most appropriate, you have to move back or you have to backspace to delete the characters. The other problem I found was that helm has a lot of options - many things you can do at any particular point of the completions process. Some of these were quite handy. However, because there can be so many, Helm has been forced to provide visual clues to these options in multiple places i.e. mode-line, header-line etc. I found in most cases, the amount of extra effort taken to navigate around to find these options was prohibitive, although over time, I would probably just learn to remember the most common ones and so this would be less of a burden.
The other thing I noticed with Helm was that some of the time, it seemed to have a pretty negative impact on emacs' responsiveness. I normally don't notice any delay or lag when using emacs. However, on a number of instances, helm did seem a little 'sluggish'. I suspect this is something which could be addressed with a bit of configuration turning. Still, I don't need to do that with other approaches.
Perhaps the biggest challenge I found with helm was changing my mental model regarding how I interact with emacs. I've been using emacs for about 18 years now and I guess I'm use to it. I dimly remember finding it hard at first, but I rarely have issues I can't solve these days and there is very little I find with the interface which annoys or frustrates me and I'm not sure if the benefits offered by Helm are sufficient to offset the effort needed to learn to think in a helm workflow rather than the workflow I'm use to. This is especially true given that while I can see the interface, it is difficult to read and I cannot really benefit from Helm's visual approach to guiding the user.
It is quite possible that Helm could be vary useful for new users. However, this usefulness may level off after a bit of time, which could actually result in limiting individual growth. The great thing about emacs is that it has always been very keyboard focused and allows the individual to really customize their environment to suit their own needs. If you rely too heavily on something like helm, I suspect you could find your growth limited to what helm does or to the direction helm moves and this will always be a little limiting, especially given that it has a very visual focus for the interface. Having said that, I should also emphasize that the helm community seems to be a very welcoming and helpful community. When I asked questions and tried to solve a few problems, I got a lot of help and suggestions.
In conclusion, I found running helm quite interesting. Raman has done some work to make it compatible with emacspeak and his helm-prepare.el file in the tvr directory shows how you can have helm and turn it on or off. One good thing about helm is that you don't have to drink the full kool-aid - you can actually pick some of its functionality and just use the bits you want or just turn it on when you want it.
Personally, I think other approaches, such as using ido, smex, company etc, provide a solution which I prefer and which I think work better for an auditory interface. If you want to try helm, just to see what it is like, I would recommend using emacs prelude. The prelude configuration framework already has a good helm setup and prelude will work well with emacspeak - all you need to do is put your emacspeak init code in a file in the personal/preload directory, uncomment the modules you need in the prelude modules file and your good to go. Note that you should comment out the ido module as I found loading both helm and ido caused some problems.
--
If you have questions about this archive or had problems using it,
please contact us.