bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51819: The Senselessness of Emacs Company Mode


From: irenezerafa
Subject: bug#51819: The Senselessness of Emacs Company Mode
Date: Tue, 16 Nov 2021 20:23:08 +0000

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, November 16th, 2021 at 8:07 PM, Carlos Pita 
<carlosjosepita2@gmail.com> wrote:

> > > I understand the OP's frustration though, because this simplicity is not
> > > a given but the result of an exhausting process of research and
> > > refinement, there are a lot of options and (ill-)advice usually comes in
> > > the form of installing yet another extension. One has to learn many
> > > things that would be better not to know.
> >
> > I am pleased to see you understand my point, because the development 
> > geniuses
> >
> > can't.
>
> I don't think they don't understand your point, but as it is now your
> report is not really actionable. You might try your luck discussing
> the point in emacs-devel, even so company is not part of emacs but a
> development of the community, not to mention company extensions and
> extensions of extensions up to the nth degree.

There is a time that the project needs to clean things up a bit.  It is a basic
problem as things are accepted for inclusion.  I give texinfo as example.  
Because
originally, it was based on tex, its development has not migrated to a more
structured system such as latex, making some improvements basically impossible.

> Perhaps you believe
> that this is a consequence of some limitation of the builtin UI and/or
> protocol that triggered an extension industry around solving emacs
> shortcomings and may want to discuss that. I don't see anything
> terribly wrong in said UI and protocol, the UI may be a little clunky
> for current standards but it's sturdy, gets the job done and is easily
> replaceable (although I've argued for an improved builtin experience
> which doesn't seem too far-fetched) and the protocol is not as rich as
> company's but it's rich enough for most purposes and there is no way
> to prevent that a new extension X adds some novel feature, gains
> traction and a new X-.* extension industry flourishes, that's out of
> the maintainer's hands and, for better or worse, part of emacs DNA.

Have understood criticisms of change being slow though.  Getting the job done
is customarily the first iteration in software when working at a serious enough
place.  Being able to get the job done (i.e. hacking) seems to be enough for 
many
people, because design is much more demanding.  I experienced this in industry,
with the result that things started to be rewritten rather that fixed or wasting
months or years trying to follow the haphazard evolution of the software.

> Best regards,
>
> Carlos





reply via email to

[Prev in Thread] Current Thread [Next in Thread]