guile-user
[Top][All Lists]
Advanced

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

Re: Guile Studio's goals (and home)


From: Eli Zaretskii
Subject: Re: Guile Studio's goals (and home)
Date: Fri, 28 Feb 2020 15:33:50 +0200

> From: Ricardo Wurmus <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Tue, 25 Feb 2020 13:47:36 +0100
> 
> > As an Emacs co-maintainer, I was quite surprised to read the above,
> > since AFAIK none of these issues were ever communicated to the Emacs
> > developers.  If they were reported (using the Emacs built-in
> > bug-reporting command), I'm quite sure we would be very attentive to
> > such reports and amenable to adding/tweaking features so as to make
> > Emacs a better basis for Guile use and development.  After all, GNU
> > projects should help each other.
> >
> > So I urge you to report the problems on which you hint above, and
> > suggest changes or improvements that would remove at least some of the
> > need to tweak Emacs for being a "Guile Studio".
> 
> These are not necessarily problems with Emacs.  They are just annoyances
> that result from a mismatch of expectations. [...]
> 
> I don’t feel strongly enough about these things that I would push to
> change the defaults in Emacs.  But as an experienced Emacs user I feel
> confident enough to judge what Emacs features contribute to confusion,
> and to configure them in a way that mitigates or avoids the confusion.
> 
> The goal here is to point new Guilers to an IDE they can use without
> further configuration instead of telling them to install Emacs, install
> Geiser, install Company mode, install Flycheck and configure a Guile
> syntax checker, etc.  Guile Studio accomplishes this goal by configuring
> Emacs — not by forking Emacs.
> 
> I don’t think Emacs should have its defaults changed to be the best
> Guile editor out of the box.  It’s already the best editor (and more),
> in my opinion, but it may need extensive configuration to get reach its
> potential in different domains.

A "problem" doesn't necessarily have to be a bug or a deficiency, it
could also be a missing feature.  In this case, a missing feature
could perhaps be described as a lack of guile-ide.el package in Emacs,
which users of the Guile Studio could simply load, and magically have
their confusion taken care of.  Or maybe Emacs could have a
simple-ide.el package which would target more than just Guile users
(assuming at least part of the customizations you think are needed are
not specific to Guile).  Or it could be something else; or a
combination of several features separately selectable by users.

My point is that a need for extensive customizations might mean that
some more general issue exists that the Emacs developers may need to
address, either by default or as customizable options that aggregate
several related options (thus freeing the users from the need to
customize each one separately).  Describing those issues could
therefore be beneficial both for Emacs and for Guile.  So I still
think a detailed bug report could be a good idea, if only to have the
issues recorded in the Emacs issue tracker.

TIA



reply via email to

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