Emacspeak discussion list

[Tim Cross <theophilusx AT gmail.com>]

That article is a good summary of the options and the different types of
suggestion/completion use cases and available solutions, especially from the 
eyes
free interface perspective.

To provide some context with respect to corfu for those not familiar
with it, I'll try to summarise.

In line with Raman's article, corfu basically fulfills the completion
role as outlined in his blog article. I is a UI for the
completion-at-point functionality in Emacs.

Corfu is from the same author as vertico and consult. Part of the
author's philosophy is to use as much of existing core emacs
functionality as possible rather than re-inventing existing wheels and
try to keep packages as small as possible. A philosophy I agree with.

Corfu fulfills a similar role to company. However, because it relies
heavily on existing Emacs functionality, it is much smaller and I think
faster than company. However, this does come at a cost for Emacspeak
users. One of the advantages of company is that you have fine grained
control over the configuration of the front end. This makes it
relatively easy to get company to work in a manner which is compatible
with emacspeak. Corfu on the other hand is less flexible in this area
and out of the box, is not terrribly compatible with Emacspeak. As I
have some sight, I am able to use it effectively, but for anyone who
depends on an eyes free completion interface, corfu is unlikely to be
terribly useful. There are some options to configure corfu to use the
minibuffer, which might make it work better with emacspeak, but that also
has its own restrictions. For one, you cannot use the minibuffer if you
are also using another UI package such as vertico. The whole point of
corfu is to provide a completion candidate popup at point in the buffer
you are editing. While this works well for a sighted based interface
where you can quickly and easily scan the list for the appropriate
candidate, it isn't necessarily a good interface for an eyes free experience.

One of the nice aspects of corfu is that it is very easy to add new
completions back ends and it has the ability to combine multiple
backends into a single completion candidate list. I also find it very
easy to configure. Currenntly, I am looking to see if it can be made to
work with better speech feedback by adding some advice to key
areas. While I suspect this may help, I doubt it will never be as good
as a well configured company from an eyes free interface perspective.

For some additional background, part of the reason I've been looking at
corfu and have adopted vertico, embark and consult as key components in
my setup was due to two main factors. Firstly, I found helm, despite
being extremely popular, to be very slow and I frequently ran into
problems. Noting that the original author no longer wants to maintain
the package and subsequent uncertainty over its future, I decided to
move away from it. Likewise, while I found ivy to be better than helm,
I still found it to be a fairly large package which was re-inventing a number 
of
existing Emacs features and which lacked the close Emacs integration I
prefer. So far, I'm very happy with vertico and embark and despite the
lack of emacspeak support, find corfu a good completion-at-point
interface for my workflow. Of course, as is the case with most of emacs,
your mileage may differ depending on your workflow and interface 
requirements.  

The second reason I've been looking at all of this is a general desire
to reduce the amount of additional non-core packages I use and to try
and ensure that those packages I do use leverage off existing emacs
facilities. As another example, I use eglot instead of lsp-mode because
the former is built on top of flymake, xref, eldoc, project etc while
the later implements its own versions of similar functionality and
depends on other external packages, such as projectiles, helm, ivy and
company. Also, eglot is part of Emacs while lsp-mode is a separate
non-GNU package. In fact, I think eglot is a great example of what Raman
was highlighting when he posted about Emacs gems. Eglot has implemented
a framework for supporting LSP which uses functionality which already
existed in Emacs. Essentially, it provides the glue code to take
existing functionality, extend it with the ability to query language
servers using the LSP protocol and wrap it all up with a consistent
UI. As a consequence, it is much smaller than lsp-mode and less code
tends to mean less bugs!

Of course, this is just my take on things. These days, I have quite a
well defined workflow which I need to support and it is not complex. I'm
now more a tinkerer rather than a full time developer and spend lots of
my time simplifying things and only looking at stuff I find
interesting. I don't have the same demands on my productivity I had when
working full time, which means a bit more flexibility. I also am easily
distracted by other things, so progress in any specific area can be slow.

Tim