Re: Guile Studio's goals (and home)
Hi! > • What are Guile Studio's goals? 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. Everything that serves to avoid confusion is welcome in Guile Studio. > • What is its relationship with the GNU Guile project? There is none. I’m just a Guile enthusiast who thought that Guile Studio would be a good thing to build. > • The homepage field in the Guix package points to GNU Guile's > website. Should I send future questions and issues to Guile's lists > and issue tracker? I don’t know. Whether to use the Guile bug tracker is up for the Guile maintainers to decide. I think it’s fine to use the guile-user list, though. I’m subscribed to guile-user. > • Current Guile Studio version is 0.0.2. Any plans for a future version? Once Emacs 27 is released I’ll probably have to adjust a few things. Perhaps I’ll also configure the use of tabs then. There are many more things that could be done to improve the experience (buffer handling is still a big pain point; documentation needs to be better integrated, etc), but I don’t think I can spend as much time on this as I used to. I’ll gladly discuss and merge patches, though. Thank you for your interest in Guile Studio! -- Ricardo
Re: Guile Studio's goals (and home)
> From: Ricardo Wurmus > Date: Tue, 25 Feb 2020 10:12:31 +0100 > Cc: guile-user@gnu.org > > 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". TIA
Re: Guile Studio's goals (and home)
Eli Zaretskii writes: >> From: Ricardo Wurmus >> Date: Tue, 25 Feb 2020 10:12:31 +0100 >> Cc: guile-user@gnu.org >> >> 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
Re: Guile Studio's goals (and home)
Hi, I am an Emacs user. >From my perspective, Guile Studio is a first experimental attempt between DrRacket and racket-mode for GNU Guile. Other said, it is a specialized cosmetic of Emacs for programming in Scheme using Guile out-of-the-box. In my labs, people do not even know what an editor is and I am pushing to use Guix. Well, at one moment or another, one user needs to know small piece of Scheme. Or at least, they need to be able to open .scm files, read them, and time to time modify the recipe of a package. The learning curve of Emacs is too much; going from nothing (or at best they use RStudio) to Emacs for editing package definition is too much. Guile Studio could fill the gap, IMHO. Moreover, note the Guix Workflow Language (GWL) is under development. Its goal is an alternative to Snakemake (Python flavoured) to write pipelines for analysing biological data. Therefore, GWL targets users without any experience to Emacs and Guile Studio should be the default editor to compose these pipelines. And it should be a way to popularize Emacs to the non-Emacs users. https://docs.racket-lang.org/drracket/interface-essentials.html http://workflows.guix.info/ All the best, simon
