Re: [Emacspeak] Emacs: Hidden Holiday Gems

[Tim Cross <theophilusx@xxxxxxxxx>]

Agree 100%. Corfu is definitely oriented towards a sighted interface and
while it may be possible to make it work better with Emacspeak, that
effort is hard to justify given that company is also a good choice and
already works well. I am also mindful of the maintenance overheads
associated with every additional supported package for emacspeak. I feel
it would be better to support a small number well than try to support
everything poorly.

"T.V Raman" <raman@xxxxxxxxxx> writes:

> 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@xxxxxxxxxxxxx
>  > To unsubscribe send email to:
>  > emacspeak-request@xxxxxxxxxxxxx with a subject of: unsubscribe