Guile Studio's goals (and home)

Guile Studio's goals (and home)

[sirgazil]

Hi,

I want a Guile IDE, and Guile Studio describes itself as such in its Guix package description, so I'd like to know more about it.

• What are Guile Studio's goals?  
• What is its relationship with the GNU Guile project? 
• 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?
• Current Guile Studio version is 0.0.2. Any plans for a future version?

Thanks,

---
https://sirgazil.bitbucket.io/

Re: Guile Studio's goals (and home)

[Ricardo Wurmus]

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)

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> 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)

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ricardo Wurmus <rekado@elephly.net>
>> 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)

[zimoun]

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

Re: Guile Studio's goals (and home)

[Eli Zaretskii]

> 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

Re: Guile Studio's goals (and home)

[sirgazil]

 ---- On Tue, 25 Feb 2020 04:12:31 -0500 Ricardo Wurmus <rekado@elephly.net> wrote ----
 > 
 > 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!


No, thank you for the detailed information.

Re: Guile Studio's goals (and home)

[sirgazil]

 ---- On Fri, 28 Feb 2020 08:33:50 -0500 Eli Zaretskii <eliz@gnu.org> wrote ----
 > > 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.

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...

Re: Guile Studio's goals (and home)

[Eli Zaretskii]

> Date: Fri, 28 Feb 2020 11:02:00 -0500
> From: sirgazil <sirgazil@zoho.com>
> Cc: "Ricardo Wurmus" <rekado@elephly.net>, "guile-user" <guile-user@gnu.org>
> 
>  > 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." 

Emacs is very old, but new packages and features are being added to it
all the time.  Just look at the NEWS file of any Emacs release, and
you will see that clearly.

> Maybe I'll send something...

Please do, and TIA.

Re: Guile Studio's goals (and home)

[Arne Babenhauserheide]

Eli Zaretskii <eliz@gnu.org> writes:
> 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.

There is a problem I see: I cannot easily share configurations that can
be loaded with use-package. The main reason for that is that melpa
rejects meta-packages which only setup other packages and adjust some
configuration values.

Another aspect is that "use Emacs for X" is a major selling point of
many publicly shared configurations. If you look outside the box and
check IntelliJ, you’ll see that JetBrains sells several customizations
for specific usecases, so this is not unique to Emacs.

TLDR: It would be nice if Emacs could at startup offer users to select a
customization for a specific use-case.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Guile Studio's goals (and home)

[Eli Zaretskii]

> From: Arne Babenhauserheide <arne_bab@web.de>
> Date: Sat, 29 Feb 2020 22:15:05 +0100
> 
> TLDR: It would be nice if Emacs could at startup offer users to select a
> customization for a specific use-case.

Please report this using "M-x report-emacs-bug", so that an issue is
open with the Emacs issue tracker.

Thanks.

Re: Guile Studio's goals (and home)

[Arne Babenhauserheide]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arne Babenhauserheide <arne_bab@web.de>
>> Date: Sat, 29 Feb 2020 22:15:05 +0100
>> 
>> TLDR: It would be nice if Emacs could at startup offer users to select a
>> customization for a specific use-case.
>
> Please report this using "M-x report-emacs-bug", so that an issue is
> open with the Emacs issue tracker.

done :-)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Guile Studio's goals (and home)

[sirgazil]

 ---- On Fri, 28 Feb 2020 11:02:00 -0500 sirgazil <sirgazil@zoho.com> wrote ----
 >  ---- On Fri, 28 Feb 2020 08:33:50 -0500 Eli Zaretskii <eliz@gnu.org> wrote ----
 >  > > 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.
 > 
 > 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

Re: Guile Studio's goals (and home)

[Eli Zaretskii]

> Date: Tue, 03 Mar 2020 13:31:38 -0500
> From: sirgazil <sirgazil@zoho.com>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, "Ricardo Wurmus" <rekado@elephly.net>,
> 	"guile-user" <guile-user@gnu.org>
> 
>  > 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

Thanks.