---- On Fri, 28 Feb 2020 11:02:00 -0500 sirgazil <sirga...@zoho.com> wrote ---- > ---- On Fri, 28 Feb 2020 08:33:50 -0500 Eli Zaretskii <e...@gnu.org> wrote > ---- > > > From: Ricardo Wurmus <rek...@elephly.net> > > > Cc: sirga...@zoho.com, guile-user@gnu.org > > > 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
