Emacspeak discussion list

["T.V Raman" <raman AT google.com>]

This is why we have choices in Emacs;-)

Your summary is accurate, but TL;DR:

If you have some vision and can see the screen, then corfu, vertico
and perhaps even helm are for you.

If you cannot see at all, then company, ido, flx, and some of the
newer completion choices in emacs 30 are what you want.

I would not beat myhead against the wall to make corfu work for
someone who is totally blind; it's  (corfu) purpose is to put up a
popup window of choices in context which is not much if you cant see
the screen. Likewise, if you can see the screen to be able to benefit
from that popup, then it's for you and Emacspeak should not get in the
way.

Also, note that Emacspeak's goal is not support *every* package, as an
example I implemented company support which meant I never implemented
support for the autocomplete package.


"Tim Cross" (via emacspeak Mailing List) writes:
 > 
 > 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
 > 
 > ----------------------------------------------------------------------
 > Emacspeak discussion list -- emacspeak AT emacspeak.net
 > To unsubscribe send email to:
 > emacspeak-request AT emacspeak.net with a subject of: unsubscribe

--