Re: Guile Studio's goals (and home)

[Ricardo Wurmus]

Eli Zaretskii <address@hidden> writes:

>> From: Ricardo Wurmus <address@hidden>
>> Date: Tue, 25 Feb 2020 10:12:31 +0100
>> Cc: address@hidden
>>
>> The pretentiously named “Guile Studio” arose from the observation that
>> we often tell new Guile users to learn how to use Emacs first in order
>> to get a comfortable Guile development experience.  Since Emacs has
>> really quirky defaults that don’t mesh with the expectations of people
>> who learn a new programming language, this can be so discouraging
>> that the person abandons the initial goal of learning Guile.
>>
>> Many people in the past had the idea to “fix” Emacs.  “Guile Studio” is
>> not intended to be yet another Emacs starter kit like Prelude, Doom, or
>> Spacemacs.  Instead it tries to focus on just Guile, going as far as to
>> remove “Emacs” from the window title and the menus.
>>
>> My goal was to provide a friendly editor that does not require any
>> configuration to use and play with Guile.  You install Guile Studio and
>> get started right away.  It tries to be what Dr Racket is for Racket and
>> what RStudio is for R.
>>
>> This is why Guile Studio comes with the picture language and immediately
>> spawns a Geiser session where it can be used.  It hides Emacs clutter
>> from the menus and adds menu items that are relevant to new Guile users,
>> such as a link to the Guile manual.  It aims to handle documentation
>> buffers specially to avoid the confusion that comes with Emacs-typical
>> “buffer clutter”.  It uses CUA key bindings to avoid annoying surprises.
>
> 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.  What I call “buffer
clutter” — the fact that a new buffer is displayed, hiding other
buffers, or that windows are automatically split — is not really an
issue for an experienced Emacs user, but it can be disorienting for
users who have no concept of buffers and are not familiar with the
mechanisms to navigate them.

Enabling CUA mode by default stems from the same desire to reduce
confusion.  Personally, I don’t use CUA mode, but I have observed
countless new users who were confused by C-x, C-z, etc in vanilla Emacs.

The menus are pretty full in Emacs.  Many proficient Emacs users disable
them altogether.  In Guile Studio I like to keep them enabled but with
their contents reduced to the essential: no psychotherapist, no
postscript print buffer, no “Tools” menu with “Games”, “Encryption”,
“Read Mail”, etc.

All of these things are customizable, so Guile Studio customizes them.

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.

--
Ricardo