Re: Guile Studio's goals (and home)

[sirgazil]

 ---- On Fri, 28 Feb 2020 11:02:00 -0500 sirgazil <address@hidden> wrote ----
 >  ---- 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...

I reported a feature request for a "guile-mode": 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39888