[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile Studio's goals (and home)
From: |
sirgazil |
Subject: |
Re: Guile Studio's goals (and home) |
Date: |
Fri, 28 Feb 2020 11:02:00 -0500 |
User-agent: |
Zoho Mail |
---- On Fri, 28 Feb 2020 08:33:50 -0500 Eli Zaretskii <address@hidden> wrote
----
> > 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.
Personally, I avoid sending these kinds of issue reports to Emacs because I
think to myself, "Emacs is GNU, Guile is GNU; the IDE functionality I want is
common across IDEs; Emacs is very old; if this functionality is not in Emacs
it's because they don't use it, or don't want it."
But I guess it wouldn't hurt to try. If something good comes out of it (e.g. a
default guile-ide), maybe Guile Studio could also benefit from it (if there is
still a need for a Guile Studio).
Maybe I'll send something...
Re: Guile Studio's goals (and home), sirgazil, 2020/02/28