From: Eli Zaretskii <eliz@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guile-user@gnu.org
Subject: Re: Guile Studio's goals (and home)
Date: Fri, 28 Feb 2020 15:33:50 +0200 [thread overview]
Message-ID: <83pndyg7k1.fsf@gnu.org> (raw)
In-Reply-To: <87d0a2kf4n.fsf@elephly.net> (message from Ricardo Wurmus on Tue, 25 Feb 2020 13:47:36 +0100)
> From: Ricardo Wurmus <rekado@elephly.net>
> Cc: sirgazil@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.
TIA
next prev parent reply other threads:[~2020-02-28 13:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 18:47 Guile Studio's goals (and home) sirgazil
2020-02-25 9:12 ` Ricardo Wurmus
2020-02-25 10:30 ` Eli Zaretskii
2020-02-25 12:47 ` Ricardo Wurmus
2020-02-25 14:25 ` zimoun
2020-02-28 13:33 ` Eli Zaretskii [this message]
2020-02-28 16:02 ` sirgazil
2020-02-28 16:22 ` Eli Zaretskii
2020-03-03 18:31 ` sirgazil
2020-03-03 19:27 ` Eli Zaretskii
2020-02-29 21:15 ` Arne Babenhauserheide
2020-03-01 3:30 ` Eli Zaretskii
2020-03-01 8:31 ` Arne Babenhauserheide
2020-02-28 14:58 ` sirgazil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83pndyg7k1.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=guile-user@gnu.org \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).