Re: The e(macs)lephant in the room and the Guix Bang

Re: The e(macs)lephant in the room and the Guix Bang

[Nathan Dehnel]

________________________________

>Hi, for some reason emacs has become the elephant in the room of the
discussion on contributing to guix.

>Regardless of one's opinion of emacs, I just want to add that this is
itself strange.  I have contributed some (package definition) patches
to guix, all without using emacs.

>I am not an emacs user, so emacs is not necessary for contributing to guix.
For what it's worth, the emacs-motif package in Guix was my addition.
I don't use it myself.

I don't use emacs either (because it's so impenetrable), so I just use
kate instead, which isn't a great environment for me either. It has
rainbow parens, but it doesn't balance them, which is a hassle. I keep
using it though due to lack of time to browse through alternatives. I
heard about guile-studio, but it doesn't appear to have a dark mode,
and I imagine trying to add one would require a bunch of emacs-style
screwing around with it.

https://archive.fosdem.org/2022/schedule/event/lispforeveryone/
This is the only setup for coding in lisp that has actually looked
attractive to me. (Coding in wisp with colored blocks that transpiles
to s-expressions) Though I haven't had the time (and probably
expertise) to set it up for myself.

Re: The e(macs)lephant in the room and the Guix Bang

[Janneke Nieuwenhuizen]

Nathan Dehnel writes:

> I don't use emacs either (because it's so impenetrable)

Emacs might be somewhat different from what you know, but this is utter
bollocks.

Switching to Emacs (from vi) took me three summers.  I kept trying
because I had seen how helpful it was, and well the statement that "the
GNU project will use it as its editor".

That was some 25y ago and it was time very well spent.  After I
switched, I taught it to my dad for his latex editing, who went on to
create patches for the Dutch tutorial because he wanted to give back
something..  If he could learn, most anyone should be able to pick it
up.

People are still indenting their code manually today, etc... it's
ridiculous.  Also, magit.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: The e(macs)lephant in the room and the Guix Bang

[paul]

Dear Janneke,

On 9/23/23 09:37, Janneke Nieuwenhuizen wrote:
> Nathan Dehnel writes:
>
>> I don't use emacs either (because it's so impenetrable)
> Emacs might be somewhat different from what you know, but this is utter
> bollocks.

Thank you for your opinion but it's just that: a subjective judgement 
based on your own episodic experience. Which is definitely valid but 
unrealistically shared by so many to be able to define Nathan's 
experience "utter bollocks".

I think this attitude (in my experience typical of GNU maintainers) 
where their way of doing computation is more blessed or holier or better 
sometimes really ruins the social interactions happening around Guix 
(which is the safest  community in the GNU project imho, probably also 
due to the distance they rightfully posed during the whole stallman drama).

It's especially problematic when people in power such as maintainers do 
not realize their role in the community. You have more power, probably 
due to your investment you have a clearer vision of where the project is 
going as well. You are supposed to be a role model for new users and 
contributors.

> If he could learn, most anyone should be able to pick it
> up.
> People are still indenting their code manually today, etc... it's
> ridiculous.
This behavior is not ok. Again, please, stop throwing your judgement on 
people. Potential users or contributors even.
> Also, magit.

I use Emacs, love magit, I used to use it daily also at $day_job on 
Windows because it's just so good, but I can assure you most of Git 
users never heard of it and live their life pretty happily.

giacomo

Re: The e(macs)lephant in the room and the Guix Bang

[Janneke Nieuwenhuizen]

paul writes:

Dear Paul,

> On 9/23/23 09:37, Janneke Nieuwenhuizen wrote:
>> Nathan Dehnel writes:
>>
>>> I don't use emacs either (because it's so impenetrable)
>> Emacs might be somewhat different from what you know, but this is utter
>> bollocks.
>
> Thank you for your opinion but it's just that: a subjective judgement
> based on your own episodic experience.

I'm sorry if my tone was too harsh, I now realise this is still
triggering old pain.

Why is it still OK to for people to keep spreading negative anecdotes
about Emacs, and problematic to refute them or counter them with
positive anecdotes?

It's been me believing exactly such lies that scared me away from
starting with Emacs for years, lost years in a way; something I deeply
regret: this has to stop.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: The e(macs)lephant in the room and the Guix Bang

[Nathan Dehnel]

>I'm sorry if my tone was too harsh, I now realise this is still
triggering old pain.

>Why is it still OK to for people to keep spreading negative anecdotes
about Emacs, and problematic to refute them or counter them with
positive anecdotes?

It was a mistake to say that. I felt the reflexive need to justify why
I don't use emacs, or else people would just tell me to use it anyways
as a result of talking about not knowing of a decent (alternative)
lisp editor.

>It's been me believing exactly such lies that scared me away from
starting with Emacs for years, lost years in a way; something I deeply
regret: this has to stop.

I want to clarify that I'm not just repeating rumors and I actually
have tried to use emacs.

On Sat, Sep 23, 2023 at 5:00 AM Janneke Nieuwenhuizen <janneke@gnu.org> wrote:
>
> paul writes:
>
> Dear Paul,
>
> > On 9/23/23 09:37, Janneke Nieuwenhuizen wrote:
> >> Nathan Dehnel writes:
> >>
> >>> I don't use emacs either (because it's so impenetrable)
> >> Emacs might be somewhat different from what you know, but this is utter
> >> bollocks.
> >
> > Thank you for your opinion but it's just that: a subjective judgement
> > based on your own episodic experience.
>
> I'm sorry if my tone was too harsh, I now realise this is still
> triggering old pain.
>
> Why is it still OK to for people to keep spreading negative anecdotes
> about Emacs, and problematic to refute them or counter them with
> positive anecdotes?
>
> It's been me believing exactly such lies that scared me away from
> starting with Emacs for years, lost years in a way; something I deeply
> regret: this has to stop.
>
> Greetings,
> Janneke
>
> --
> Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
> Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: The e(macs)lephant in the room and the Guix Bang

[Liliana Marie Prikler]

Am Sonntag, dem 24.09.2023 um 02:37 -0500 schrieb Nathan Dehnel:
> > I'm sorry if my tone was too harsh, I now realise this is still
> > triggering old pain.
> 
> > Why is it still OK to for people to keep spreading negative
> > anecdotes about Emacs, and problematic to refute them or counter
> > them with positive anecdotes?
> 
> It was a mistake to say that. I felt the reflexive need to justify
> why I don't use emacs, or else people would just tell me to use it
> anyways as a result of talking about not knowing of a decent
> (alternative) lisp editor.
I mean, you could try using it anyways, whether it's vanilla emacs,
customized emacs, guile studio, or the heavily popularized spacemacs,
doom, etc. variants.  On the Guix side, it doesn't really matter, our
configuration works with packages based on Emacs.

It's fine if you prefer another editor, but don't count on us to write
documentation for every editor out there, especially when it almost
always turns out to be invoking "guix edit" followed by "git commit …"
or perhaps using that editor's built-in VC integration to do so.  I'm
also not convinced you need to bring the big guns of lisp editing to
the table.  From personal experience, an editor that autocompletes the
closing bracket and has parentheses matching capabilities suffices. 
The latter is even implemented by crude tools such as gnome-text-
editor.

> > It's been me believing exactly such lies that scared me away from
> > starting with Emacs for years, lost years in a way; something I
> > deeply regret: this has to stop.
> 
> I want to clarify that I'm not just repeating rumors and I actually
> have tried to use emacs.
There is a wide span of "tried emacs".  I personally wouldn't say I've
"tried" vi after hitting ESC :q once and being done or even that I've
tried using ed after vaguely figuring out how you can make it actually
change the contents of a file.

Now whether you want to qualify your experience further or not is up to
you, and even if you do, your personal choice of a suitable editor
remains personal.  However, I don't think that repeating the age old
jokes of "herp derp, me no likes defaults" as has happened in other
branches of this topic is helpful.  *The defaults in Emacs do not
matter.*  You don't need to be happy with the editor you get out of the
box.  You can change it into the editor you want and there's ample
documentation on how to do so.  Coming full circle, this is why we
reference Emacs in the manual, enough people collaborated to suggest a
workflow that works for them or at least goes in the right direction. 
However, I think it's fair to say that most folks' setup will differ
ever so slightly from what is presented there.

Cheers

Re: The e(macs)lephant in the room and the Guix Bang

[MSavoritias]

On 9/24/23 11:51, Liliana Marie Prikler wrote:
> Am Sonntag, dem 24.09.2023 um 02:37 -0500 schrieb Nathan Dehnel:
>>> I'm sorry if my tone was too harsh, I now realise this is still
>>> triggering old pain.
>>> Why is it still OK to for people to keep spreading negative
>>> anecdotes about Emacs, and problematic to refute them or counter
>>> them with positive anecdotes?
>> It was a mistake to say that. I felt the reflexive need to justify
>> why I don't use emacs, or else people would just tell me to use it
>> anyways as a result of talking about not knowing of a decent
>> (alternative) lisp editor.
> I mean, you could try using it anyways, whether it's vanilla emacs,
> customized emacs, guile studio, or the heavily popularized spacemacs,
> doom, etc. variants.  On the Guix side, it doesn't really matter, our
> configuration works with packages based on Emacs.
>
> It's fine if you prefer another editor, but don't count on us to write
> documentation for every editor out there, especially when it almost
> always turns out to be invoking "guix edit" followed by "git commit …"
> or perhaps using that editor's built-in VC integration to do so.  I'm
> also not convinced you need to bring the big guns of lisp editing to
> the table.  From personal experience, an editor that autocompletes the
> closing bracket and has parentheses matching capabilities suffices.
> The latter is even implemented by crude tools such as gnome-text-
> editor.

How about we start with two editors then besides vanilla Emacs then?

Because we don't even have two now.

>>> It's been me believing exactly such lies that scared me away from
>>> starting with Emacs for years, lost years in a way; something I
>>> deeply regret: this has to stop.
>> I want to clarify that I'm not just repeating rumors and I actually
>> have tried to use emacs.
> There is a wide span of "tried emacs".  I personally wouldn't say I've
> "tried" vi after hitting ESC :q once and being done or even that I've
> tried using ed after vaguely figuring out how you can make it actually
> change the contents of a file.
>
> Now whether you want to qualify your experience further or not is up to
> you, and even if you do, your personal choice of a suitable editor
> remains personal.  However, I don't think that repeating the age old
> jokes of "herp derp, me no likes defaults" as has happened in other
> branches of this topic is helpful.  *The defaults in Emacs do not
> matter.*  You don't need to be happy with the editor you get out of the
> box.  You can change it into the editor you want and there's ample
> documentation on how to do so.  Coming full circle, this is why we
> reference Emacs in the manual, enough people collaborated to suggest a
> workflow that works for them or at least goes in the right direction.
> However, I think it's fair to say that most folks' setup will differ
> ever so slightly from what is presented there.
>
> Cheers
>
>
That's the thing you are missing.

The default of Emacs absolutely do matter.

Because

1. not everybody has time to learn elisp and configure Emacs so it 
doesn't break.

2. By how the defaults are you see how the community around a program is.

If the defaults are good and empower the person using the program that 
means that the community is open

to suggestions and changes at the very least. which is not what happens 
with Emacs.

This is from someone who uses Emacs.


MSavoritias

Re: The e(macs)lephant in the room and the Guix Bang

[Liliana Marie Prikler]

Am Montag, dem 25.09.2023 um 14:19 +0300 schrieb MSavoritias:
> 
> On 9/24/23 11:51, Liliana Marie Prikler wrote:
> > [...]
> > It's fine if you prefer another editor, but don't count on us to
> > write documentation for every editor out there [...]
> 
> How about we start with two editors then besides vanilla Emacs then?
> 
> Because we don't even have two now.
Well, assuming you count Emacs variants (given the "vanilla" prefix
it'd only be fair if you did), we actually have at least four covered
with the manual, if not more. :)

As for other editors, I point to the sign above, with "us" being folks
who are happy to contribute to Guix from Emacs.  I know there are vi
folk out there who could probably make our section on "The Perfect
Setup" less biased, but I neither want nor am able to speak on their
behalf when it comes to actually doing so.

> > > > It's been me believing exactly such lies that scared me away
> > > > from starting with Emacs for years, lost years in a way;
> > > > something I deeply regret: this has to stop.
> > > I want to clarify that I'm not just repeating rumors and I
> > > actually have tried to use emacs.
> > There is a wide span of "tried emacs".  I personally wouldn't say
> > I've "tried" vi after hitting ESC :q once and being done or even
> > that I've tried using ed after vaguely figuring out how you can
> > make it actually change the contents of a file.
> > 
> > Now whether you want to qualify your experience further or not is
> > up to you, and even if you do, your personal choice of a suitable
> > editor remains personal.  However, I don't think that repeating the
> > age old jokes of "herp derp, me no likes defaults" as has happened
> > in other branches of this topic is helpful.  *The defaults in Emacs
> > do not matter.*  You don't need to be happy with the editor you get
> > out of the box.  You can change it into the editor you want and
> > there's ample documentation on how to do so.  Coming full circle,
> > this is why we reference Emacs in the manual, enough people
> > collaborated to suggest a workflow that works for them or at least
> > goes in the right direction.  However, I think it's fair to say
> > that most folks' setup will differ ever so slightly from what is
> > presented there.
> > 
> > Cheers
> > 
> > 
> That's the thing you are missing.
> 
> The default of Emacs absolutely do matter.
> 
> Because
> 
> 1. not everybody has time to learn elisp and configure Emacs so it 
> doesn't break.
> 
> 2. By how the defaults are you see how the community around a program
> is.
> 
> If the defaults are good and empower the person using the program
> that means that the community is open to suggestions and changes at
> the very least. which is not what happens with Emacs.
> 
> This is from someone who uses Emacs.
I share neither the experience nor the argument.  Now granted, I do see
the appeal of preconfigured Emacsen for those who don't want to go
through the trouble of configuring it for themselves; however, there is
no "one size fits all" solution among these offerings as far as I can
see.  In fact, I'd argue the opposite, as they themselves have to offer
customization so to appeal to a broader audience.  For all the rant
about how insane the defaults of Emacs are, the various "sane defaults"
offered by others sure tend in various different directions.  It's
almost as though coding for the common case leaves many people out and
the customization mechanism is what actually empowers users.

Cheers

Re: The e(macs)lephant in the room and the Guix Bang

[Simon Tournier]

Hi,

On Mon, 25 Sep 2023 at 20:54, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

>> The default of Emacs absolutely do matter.

[...]

> I share neither the experience nor the argument. 

[...]

Please, we are not on the emacs-devel mailing list. :-)  Or maybe, we
need to create some guix-tagents mailing list. ;-)

Cheers,
simon

Re: The e(macs)lephant in the room and the Guix Bang

[MSavoritias]

On 9/23/23 13:00, Janneke Nieuwenhuizen wrote:
> paul writes:
>
> Dear Paul,
>
>> On 9/23/23 09:37, Janneke Nieuwenhuizen wrote:
>>> Nathan Dehnel writes:
>>>
>>>> I don't use emacs either (because it's so impenetrable)
>>> Emacs might be somewhat different from what you know, but this is utter
>>> bollocks.
>> Thank you for your opinion but it's just that: a subjective judgement
>> based on your own episodic experience.
> I'm sorry if my tone was too harsh, I now realise this is still
> triggering old pain.
>
> Why is it still OK to for people to keep spreading negative anecdotes
> about Emacs, and problematic to refute them or counter them with
> positive anecdotes?
>
> It's been me believing exactly such lies that scared me away from
> starting with Emacs for years, lost years in a way; something I deeply
> regret: this has to stop.
>
> Greetings,
> Janneke
>
Depends what Emacs you mean.

The vanilla Emacs experience is traditionally horrible until you start 
tweaking it.

And it for years the maintainers of Emacs refuse to do anything to fix 
it. So I would say complaints are pretty valid

when its the same people that push Emacs as the "blessed" way to 
contribute (as in the guix manual) and then people see Emacs vanilla and 
cant use it.


The problematic is not that you say positive stuff about Emacs. I have a 
lot of positive stuff to say too :)

The problem part is the way you dismissed the persons experience as 
"bollocks". The knowledge that the Emacs community is pretty 
conservative in changing anything for decades in the default config also 
doesn't help.


MSavoritias

Emacs and Guix (was Re: The e(macs)lephant in the room and the Guix Bang)

[Simon Tournier]

Hi,

On Mon, 25 Sep 2023 at 14:09, MSavoritias <email@msavoritias.me> wrote:

> when its the same people that push Emacs as the "blessed" way to 
> contribute (as in the guix manual)

Just to point 1. Guix is part of GNU – for the good, the bad and the
ugly – so 2. editors developed under the GNU umbrella are autopromoted –
GNU Emacs is one, GNU nano would be another one.  Well, for what it is
worth, I feel such autopromotion as some consistency.

BTW, Efraim is GNU Guix co-maintainer and demoed the use of Vim for Guix
development:

    https://10years.guix.gnu.org/video/using-vim-for-guix-development/

Somehow, when one co-maintainer publicly demoed using not-Emacs makes a
point that there is no “blessed“ editors – and the part dedicated for
Emacs in the manual seems just an autopromotion of GNU products that
contributors enjoy for cooking – dogfooding. ;-).

Contributions in the Guix manual or in the cookbook about how to setup
other editors than Emacs are very welcome.


> The problem part is the way you dismissed the persons experience as 
> "bollocks".

From where I stand, I feel a lot of negative rants, coming from
frustration or generating frustration.  The best against frustration,
from all sides, is to send positive feedback for being engaging and thus
unlock or tackle concrete issues.  Well, my 2 cents. :-)


Last, in all what I am reading in this thread or elsewhere about the
relationship between Emacs and Guix or between Guix and Emacs, I have
the bad taste that a part of the Guile manual had been lost in
translation:

    The Emacs Thesis

    The story of Guile is the story of bringing the development experience
    of Emacs to the mass of programs on a GNU system.

    [...]

    After the Emacs experience was appreciated more widely, a number of
    hackers started to consider how to spread this experience to the rest of
    the GNU system. It was clear that the easiest way to Emacsify a program
    would be to embed a shared language implementation into it.

    https://www.gnu.org/software/guile/manual/html_node/The-Emacs-Thesis.html

Guix is this GNU System, isn’t it?

And then Ludo explicitly expressed such goal for Guix [1]: « What about
following that Emacs meme for a complete distro? That's what the GNU
Guix project has been trying to answer. »

Emacs principles and design are part of the Guix DNA.  Part of the DNA
does not mean twin, it means share some relative.  Emacs is not a
mandatory tool for contributing, obviously not!  The point is that many
of us are seeing a continuum between Emacs and Guix for doing their
computations and similarly as I am promoting Guix because it has
radically changed my view of package and system management, I am also
promoting Emacs because it has radically changed my view of interacting
with computers.  Because both are rooted in the same principles.

IMHO, this explains the place of Emacs in the Guix ecosystem.  Many
contributors had or still share this point of view between Emacs and
Guix.  And it is up to people that are not sharing « The Emacs Thesis »
to promote their tools; free software is not about consuming a product
but about sharing what you have.

1: https://archive.fosdem.org/2015/schedule/event/the_emacs_of_distros/


Cheers,
simon

Re: Emacs and Guix (was Re: The e(macs)lephant in the room and the Guix Bang)

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

On Mon, Sep 25, 2023 at 10:34:11PM +0200, Simon Tournier wrote:
> Hi,
> 
> On Mon, 25 Sep 2023 at 14:09, MSavoritias <email@msavoritias.me> wrote:
> 
> > when its the same people that push Emacs as the "blessed" way to 
> > contribute (as in the guix manual)
> 
> Just to point 1. Guix is part of GNU – for the good, the bad and the
> ugly – so 2. editors developed under the GNU umbrella are autopromoted –
> GNU Emacs is one, GNU nano would be another one.  Well, for what it is
> worth, I feel such autopromotion as some consistency.
> 
> BTW, Efraim is GNU Guix co-maintainer and demoed the use of Vim for Guix
> development:
> 
>     https://10years.guix.gnu.org/video/using-vim-for-guix-development/
> 
> Somehow, when one co-maintainer publicly demoed using not-Emacs makes a
> point that there is no “blessed“ editors – and the part dedicated for
> Emacs in the manual seems just an autopromotion of GNU products that
> contributors enjoy for cooking – dogfooding. ;-).

Oh no! My very embarrassing talk where I was missing that magic 1 or 2
packages from my manifest and then everything fell apart. I think I need
to watch it again myself and then try redoing it at home.

> Contributions in the Guix manual or in the cookbook about how to setup
> other editors than Emacs are very welcome.

This is the big part. I have a setup that works reasonably well for me
and I haven't done a good job sharing it with others so they can see
some of the other options.

IIRC one of the big things I wanted to show was using ctags with Guix to
jump quickly between packages or to other definitions. Right now the
tags make target is a stub, I (or someone else even) should see about
adjusting that so 'make tags' works for the project.


-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: The e(macs)lephant in the room and the Guix Bang

[Munyoki Kilyungi]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

Janneke Nieuwenhuizen <janneke@gnu.org> aliandika:


[...]


>>
>> Thank you for your opinion but it's just that: a subjective judgement
>> based on your own episodic experience.
>
> I'm sorry if my tone was too harsh, I now realise this is still
> triggering old pain.
>
> Why is it still OK to for people to keep spreading negative anecdotes
> about Emacs, and problematic to refute them or counter them with
> positive anecdotes?
>
> It's been me believing exactly such lies that scared me away from
> starting with Emacs for years, lost years in a way; something I deeply
> regret: this has to stop.
>

This I agree with.  I got into Emacs about a
decade ago.  And what helped me I guess, was that
no one in my environment used Emacs nor knew too
much about it.  And the internet wasn't as fast as
it is now.  So in a sense, I got into the
ecosystem "by faith", and it stuck.  However, this
is not the case today.  I'm running a SICP reading
book club community locally, and the feedback I'm
getting from people who are trying it out, is that
it's "very difficult to learn", and most of these
sentiments are from the internet.


-- 
(Life is like a pencil that will surely run out,
    but will leave the beautiful writing of life.)
(D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
    (hkp://keys.openpgp.org))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 865 bytes --]

The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang)

[indieterminacy]

I would assume that people who dont use Emacs are entitled to document 
their experiences using their weapon(s) of choice within the Guix 
knowledge corpus.

Sure, consider and discuss governance and workflows... but people 
complaining that Emacs users have documented their techniques to a 
better standard than non Emacs users within an operating system's 
documentation is bordering on the ridiculous.

On 23-09-2023 10:58, paul wrote:
> Dear Janneke,
> 
> On 9/23/23 09:37, Janneke Nieuwenhuizen wrote:
>> Nathan Dehnel writes:
>> 
>>> I don't use emacs either (because it's so impenetrable)
>> Emacs might be somewhat different from what you know, but this is 
>> utter
>> bollocks.
> 
> Thank you for your opinion but it's just that: a subjective judgement 
> based on your own episodic experience. Which is definitely valid but 
> unrealistically shared by so many to be able to define Nathan's 
> experience "utter bollocks".
> 
> I think this attitude (in my experience typical of GNU maintainers) 
> where their way of doing computation is more blessed or holier or 
> better sometimes really ruins the social interactions happening around 
> Guix (which is the safest  community in the GNU project imho, probably 
> also due to the distance they rightfully posed during the whole 
> stallman drama).
> 
> It's especially problematic when people in power such as maintainers do 
> not realize their role in the community. You have more power, probably 
> due to your investment you have a clearer vision of where the project 
> is going as well. You are supposed to be a role model for new users and 
> contributors.
> 
>> If he could learn, most anyone should be able to pick it
>> up.
>> People are still indenting their code manually today, etc... it's
>> ridiculous.
> This behavior is not ok. Again, please, stop throwing your judgement on 
> people. Potential users or contributors even.
>> Also, magit.
> 
> I use Emacs, love magit, I used to use it daily also at $day_job on 
> Windows because it's just so good, but I can assure you most of Git 
> users never heard of it and live their life pretty happily.
> 
> giacomo

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang)

[MSavoritias]

On 9/23/23 15:59, indieterminacy wrote:
> I would assume that people who dont use Emacs are entitled to document 
> their experiences using their weapon(s) of choice within the Guix 
> knowledge corpus.
>
> Sure, consider and discuss governance and workflows... but people 
> complaining that Emacs users have documented their techniques to a 
> better standard than non Emacs users within an operating system's 
> documentation is bordering on the ridiculous.
>
The discussion at least the last couple of weeks have been on lessening 
the difficulty to contribute.

So saying that the people who don't know guile or guix need to first 
contribute docs is pretty ridiculous.

MSavoritias

> On 23-09-2023 10:58, paul wrote:
>> Dear Janneke,
>>
>> On 9/23/23 09:37, Janneke Nieuwenhuizen wrote:
>>> Nathan Dehnel writes:
>>>
>>>> I don't use emacs either (because it's so impenetrable)
>>> Emacs might be somewhat different from what you know, but this is utter
>>> bollocks.
>>
>> Thank you for your opinion but it's just that: a subjective judgement 
>> based on your own episodic experience. Which is definitely valid but 
>> unrealistically shared by so many to be able to define Nathan's 
>> experience "utter bollocks".
>>
>> I think this attitude (in my experience typical of GNU maintainers) 
>> where their way of doing computation is more blessed or holier or 
>> better sometimes really ruins the social interactions happening 
>> around Guix (which is the safest community in the GNU project imho, 
>> probably also due to the distance they rightfully posed during the 
>> whole stallman drama).
>>
>> It's especially problematic when people in power such as maintainers 
>> do not realize their role in the community. You have more power, 
>> probably due to your investment you have a clearer vision of where 
>> the project is going as well. You are supposed to be a role model for 
>> new users and contributors.
>>
>>> If he could learn, most anyone should be able to pick it
>>> up.
>>> People are still indenting their code manually today, etc... it's
>>> ridiculous.
>> This behavior is not ok. Again, please, stop throwing your judgement 
>> on people. Potential users or contributors even.
>>> Also, magit.
>>
>> I use Emacs, love magit, I used to use it daily also at $day_job on 
>> Windows because it's just so good, but I can assure you most of Git 
>> users never heard of it and live their life pretty happily.
>>
>> giacomo
>

Re: The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang)

[Simon Tournier]

Hi,

On Mon, 25 Sep 2023 at 14:13, MSavoritias <email@msavoritias.me> wrote:

> So saying that the people who don't know guile or guix need to first 
> contribute docs is pretty ridiculous.

Why?  Could you explain more why it appears to you “ridiculous”?

Cheers,
simon

Re: The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang)

[indieterminacy]

On 25-09-2023 22:35, Simon Tournier wrote:
> Hi,
> 
> On Mon, 25 Sep 2023 at 14:13, MSavoritias <email@msavoritias.me> wrote:
> 
>> So saying that the people who don't know guile or guix need to first
>> contribute docs is pretty ridiculous.
> 
> Why?  Could you explain more why it appears to you “ridiculous”?
> 

My frustration seems to be that a lot of negative energy has been 
directed towards Emacs.
It has almost been straying towards anti elitist type discourse (that 
one is observing more increasingly in politics) -
*rather* than doOcracy style discourse that there is a problem and 
people are capable of autonomously resolving these things.

Emacs has not done something wrong here - it has merely had people who 
have had the capacity for exploration and reaching certain goals and 
insights then documenting their techniques within the Guix 
documentation.

It seems strange that people havent sooner expressed the concept of:
'well, I have this setup in /this/ editor, Ill put it up. Anybody else 
want to contribute and fill out gaps X Y and Z?'

It is worth noting that there has been a thread fork, starting this this 
subject title which is behaving more maturely and proactively:
RFC: add more setups to Guix docs

Similarly, there have been more sounds regarding Vim which are more 
proactive and constructive.

If people want a plurality of editors represented in the documentation 
they should be proactive about it, rather than lamenting and using 
divisive rhetoric.

> Cheers,
> simon

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: The e(macs)lephant in the room and the Guix Bang

[Ricardo Wurmus]

Nathan Dehnel <ncdehnel@gmail.com> writes:

> heard about guile-studio, but it doesn't appear to have a dark mode,
> and I imagine trying to add one would require a bunch of emacs-style
> screwing around with it.

M-x modus-themes-toggle RET

i.e. hold Alt, press x, then type “modus-themes-toggle” and hit the
return key.

We can add a little toggle button to Guile Studio that does this.

-- 
Ricardo

Re: The e(macs)lephant in the room and the Guix Bang

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Nathan Dehnel <ncdehnel@gmail.com> writes:
>
>> heard about guile-studio, but it doesn't appear to have a dark mode,
>> and I imagine trying to add one would require a bunch of emacs-style
>> screwing around with it.
>
> M-x modus-themes-toggle RET
>
> i.e. hold Alt, press x, then type “modus-themes-toggle” and hit the
> return key.
>
> We can add a little toggle button to Guile Studio that does this.

To affect the context menu and menu bar you’d also need to do set the
GTK_THEME variable when starting Guile Studio, e.g.

    GTK_THEME=Adwaita:dark guile-studio

I’ll try to change Guile Studio so that it will automatically pick the
dark or light variant of the theme dependent on system preferences, but
for now this is the workaround that should get you most of the way to a
dark theme.

-- 
Ricardo

Re: The e(macs)lephant in the room and the Guix Bang

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Nathan Dehnel <ncdehnel@gmail.com> writes:
>
>> heard about guile-studio, but it doesn't appear to have a dark mode,
>> and I imagine trying to add one would require a bunch of emacs-style
>> screwing around with it.
>
> M-x modus-themes-toggle RET
>
> i.e. hold Alt, press x, then type “modus-themes-toggle” and hit the
> return key.
>
> We can add a little toggle button to Guile Studio that does this.

Actually, I just noticed that Guile Studio already tells you how to do
this in the help pane that is displayed on startup:

    Toggle between dark and light mode with F5.

-- 
Ricardo

Re: The e(macs)lephant in the room and the Guix Bang

[Nathan Dehnel]

Oh, thank you, that's lovely.

On Sat, Sep 23, 2023 at 4:59 AM Ricardo Wurmus <rekado@elephly.net> wrote:
>
>
> Nathan Dehnel <ncdehnel@gmail.com> writes:
>
> > heard about guile-studio, but it doesn't appear to have a dark mode,
> > and I imagine trying to add one would require a bunch of emacs-style
> > screwing around with it.
>
> M-x modus-themes-toggle RET
>
> i.e. hold Alt, press x, then type “modus-themes-toggle” and hit the
> return key.
>
> We can add a little toggle button to Guile Studio that does this.
>
> --
> Ricardo

Re: The e(macs)lephant in the room and the Guix Bang

[Csepp]

Ricardo Wurmus <rekado@elephly.net> writes:

> Nathan Dehnel <ncdehnel@gmail.com> writes:
>
>> heard about guile-studio, but it doesn't appear to have a dark mode,
>> and I imagine trying to add one would require a bunch of emacs-style
>> screwing around with it.
>
> M-x modus-themes-toggle RET
>
> i.e. hold Alt, press x, then type “modus-themes-toggle” and hit the
> return key.
>
> We can add a little toggle button to Guile Studio that does this.

Kinda tangential, but could Emacs be made to just use the system (GTK)
theme?
(In general there are a looot of places where Emacs should just stop
doing its own thing and properly integrate with the system services and
settings.)

Re: The e(macs)lephant in the room and the Guix Bang

[Ricardo Wurmus]

Csepp <raingloom@riseup.net> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Nathan Dehnel <ncdehnel@gmail.com> writes:
>>
>>> heard about guile-studio, but it doesn't appear to have a dark mode,
>>> and I imagine trying to add one would require a bunch of emacs-style
>>> screwing around with it.
>>
>> M-x modus-themes-toggle RET
>>
>> i.e. hold Alt, press x, then type “modus-themes-toggle” and hit the
>> return key.
>>
>> We can add a little toggle button to Guile Studio that does this.
>
> Kinda tangential, but could Emacs be made to just use the system (GTK)
> theme?

Yes, that’s my plan, but I don’t have enough time this month to work on
it.  My notes:

+ when =dconf read /org/gnome/desktop/interface/color-scheme= returns
  ’prefer-dark’ enable dark mode by default.

+ use =xprop= to change the theme variant *after* the frame has been created; see
  https://gist.github.com/itoshkov/850c46746705e32e2039fb0112a75ec7
  
+ we may also need to set =GTK_THEME= to =Adwaita:dark= before actually
  launching Guile Studio.  Or rather the value at
  =/org/gnome/desktop/wm/preferences/theme= followed by =:dark=.  This
  can be done in shell wrapper.

-- 
Ricardo

Re: The e(macs)lephant in the room and the Guix Bang

[Christine Lemmer-Webber]

Nathan Dehnel <ncdehnel@gmail.com> writes:

> ________________________________
>
>> Hi, for some reason emacs has become the elephant in the room of the
>> discussion on contributing to guix.
>>
>> Regardless of one's opinion of emacs, I just want to add that this is
>> itself strange.  I have contributed some (package definition) patches
>> to guix, all without using emacs.
>>
>> I am not an emacs user, so emacs is not necessary for contributing to guix.
>> For what it's worth, the emacs-motif package in Guix was my addition.
>> I don't use it myself.
>
> I don't use emacs either (because it's so impenetrable), so I just use
> kate instead, which isn't a great environment for me either. It has
> rainbow parens, but it doesn't balance them, which is a hassle. I keep
> using it though due to lack of time to browse through alternatives. I
> heard about guile-studio, but it doesn't appear to have a dark mode,
> and I imagine trying to add one would require a bunch of emacs-style
> screwing around with it.
>
> https://archive.fosdem.org/2022/schedule/event/lispforeveryone/
> This is the only setup for coding in lisp that has actually looked
> attractive to me. (Coding in wisp with colored blocks that transpiles
> to s-expressions) Though I haven't had the time (and probably
> expertise) to set it up for myself.

Happy to see this talk get some attention.  It does advocate a variety
of possible approaches, one of them Wisp (and the wisp-mode colored
block stuff is pretty awesome).

If you like that approach and want to not have to do the
parenthesis-balancing as much yourself, there's an interesting overlap
between Wisp and parinfer, which automatically infers the parentheses
from whitespace but keeps them in the actual source.  I have personally
never tried using parinfer for serious tasks though.  It still requires
an editor set up for those features.

Since Spritely is also using Guile heavily, we have also spent a lot of
time talking about possible directions for helping non-emacs-users get
going with our tooling.  Personally I think the biggest path to success
is likely to be seeing Guile support (starting with parenthetical Guile)
also be very strong in mainstream editors.  A lot has changed in the
programming editor world recently: LSP looks like a very promising
direction for this.  (Anyway, there's no decisionmaking yet in terms of
what we're doing, it just has come up quite a bit.)

Has anyone tried using an LSP-like environment and seeing if they can
get something approximating the comfort that Guile and Geiser users in
emacs have, I wonder?  I have seen there are a couple of guile LSP
packages but I have not personally tried them.

 - Christine

Re: The e(macs)lephant in the room and the Guix Bang

[Nathan Dehnel]

Which packages are those? I' ve only seen scheme-lsp-server, which
isn't merged yet


On Wed, Sep 27, 2023 at 1:44 PM Christine Lemmer-Webber
<cwebber@dustycloud.org> wrote:
>
> Nathan Dehnel <ncdehnel@gmail.com> writes:
>
> > ________________________________
> >
> >> Hi, for some reason emacs has become the elephant in the room of the
> >> discussion on contributing to guix.
> >>
> >> Regardless of one's opinion of emacs, I just want to add that this is
> >> itself strange.  I have contributed some (package definition) patches
> >> to guix, all without using emacs.
> >>
> >> I am not an emacs user, so emacs is not necessary for contributing to guix.
> >> For what it's worth, the emacs-motif package in Guix was my addition.
> >> I don't use it myself.
> >
> > I don't use emacs either (because it's so impenetrable), so I just use
> > kate instead, which isn't a great environment for me either. It has
> > rainbow parens, but it doesn't balance them, which is a hassle. I keep
> > using it though due to lack of time to browse through alternatives. I
> > heard about guile-studio, but it doesn't appear to have a dark mode,
> > and I imagine trying to add one would require a bunch of emacs-style
> > screwing around with it.
> >
> > https://archive.fosdem.org/2022/schedule/event/lispforeveryone/
> > This is the only setup for coding in lisp that has actually looked
> > attractive to me. (Coding in wisp with colored blocks that transpiles
> > to s-expressions) Though I haven't had the time (and probably
> > expertise) to set it up for myself.
>
> Happy to see this talk get some attention.  It does advocate a variety
> of possible approaches, one of them Wisp (and the wisp-mode colored
> block stuff is pretty awesome).
>
> If you like that approach and want to not have to do the
> parenthesis-balancing as much yourself, there's an interesting overlap
> between Wisp and parinfer, which automatically infers the parentheses
> from whitespace but keeps them in the actual source.  I have personally
> never tried using parinfer for serious tasks though.  It still requires
> an editor set up for those features.
>
> Since Spritely is also using Guile heavily, we have also spent a lot of
> time talking about possible directions for helping non-emacs-users get
> going with our tooling.  Personally I think the biggest path to success
> is likely to be seeing Guile support (starting with parenthetical Guile)
> also be very strong in mainstream editors.  A lot has changed in the
> programming editor world recently: LSP looks like a very promising
> direction for this.  (Anyway, there's no decisionmaking yet in terms of
> what we're doing, it just has come up quite a bit.)
>
> Has anyone tried using an LSP-like environment and seeing if they can
> get something approximating the comfort that Guile and Geiser users in
> emacs have, I wonder?  I have seen there are a couple of guile LSP
> packages but I have not personally tried them.
>
>  - Christine

Re: The e(macs)lephant in the room and the Guix Bang

[Andy Tai]

Hi, for some reason emacs has become the elephant in the room of the
discussion on contributing to guix.

Regardless of one's opinion of emacs, I just want to add that this is
itself strange.  I have contributed some (package definition) patches
to guix, all without using emacs.

I am not an emacs user, so emacs is not necessary for contributing to guix.
For what it's worth, the emacs-motif package in Guix was my addition.
I don't use it myself.

Re: The e(macs)lephant in the room and the Guix Bang

[Ludovic Courtès]

Hi Andy,

Andy Tai <atai@atai.org> skribis:

> Regardless of one's opinion of emacs, I just want to add that this is
> itself strange.  I have contributed some (package definition) patches
> to guix, all without using emacs.
>
> I am not an emacs user, so emacs is not necessary for contributing to guix.
> For what it's worth, the emacs-motif package in Guix was my addition.
> I don't use it myself.

I agree.  It’s great that some of us are so passionate about Emacs (and
I’m certainly one of them), but I think we should make sure not to
spread the idea that one *has* to master Emacs to contribute to Guix.

Quite a few long-time contributors do not use Emacs; the tooling (‘guix
edit’, ‘guix refresh’, ‘guix style’) is also there to provide a good
experience whether or not one uses Emacs.

Ludo’.

How can we decrease the cognitive overhead for contributors?

[Katherine Cox-Buday]

Summary: for people who don't contribute to Guix a lot, each 
contribution has
very high cognitive overhead. Can we work to reduce that?

Hey all,

Contributing to Guix is currently pretty difficult for me. I'm a Mom with a
full-time job, and anything outside of my job that requires a lot of 
executive
functioning (e.g. lots of manual, detailed, steps) is very difficult for 
me to
get correct. That last part is what I wanted to discuss, because that's 
the part
that prevents me from contributing more than I do, and I think there are
probably others whom are impacted by this.

When I have some time to contribute, I usually stall out at the "submit 
this for
review" because of the amount of cognitive overhead required. I've written a
script for myself that tries to perform all the steps including running 
the git
command to submit the patch, and this has helped me, but that this is 
necessary
for me to do might be something that, if addressed, could help others.

Here are some examples of things that cause issues for me. This is not a 
list of
grievances; it's my way of attempting to demonstrate the "shape" of the 
issue:

     I signed up on Savannah with the intention of applying to be a 
committer.
     Savannah closed my account one or two days later due to inactivity.

     I can't ever seem to get the GNU style commit messages correct. I 
use the
     templates provided, but those don't cover all cases, and I've even 
gotten
     feedback in a review to change a message it created.

     I don't use the email-based patch workflow day-to-day, so this is 
another
     area where I spend a lot of time trying to make sure I'm doing things
     correctly.

     My script runs `guix style` and `guix lint`, but its suggestions aren't
     always correct. I suspect I've submitted some patches with nonsensical
     changes due to implicitly trusting these tools.

     Maybe 
https://lists.gnu.org/archive/html/guile-devel/2023-02/msg00030.html
     addresses this, but manually managing Guile imports is laborious. As a
     fledgling schemer, I often forget which imports I needed just for
     development.

I think I would summarize the core of these examples as:

     "At every step of the contribution process, I must manually check that
     multiple things are correct. With limited available executive 
functioning,
     and no automation, this is very difficult to do correctly, and an 
easy place
     for contributors to stop."

I think that if I were working on Guix more frequently, I would build 
habits I
didn't have to think about, and these wouldn't be the large issues they are
for me. But because of the nature of a project like Guix, we want 
contributions
from people of all kinds of backgrounds, not just people who have the 
privilege
to work on Guix a lot.

I have given a list of issues to a group of people who are presumably
analytical, and I think the natural inclination is to go point-by-point 
and make
arguments for/against. Instead of that[*], I invite you to address the more
abstract issue: (should/how do) we reduce friction for making contributions?

Here are some things I've considered:

* Contributing to Guix is not for you

     I would be really sad if someone ever said this, but I guess it's a
     possibility. Maybe someone like me just can't be a contributor to 
Guix until
     I have the bandwidth to manage all the details. I would 
preemptively argue
     that diversity of thought and experiences usually leads to better 
things.

* It's OK to make lots of mistakes

     The people who have reviewed my code have been generous both with 
their time
     and fixing my mistakes and then applying. Maybe this model is OK? I 
still
     feel guilty every time a reviewer has to correct an oversight I've 
made. I
     also want to become a committer, but I don't know how that would 
work if
     I'm regularly making mistakes. Obviously people would still be 
reviewing my
     commits, but presumably a committer should not regularly be making
     mistakes.

* We could support a managed web-based workflow

     I think this has been brought up a lot of times, and I don't have a 
clear
     idea of what's been said. But I think a lot of developers these 
days are
     more familiar with this style, and we could still maintain 
self-sovereignty
     if we hosted something.

* Encourage upstream communities like "Guix 'R Us" 
(https://sr.ht/~whereiseveryone/guixrus/)

     Maybe Guix proper continues as is and we foster various upstream 
communities
     that utilize different styles and batch their contributions?

What do you all think? Does this affect anyone else?

[*] But if you have workflow suggestions, I'm all ears!

--
Katherine

Re: How can we decrease the cognitive overhead for contributors?

[(]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>     I signed up on Savannah with the intention of applying to be a committer.
>     Savannah closed my account one or two days later due to inactivity.

That happened to me, too :|

>     I can't ever seem to get the GNU style commit messages correct. I use the
>     templates provided, but those don't cover all cases, and I've even gotten
>     feedback in a review to change a message it created.

You do get used to it, but the format is very... verbose, and personally
I think we should abandon it; the signal:noise ratio isn't good, and I
don't think the automatic generation of ChangeLog files is a great idea
anyway, since so many changes to Guix are so trivial.  I think we should
just use the news file more often instead.

>     My script runs `guix style` and `guix lint`, but its suggestions aren't
>     always correct. I suspect I've submitted some patches with nonsensical
>     changes due to implicitly trusting these tools.

Yes, I'd personally advise against the use of `guix style` for now.
`guix lint` is fine, though.

> * Contributing to Guix is not for you

I'd hope nobody says this!  It's definitely not true, and rather
defeatist.

> * It's OK to make lots of mistakes

Yes. :)

> * We could support a managed web-based workflow

The problem with this is that it would not be possible without changing
the git hosting entirely to something like Gitea.  I'm personally a fan
of the email-based workflow; what, specifically, is it that bothers you
about it?  If it's:

- Setting it up: Yes, this is annoying.  Sadly, our mighty oligarchal
  masters have taken it upon themselves to make it as annoying as
  possible to use email from anywhere but their web or mobile clients.
- Sending the emails: This isn't that bad once you get used to it;
  sadly most Git clients (magit sadly included) don't support send-email
  well or at all.  But on the command line, all you need to do is:

  # for a single commit
  $ git send-email --to=guix-patches@gnu.org -1 --base=master -a
  # for several commits
  $ git send-email --to=guix-patches@gnu.org -$N_COMMITS --base=master --cover-letter -a

  Or, if sending an amended series:
  $ git send-email --to=$BUG_NUM@debbugs.gnu.org -$N_COMMITS --base=master -a -v$VERSION

- Switching between branches: The best way to handle this is with
  subtrees; see `git subtree --help`.
- Applying patches: This is a bit annoying.  Most email clients won't
  let you set up commands to pipe mailboxes to, unlike aerc.  Perhaps we
  could have a `mumi apply` command to fetch a patch series from debbugs
  and apply it to the checkout.

  -- (

Re: How can we decrease the cognitive overhead for contributors?

[Katherine Cox-Buday]

On 8/24/23 12:33 AM, ( wrote:

>> * We could support a managed web-based workflow
> 
> The problem with this is that it would not be possible without changing
> the git hosting entirely to something like Gitea.  I'm personally a fan
> of the email-based workflow; what, specifically, is it that bothers you
> about it?  If it's:

I can envision some kind of upstream branch that's blessed and merged 
daily. The web crowd commits to that, the email crowd commits to main.

> - Setting it up: Yes, this is annoying.  Sadly, our mighty oligarchal
>    masters have taken it upon themselves to make it as annoying as
>    possible to use email from anywhere but their web or mobile clients.

This isn't it at all, but I agree with your comment. I'm fond of email, 
and it's distressing how centralized it's become.

> - Sending the emails: This isn't that bad once you get used to it;
>    sadly most Git clients (magit sadly included) don't support send-email
>    well or at all.  But on the command line, all you need to do is:
> 
>    # for a single commit
>    $ git send-email --to=guix-patches@gnu.org -1 --base=master -a
>    # for several commits
>    $ git send-email --to=guix-patches@gnu.org -$N_COMMITS --base=master --cover-letter -a
> 
>    Or, if sending an amended series:
>    $ git send-email --to=$BUG_NUM@debbugs.gnu.org -$N_COMMITS --base=master -a -v$VERSION

It's this. Having to:

1. Remember the flags and their values
2. Remember the email address (it might seem silly unless you have forms 
of dyslexia. is it guix-patches? or patches-guix? Wait, what was I doing?)
3. And then the whole deal with what to do with follow ups.

I feel like I know my way around git pretty well, but I struggle with 
how those concepts map onto sending emails.

I have only been able to surmount this by lifting these concepts through 
scripts into higher-order concepts with less cognitive overhead.

> - Switching between branches: The best way to handle this is with
>    subtrees; see `git subtree --help`.

Interesting! I use worktrees, but maybe subtrees are easier? I'll have 
to read up on this. Thank you!

> - Applying patches: This is a bit annoying.  Most email clients won't
>    let you set up commands to pipe mailboxes to, unlike aerc.  Perhaps we
>    could have a `mumi apply` command to fetch a patch series from debbugs
>    and apply it to the checkout.

I wrote some elisp to one-key apply patches from GNUS, but I guess my 
point is: not everyone can do that. How are we to expect more 
contributors if that, or something similar, is the barrier to entry?

--
Katherine

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi Katherine,

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> On 8/24/23 12:33 AM, ( wrote:
>
>>> * We could support a managed web-based workflow
>> The problem with this is that it would not be possible without
>> changing
>> the git hosting entirely to something like Gitea.  I'm personally a fan
>> of the email-based workflow; what, specifically, is it that bothers you
>> about it?  If it's:
>
> I can envision some kind of upstream branch that's blessed and merged
> daily. The web crowd commits to that, the email crowd commits to main.
>
>> - Setting it up: Yes, this is annoying.  Sadly, our mighty oligarchal
>>    masters have taken it upon themselves to make it as annoying as
>>    possible to use email from anywhere but their web or mobile clients.
>
> This isn't it at all, but I agree with your comment. I'm fond of
> email, and it's distressing how centralized it's become.
>
>> - Sending the emails: This isn't that bad once you get used to it;
>>    sadly most Git clients (magit sadly included) don't support send-email
>>    well or at all.  But on the command line, all you need to do is:
>>    # for a single commit
>>    $ git send-email --to=guix-patches@gnu.org -1 --base=master -a
>>    # for several commits
>>    $ git send-email --to=guix-patches@gnu.org -$N_COMMITS --base=master --cover-letter -a
>>    Or, if sending an amended series:
>>    $ git send-email --to=$BUG_NUM@debbugs.gnu.org -$N_COMMITS --base=master -a -v$VERSION
>
> It's this. Having to:
>
> 1. Remember the flags and their values
> 2. Remember the email address (it might seem silly unless you have
> forms of dyslexia. is it guix-patches? or patches-guix? Wait, what was
> I doing?)
> 3. And then the whole deal with what to do with follow ups.
>
> I feel like I know my way around git pretty well, but I struggle with
> how those concepts map onto sending emails.

Perhaps you'd like to invest 1 hour (30 minutes?) into learning to use
'patman'.  It allows attaching metadata to a feature branch by means of
Git message tags, e.g. the associated email address with 'Series-to:',
or the current revision with 'Series-version:', etc.  Then submitting
the series is a matter of invoking just 'patman', and following the
indications.

For more information, try: 'guix shell info-reader u-boot -- info
"(u-boot) Patman patch manager"'

> I have only been able to surmount this by lifting these concepts
> through scripts into higher-order concepts with less cognitive
> overhead.
>
>> - Switching between branches: The best way to handle this is with
>>    subtrees; see `git subtree --help`.
>
> Interesting! I use worktrees, but maybe subtrees are easier? I'll have
> to read up on this. Thank you!
>
>> - Applying patches: This is a bit annoying.  Most email clients won't
>>    let you set up commands to pipe mailboxes to, unlike aerc.  Perhaps we
>>    could have a `mumi apply` command to fetch a patch series from debbugs
>>    and apply it to the checkout.
>
> I wrote some elisp to one-key apply patches from GNUS, but I guess my
> point is: not everyone can do that. How are we to expect more
> contributors if that, or something similar, is the barrier to entry?

Using an Emacs-based workflow:

1. C-u M-x debbugs-gnu RET guix-patches RET [then answer prompts]
2. M-x cd RET ~/src/guix or wherever is your guix checkout
3. Select series you want to apply
4. Sort by subject
5. Press '|' (pipe) on any message, and pipe this to the command 'git am
-3'.  To apply multiple patches at once, you can specify an argument
prefix, e.g. 'C-u 10 |' to apply 10 patches at once.

I hope that helps someone.

-- 
Thanks,
Maxim

Re: How can we decrease the cognitive overhead for contributors?

[宋文武]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Perhaps you'd like to invest 1 hour (30 minutes?) into learning to use
> 'patman'.  It allows attaching metadata to a feature branch by means of
> Git message tags, e.g. the associated email address with 'Series-to:',
> or the current revision with 'Series-version:', etc.  Then submitting
> the series is a matter of invoking just 'patman', and following the
> indications.
>
> For more information, try: 'guix shell info-reader u-boot -- info
> "(u-boot) Patman patch manager"'

Oh, patman look interesting for long series, will learn it later..

>> I wrote some elisp to one-key apply patches from GNUS, but I guess my
>> point is: not everyone can do that. How are we to expect more
>> contributors if that, or something similar, is the barrier to entry?
>
> Using an Emacs-based workflow:
>
> 1. C-u M-x debbugs-gnu RET guix-patches RET [then answer prompts]
> 2. M-x cd RET ~/src/guix or wherever is your guix checkout
> 3. Select series you want to apply
> 4. Sort by subject

Also can first read on issues (mumi), find a issue ID,
then M-x gnus-read-ephemeral-emacs-bug-group ID.

> 5. Press '|' (pipe) on any message, and pipe this to the command 'git am
> -3'.  To apply multiple patches at once, you can specify an argument
> prefix, e.g. 'C-u 10 |' to apply 10 patches at once.
>
> I hope that helps someone.

Don't know the 'C-u 10 |' one, cool, thank you!

Re: How can we decrease the cognitive overhead for contributors?

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 5566 bytes --]

Hi,

interesting thread: thank you very much to all for the comments and
tips!

For email based patch workflow one and two things are indispensable: a
mailbox and a MUA capable of piping a message to a command (git am);
this is the one and only obstacle for contrubutors who are accustomed to
less than functional MUAs.

https://git-send-email.io/ is a good primer for the braves.

On the "cognitive overhead" for users like me who are able to (very)
seldom send some patch to projects, I find it much more straightforward
to just send a "git format-patch" generated file via email than to open
a web browser, log-in (or worst: register), fork... naah! 

On the general topic of "email vs. web (fork and PR) patch management" I
found this articles useful and interesting:

- «How I Learned to Love the Email Patch Developer Workflow» by Emily Shaffer
https://nasamuffin.github.io/git/open-source/email/code-review/2019/05/22/how-i-learned-to-love-email-patches.html

--8<---------------cut here---------------start------------->8---

With some tooling and good practices, I found a workflow that I love - and found myself arguing in defense of emailed patches!

[...]

* Responding to Comments

Note: As with Gerrit and other iterative code review tools based around a Git workflow, making your changes involves using interactive rebase. I won’t cover that here, as it’s not significantly different from other processes, and it’s complex enough to take its own tutorial.

--8<---------------cut here---------------end--------------->8---

- «Code review at the speed of email» by "Drew DeVault"
https://drewdevault.com/2022/07/25/Code-review-with-aerc.html

--8<---------------cut here---------------start------------->8---

With hundreds of hours of review experience on GitHub, GitLab, and SourceHut, I can say with confidence the email workflow allows me to work much faster than any of the others. I can review small patches in seconds, work quickly with multiple git repositories, easily test changes and make tweaks as necessary, rebase often, and quickly chop up and provide feedback for larger patches. Working my way through a 50-email patch queue usually takes me about 20 minutes, compared to an hour or more for the same number of merge requests.

This workflow also works entirely offline.

--8<---------------cut here---------------end--------------->8---

- «The advantages of an email-driven git workflow» by Drew DeVault
https://drewdevault.com/2018/07/02/Email-driven-git.html

--8<---------------cut here---------------start------------->8---

Email isn’t as sexy as GitHub (and its imitators), but it has several advantages over the latter. Email is standardized, federated, well-understood, and venerable. A very large body of email-related software exists and is equally reliable and well-understood. You can interact with email using only open source software and customize your workflow at every level of the stack - filtering, organizing, forwarding, replying, and so on; in any manner you choose.

[...] Given that most popular email clients these days are awful and can’t handle basic tasks like “sending email” properly, I strongly recommend this tool (git-send-email) over attempting to send format-patch’s output yourself.

[...] You can also set the default recipient for a given repository by using a local git config: git config sendemail.to admin@example.org. This lets you skip a step if you send your patches to a consistent destination for that project, like a mailing list. I also recommend git config --global sendemail.annotate yes, which will always open the emails in your editor to allow you to make changes (you can get this with --annotate if you don’t want it every time).

[...] The difficult part can be getting the email to git am in the first place. If you simply use the GMail web UI, this can be difficult.

[...] The main disadvantage of email driven development is that some people are more comfortable working with email in clients which are not well-suited to this kind of work. Popular email clients have caused terrible ideas like HTML email to proliferate, not only enabling spam, privacy leaks, and security vulnerabilities, but also making it more difficult for people to write emails that can be understood by git or tolerated by advanced email users.

I don’t think that the solution to these problems is to leave these powerful tools hanging in the wind and move to less powerful models like GitHub’s pull requests.

--8<---------------cut here---------------end--------------->8---

宋文武 <iyzsong@envs.net> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

>> For more information, try: 'guix shell info-reader u-boot -- info
>> "(u-boot) Patman patch manager"'
>
> Oh, patman look interesting for long series, will learn it later..

[...]

>> Using an Emacs-based workflow:
>>
>> 1. C-u M-x debbugs-gnu RET guix-patches RET [then answer prompts]
>> 2. M-x cd RET ~/src/guix or wherever is your guix checkout
>> 3. Select series you want to apply
>> 4. Sort by subject
>
> Also can first read on issues (mumi), find a issue ID,
> then M-x gnus-read-ephemeral-emacs-bug-group ID.

[...]

> Don't know the 'C-u 10 |' one, cool, thank you!

I feel like a section in the Cookbook about email based workflows would
be useful to many, even one with just excertps from this thread.

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: How can we decrease the cognitive overhead for contributors?

[Imran Iqbal]

On Mon, Aug 28, 2023 at 01:42:15PM +0200, Giovanni Biscuolo wrote:
> Hi,
>
> interesting thread: thank you very much to all for the comments and
> tips!

Seconded, this has been a great thread to read through.

> For email based patch workflow one and two things are indispensable: a
> mailbox and a MUA capable of piping a message to a command (git am);
> this is the one and only obstacle for contrubutors who are accustomed to
> less than functional MUAs.

I think this is the biggest hurdle. A lot of folks are using gmail and
its web based UI and it is just plain awful. I have made the switch to
using neomutt (and isync + notmuch + mstmp) and it has made emails a joy
to use and work with.

> On the "cognitive overhead" for users like me who are able to (very)
> seldom send some patch to projects, I find it much more straightforward
> to just send a "git format-patch" generated file via email than to open
> a web browser, log-in (or worst: register), fork... naah!

This also has the nice side effect of not having to worry about if you
should force push or not to maintain a clean commits the web ui, and in
general I find the email flow to promote better commit hygiene.

> On the general topic of "email vs. web (fork and PR) patch management" I
> found this articles useful and interesting:

One thing I would to this is Linus's rant on the github style workflow,
as seen in a hard to follow list style UI:
https://github.com/torvalds/linux/pull/17

Re: How can we decrease the cognitive overhead for contributors?

[Ekaitz Zarraga]

Hi,

> I think this is the biggest hurdle. A lot of folks are using gmail and
> its web based UI and it is just plain awful. I have made the switch to
> using neomutt (and isync + notmuch + mstmp) and it has made emails a joy
> to use and work with.

I use protonmail and they don't provide smtp access so I can't do git
send-mail as easy as other people do.

Protonmail has a bridge that deals with that but we don't have it packaged
because it's written in Go and it has TOO MANY dependencies.

This is not Guix's fault, but it's a problem Guix doesn't help fix either.
The only thing I can do with this is just copy-paste the result of git
format-patch and hope it's not a trouble for committers.

This doesn't mean I'm against the email based approach, in fact, I really
like it. The main problem I see is many people inside guix are not 
sensible to people's problems and tastes.

Some people are forced to use tools for several reasons, too.

This is what I mean when I say many times emacs is kind of mandatory, and
this thread is kind of a demonstration of what I meant because the main
discussion evolved to: you can use this or that in emacs to ease the dev
experience.

I don't think software we use is the main problem, but the fact that we
are not always sensible with other people's experience.

Cheers,
Ekaitz

Re: How can we decrease the cognitive overhead for contributors?

[indieterminacy]

On 03-09-2023 19:45, Ekaitz Zarraga wrote:
> Hi,
> 
>> I think this is the biggest hurdle. A lot of folks are using gmail and
>> its web based UI and it is just plain awful. I have made the switch to
>> using neomutt (and isync + notmuch + mstmp) and it has made emails a 
>> joy
>> to use and work with.
> 
> I use protonmail and they don't provide smtp access so I can't do git
> send-mail as easy as other people do.
> 
> Protonmail has a bridge that deals with that but we don't have it 
> packaged
> because it's written in Go and it has TOO MANY dependencies.
> 
> This is not Guix's fault, but it's a problem Guix doesn't help fix 
> either.
> The only thing I can do with this is just copy-paste the result of git
> format-patch and hope it's not a trouble for committers.
> 
> This doesn't mean I'm against the email based approach, in fact, I 
> really
> like it. The main problem I see is many people inside guix are not
> sensible to people's problems and tastes.
> 
> Some people are forced to use tools for several reasons, too.
> 
> This is what I mean when I say many times emacs is kind of mandatory, 
> and
> this thread is kind of a demonstration of what I meant because the main
> discussion evolved to: you can use this or that in emacs to ease the 
> dev
> experience.
> 

One of the benefits of my being able to attend Guix Days was seeing 
peoples' workflows and stacks in person.

As such, one of my conclusions having (already) committed to Guix was 
that I needed to master Emacs prior to Guile
(Im highly flow orientated).

> I don't think software we use is the main problem, but the fact that we
> are not always sensible with other people's experience.
> 
> Cheers,
> Ekaitz

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: How can we decrease the cognitive overhead for contributors?

[Ekaitz Zarraga]

> > This is what I mean when I say many times emacs is kind of mandatory,
> > and
> > this thread is kind of a demonstration of what I meant because the main
> > discussion evolved to: you can use this or that in emacs to ease the
> > dev
> > experience.
> 
> 
> One of the benefits of my being able to attend Guix Days was seeing
> peoples' workflows and stacks in person.
> 
> As such, one of my conclusions having (already) committed to Guix was
> that I needed to master Emacs prior to Guile
> (Im highly flow orientated).

But again, even if this is a great option for you, it might be a really bad
option for some other people. Everybody does not have the time to spend
learning emacs, or other specific tool. It's ok if the workflow suggests that
but it's not great if we have no other alternative.

It's not accessible and imposes a barrier in some people.

Re: How can we decrease the cognitive overhead for contributors?

[Fannys]

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

>> > This is what I mean when I say many times emacs is kind of mandatory,
>> > and
>> > this thread is kind of a demonstration of what I meant because the main
>> > discussion evolved to: you can use this or that in emacs to ease the
>> > dev
>> > experience.
>> 
>> 
>> One of the benefits of my being able to attend Guix Days was seeing
>> peoples' workflows and stacks in person.
>> 
>> As such, one of my conclusions having (already) committed to Guix was
>> that I needed to master Emacs prior to Guile
>> (Im highly flow orientated).
>
> But again, even if this is a great option for you, it might be a really bad
> option for some other people. Everybody does not have the time to spend
> learning emacs, or other specific tool. It's ok if the workflow suggests that
> but it's not great if we have no other alternative.
>
> It's not accessible and imposes a barrier in some people.

Yeah agreed. And we should be consious of that.
Ironically by mandating Emacs and Email we force people to use specific
tools while at the same time even though the same people will complain(!) against vendor lock-in
like github.

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi Fannys,

Fannys <email@fannys.me> writes:

> Ekaitz Zarraga <ekaitz@elenq.tech> writes:
>
>>> > This is what I mean when I say many times emacs is kind of mandatory,
>>> > and
>>> > this thread is kind of a demonstration of what I meant because the main
>>> > discussion evolved to: you can use this or that in emacs to ease the
>>> > dev
>>> > experience.
>>> 
>>> 
>>> One of the benefits of my being able to attend Guix Days was seeing
>>> peoples' workflows and stacks in person.
>>> 
>>> As such, one of my conclusions having (already) committed to Guix was
>>> that I needed to master Emacs prior to Guile
>>> (Im highly flow orientated).
>>
>> But again, even if this is a great option for you, it might be a really bad
>> option for some other people. Everybody does not have the time to spend
>> learning emacs, or other specific tool. It's ok if the workflow suggests that
>> but it's not great if we have no other alternative.
>>
>> It's not accessible and imposes a barrier in some people.
>
> Yeah agreed. And we should be consious of that.
> Ironically by mandating Emacs and Email we force people to use specific
> tools while at the same time even though the same people will complain(!) against vendor lock-in
> like github.

There's no lock-in.  You can use any tool you want.  Most people hacking
on Guix do so with Emacs and Geiser because these are currently the best
tools (that I know of) to do the job; these are the tools many of us
know and can easily recommend.  If Visual Code (or editor X) was
packaged in Guix and had great support for working with Guile, we could
also mention it in our manual or in the cookbook.

Notice I use recommend rather than mandate; these are just
recommendations that try to be helpful.  If it's not helpful to you, you
are free to select your own tool box and share how it works (via patches
to the contributing section or a blog post for example).

-- 
Thanks,
Maxim

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/13/23 18:42, Maxim Cournoyer wrote:
> Hi Fannys,
>
> Fannys <email@fannys.me> writes:
>
>> Ekaitz Zarraga <ekaitz@elenq.tech> writes:
>>
>>>>> This is what I mean when I say many times emacs is kind of mandatory,
>>>>> and
>>>>> this thread is kind of a demonstration of what I meant because the main
>>>>> discussion evolved to: you can use this or that in emacs to ease the
>>>>> dev
>>>>> experience.
>>>>
>>>> One of the benefits of my being able to attend Guix Days was seeing
>>>> peoples' workflows and stacks in person.
>>>>
>>>> As such, one of my conclusions having (already) committed to Guix was
>>>> that I needed to master Emacs prior to Guile
>>>> (Im highly flow orientated).
>>> But again, even if this is a great option for you, it might be a really bad
>>> option for some other people. Everybody does not have the time to spend
>>> learning emacs, or other specific tool. It's ok if the workflow suggests that
>>> but it's not great if we have no other alternative.
>>>
>>> It's not accessible and imposes a barrier in some people.
>> Yeah agreed. And we should be consious of that.
>> Ironically by mandating Emacs and Email we force people to use specific
>> tools while at the same time even though the same people will complain(!) against vendor lock-in
>> like github.
> There's no lock-in.  You can use any tool you want.  Most people hacking
> on Guix do so with Emacs and Geiser because these are currently the best
> tools (that I know of) to do the job; these are the tools many of us
> know and can easily recommend.  If Visual Code (or editor X) was
> packaged in Guix and had great support for working with Guile, we could
> also mention it in our manual or in the cookbook.
>
> Notice I use recommend rather than mandate; these are just
> recommendations that try to be helpful.  If it's not helpful to you, you
> are free to select your own tool box and share how it works (via patches
> to the contributing section or a blog post for example).
>
There are two problems here though. Let me elaborate:

1. The "recommendations": (This is just an example)

I am a new person wanting to get involved or just tweak my config in 
guix/guile.

I go to the manual to learn package management, 
https://guix.gnu.org/en/manual/devel/en/guix.html#Package-Management

Apparently i have to either use the terminal or something called emacs. 
If I follow the guide located here: 
https://emacs-guix.gitlab.io/website/manual/latest/emacs-guix.html#Installation

It says to install emacs-guix. Okay. So apparently it is an Emacs thing, 
whatever that means. And when you start Emacs after installing the 
package, you are going to end up with Emacs in its plain form. 
Unfamiliar keybindings, no autocomplete, etc. Well thats no to Emacs 
then. The other thing is the terminal apparently. Horrible, but at least 
it works.

So what if I want to mess around with guile and the guix config directly?

If we check here it says to use something called Emacs again. So Im 
guessing its the same Emacs that was also apparent in the previous step 
with the config. but not there are more tools.

2. The contribute yourself your tools.

My point with all this is not to say its your fault or really anybody 
specific. Its more to say that:

Recommendations in an abstract sense work fine. But not in the real 
world. You proposed:

 > If it's not helpful to you, you are free to select your own tool box 
and share how it works (via patches to the contributing section or a 
blog post for example). are free to select your own tool box and share 
how it works (via patches to the contributing section or a blog post for 
example).

How many people actually have the time and energy and know-how to do 
this? In the original email it was about a mother who on her spare time 
contributes to guix. Or as another example it could be about a person 
that just starts programming. Or it could be about a person that works 
and has few spare time.

Of course I saw in an email earlier in the thread that: "If you don't 
have time (as I do) then don't contribute." Which at the very least i 
find gross and not at all what guix is about.

Guix is supposed to be about equity. We are not all privileged (not 
saying you are or anybody else in this thread is.) enough to have the 
time and knowledge to learn Emacs, git-mail, find an email client that 
works (still havent found one. previous email was with the wrong email 
and threads are a nightmare.), and set up geiser and such.

The reason I have come to guix is because it strives to actually make it 
easier for people to change things. with guix shell and such. So making 
it easier for people to contribute is absolutely a part of it. Im not 
saying we should force every volunteer of course to do "work". What I am 
saying is:

- Guix recommendations in the manual, in the cookbook and other places, 
carry weight. In the sense that if to use something else than Emacs i 
have to write my own scripts or go to some random tutorial in a search 
engine then we have effectively pushed Emacs as the main guix platform. 
For better or worse. And we have excluded a portion of contributors. 
Same with email, debbugs. What can solve this is effort to actually 
include people.

Visual Code as you mentioned or any other editor, or mumi, these are all 
efforts to get contributors in the first place. The contributors will 
never come and create the infra and tooling they want by themselves. It 
takes some initial effort on our part to lower the barrier and 
"cognitive overhead" as in the title to actually encourage people to 
contribute. Same way that women or other minorities dont just "show up" 
to change the culture to make the welcome. they would rather go where 
they are already welcome.


Not to make this too long i strongly disagree that "Create your own 
toolbox" is a barrier we should have for new users. And recommendations 
carry weight because its what people see the community putting effort 
into and using.


Some proposals/good directions that we already have not to leave this 
with just complaining is:

- Improve guile studio and add it as a recommendation. With an improve 
UI and keybindings for it.

- Improve the docs of course.

- add more editors maybe(?) by ourselves.

This is for the starting to change guix/guile code that is. For people 
wanting to use code there is others. As there is for actually committing 
being discussed elsewhere for improvements.


Yes I want to help on all of them at some point :)


MSavoritias

Re: How can we decrease the cognitive overhead for contributors?

[Simon Tournier]

Hi,

On Sun, 17 Sep 2023 at 14:29, MSavoritias <email@msavoritias.me> wrote:

> The reason I have come to guix is because it strives to actually make it 
> easier for people to change things. with guix shell and such. So making 
> it easier for people to contribute is absolutely a part of it. Im not 
> saying we should force every volunteer of course to do "work". What I am 
> saying is:

Sorry if I misread you.  From my understanding you are mixing unrelated
things.  As I have tried to explain elsewhere in this thread, there is a
range of contributions.  Somehow, we can divide them in 4 categories:

0. Use Guix (and potentially report bugs :-))
1. Extend Guix for your own needs
2. Submit your modifications
3. Merge some modifications

Here, you start to speak about #0 and #1 and then you splice to #2.

I agree, it is a whole as the “free software” definition:

0. The freedom to run the program as you wish, for any purpose.
1. The freedom to change it so it does your computing as you wish.
2. The freedom to redistribute copies so you can help others.
3. The freedom to distribute copies of your modified versions to others.

However, to stay actionable, we need to keep in mind the 4 levels.  And
we need to recognize and identify for each level what is good, smooth,
easy and what is harder, unexpected or worse blocker.

Else, we are in some vacuum of abstract and we are locked in rants
without some engaging path forward.

That’s said, let me point that people are already engaging for improving
the accessibility of editors other than Emacs.  For instance, Vim [1] or
VSCode [2].  The frame is not “what we should do” but “let me show you
what I have”, IMHO.  Well, you are free to join the fun! :-)

1: https://10years.guix.gnu.org/video/using-vim-for-guix-development/
2: https://videos.univ-grenoble-alpes.fr/video/26660-cafe_guix_vscode_comme_outil_deditionmp4/

Cheers,
simon

The elephant in the room and the Guix Bang.

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 5514 bytes --]

Hello,

...I'm talking about Emacs.

In <87bkdzssgm.fsf@gmail.com> [1] Simon Tournier <zimon.toutoune@gmail.com> writes:

[1] https://yhetil.org/guix/87bkdzssgm.fsf@gmail.com/

[...]

> people are already engaging for improving the accessibility of editors
> other than Emacs

Simon gave me the opportunity to realize (once again) that IMO there is
a foundamental misconception regarding Emacs.

What is Emacs, exacly: is it an editor?

I feel that a great deal of friction on the matter is due to the fact
that Emacs is usually defined as an /editor/ (OK text editor, but it
makes no difference)... **also** in its official page:

--8<---------------cut here---------------start------------->8---

 An extensible, customizable, free/libre text editor — and more.
 
 At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
 programming language with extensions to support text editing.

--8<---------------cut here---------------end--------------->8---
(https://www.gnu.org/software/emacs/)

IMO to define Emacs as a sort of «text editor on steroids with batteries
included (Emacs Lisp)» does not represent the real nature of the
program; an /effective/ definition would be:

--8<---------------cut here---------------start------------->8---

 An extensible, customizable, free/libre user interface.
 
 At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
 programming language, with extensions to use it as an interface to text
 editing functions and many, many more: MUA, web browser, task
 organizer...

--8<---------------cut here---------------end--------------->8---

To define Emacs as a /user interface/ it's not just a cool way to
"market it", it means to classify its /unique/ (?) user interface design
as one among all the historical instances of user interfaces:

--8<---------------cut here---------------start------------->8---

1. batch interface
2. command line interface
3. SAA User Interface or Text-Based User Interface
4. graphical user interface
5. (editor note) web user interface

--8<---------------cut here---------------end--------------->8---
(https://en.wikipedia.org/wiki/User_interface#History)

Someone may consider Emacs "just" a "text-based user interface (UI)"
(point 3. of the above mentioned list) like the ones using curses and
alike (e.g. vim, mutt, ranger, Norton Commander and so on) but IMO Emacs
implements a very different design, centered around a specific UI
element called "emacs buffer".

I consider Emacs as a 6th class of user interface :-D

Just to bring my limited personal experience: I was a mutt+vim user for
email management, ranger for file management... and so on, and since I
was was **very** happy with my vim user experience when editing text,
for a very long time I looked at Emacs as "just" another text editor I
didn't need, because **as text editors** both vim, Emacs and alike are
/very/ powerful and I was never ever interested for just a sec to the
funny "editor war" (and similar "wars").

Then, one day, moved by curiosity and the fact that the Emacs interface
is /integrated/ in the notmuch mail indexer I was already using, I
started using Emacs as my preferred /user interface/ for notmuch... and
some year later here I am, trying to use the Emacs interface for as much
computing activities I can.

Now I see Emacs in a very different way.

Incidentally (?), AFAIU Emacs was the Guile IDE (integrated development
environment, not text editor) used by Ludovic when he started
programming Guix; he and probably some (many?) of the contributors was
so happy with their tool that they started sharing their configuration
snippets, as usual amoung a community of enthusiastic users... after
many refinements and maybe some Emacs extentions progamming, they was so
proud that they decided to recommend the same (set of) tool /and/
configuration to other _collegues_, the famous "perfect setup" described
in the Guix manual.

I'm also suspecting that the spark that started the "Guix Bang" in
Ludovic's mind, the very moment he realized nix could be better
_extended_ using Guile in place of it's DSL, was /caused/ by the fact he
was a Lisp programmer, the specific /dialect/ probably did not matter.
But I'm just guessing.

Now I see Guix in a different way. :-)

In this context: is the Guix project biased in recommending using Emacs
(a Lisp interpreter and compiler for Emacs Lisp) to contributors?  I
don't think so.

I'd rather say that - as in many other organizations and all similar
projects - Guix adopts a "BYOT" (bring your own tool) organizational
policy... and the first contributors brought theirs. :-D

For sure vim/neovim - and other tools - can also be extended and *used*
to provide /user interface/s for various external tools (e.g. see
fugitive.vim/nvim-fugitive) that are useful when using and/or developing
Guix, everyone is free to use and extend them, and also to share with
the whole Guix community how their beloved BYOT are working well.

Please see a recent message of mine (id:87pm2e4flj.fsf@xelera.eu [2])
for some of my comments (nothing really new, I just reused concept
already expressed by others) about the process needed to integrate
useful informations (configuration _is_ information) in Guix
official _recommandations_.

Happy hacking! Gio'

[2] https://yhetil.org/guix/87pm2e4flj.fsf@xelera.eu/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: The elephant in the room and the Guix Bang.

[Csepp]

Giovanni Biscuolo <g@xelera.eu> writes:

> [[PGP Signed Part:Undecided]]
> Hello,
>
> ...I'm talking about Emacs.
>
> In <87bkdzssgm.fsf@gmail.com> [1] Simon Tournier <zimon.toutoune@gmail.com> writes:
>
> [1] https://yhetil.org/guix/87bkdzssgm.fsf@gmail.com/
>
> [...]
>
>> people are already engaging for improving the accessibility of editors
>> other than Emacs
>
> Simon gave me the opportunity to realize (once again) that IMO there is
> a foundamental misconception regarding Emacs.
>
> What is Emacs, exacly: is it an editor?
>
> I feel that a great deal of friction on the matter is due to the fact
> that Emacs is usually defined as an /editor/ (OK text editor, but it
> makes no difference)... **also** in its official page:
>
>
>  An extensible, customizable, free/libre text editor — and more.
>  
>  At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
>  programming language with extensions to support text editing.
>
> (https://www.gnu.org/software/emacs/)
>
> IMO to define Emacs as a sort of «text editor on steroids with batteries
> included (Emacs Lisp)» does not represent the real nature of the
> program; an /effective/ definition would be:
>
>
>  An extensible, customizable, free/libre user interface.
>  
>  At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
>  programming language, with extensions to use it as an interface to text
>  editing functions and many, many more: MUA, web browser, task
>  organizer...
>
>
> To define Emacs as a /user interface/ it's not just a cool way to
> "market it", it means to classify its /unique/ (?) user interface design
> as one among all the historical instances of user interfaces:
>
>
> 1. batch interface
> 2. command line interface
> 3. SAA User Interface or Text-Based User Interface
> 4. graphical user interface
> 5. (editor note) web user interface
>
> (https://en.wikipedia.org/wiki/User_interface#History)
>
> Someone may consider Emacs "just" a "text-based user interface (UI)"
> (point 3. of the above mentioned list) like the ones using curses and
> alike (e.g. vim, mutt, ranger, Norton Commander and so on) but IMO Emacs
> implements a very different design, centered around a specific UI
> element called "emacs buffer".
>
> I consider Emacs as a 6th class of user interface :-D
>
> Just to bring my limited personal experience: I was a mutt+vim user for
> email management, ranger for file management... and so on, and since I
> was was **very** happy with my vim user experience when editing text,
> for a very long time I looked at Emacs as "just" another text editor I
> didn't need, because **as text editors** both vim, Emacs and alike are
> /very/ powerful and I was never ever interested for just a sec to the
> funny "editor war" (and similar "wars").
>
> Then, one day, moved by curiosity and the fact that the Emacs interface
> is /integrated/ in the notmuch mail indexer I was already using, I
> started using Emacs as my preferred /user interface/ for notmuch... and
> some year later here I am, trying to use the Emacs interface for as much
> computing activities I can.
>
> Now I see Emacs in a very different way.
>
> Incidentally (?), AFAIU Emacs was the Guile IDE (integrated development
> environment, not text editor) used by Ludovic when he started
> programming Guix; he and probably some (many?) of the contributors was
> so happy with their tool that they started sharing their configuration
> snippets, as usual amoung a community of enthusiastic users... after
> many refinements and maybe some Emacs extentions progamming, they was so
> proud that they decided to recommend the same (set of) tool /and/
> configuration to other _collegues_, the famous "perfect setup" described
> in the Guix manual.
>
> I'm also suspecting that the spark that started the "Guix Bang" in
> Ludovic's mind, the very moment he realized nix could be better
> _extended_ using Guile in place of it's DSL, was /caused/ by the fact he
> was a Lisp programmer, the specific /dialect/ probably did not matter.
> But I'm just guessing.
>
> Now I see Guix in a different way. :-)
>
> In this context: is the Guix project biased in recommending using Emacs
> (a Lisp interpreter and compiler for Emacs Lisp) to contributors?  I
> don't think so.
>
> I'd rather say that - as in many other organizations and all similar
> projects - Guix adopts a "BYOT" (bring your own tool) organizational
> policy... and the first contributors brought theirs. :-D
>
> For sure vim/neovim - and other tools - can also be extended and *used*
> to provide /user interface/s for various external tools (e.g. see
> fugitive.vim/nvim-fugitive) that are useful when using and/or developing
> Guix, everyone is free to use and extend them, and also to share with
> the whole Guix community how their beloved BYOT are working well.
>
> Please see a recent message of mine (id:87pm2e4flj.fsf@xelera.eu [2])
> for some of my comments (nothing really new, I just reused concept
> already expressed by others) about the process needed to integrate
> useful informations (configuration _is_ information) in Guix
> official _recommandations_.
>
> Happy hacking! Gio'
>
> [2] https://yhetil.org/guix/87pm2e4flj.fsf@xelera.eu/

Recommending Emacs would IMHO be fine, iff the UX wasn't so bad.  It's
better if we have at least one *well documented* developer setup, than
if we have a bunch of (sometimes conflicting) partial docs for setting
up certain subsystems.
Emacs can be pretty good, once you do (setq make-defaults-not-suck 1) a
bunch of times.

Re: The e(macs)lephant in the room and the Guix Bang

[Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.]

On 2023-09-20 at 10:21+02:00, Csepp wrote:
> It's better if we have at least one *well documented* developer setup,
> than if we have a bunch of (sometimes conflicting) partial docs
> for setting up certain subsystems.
>
> Emacs can be pretty good, once you do (setq make-defaults-not-suck 1)
> a bunch of times.

Or even more outrageous, an overriden Emacs package
with all the good stuff for Guix development.
We already have guix shell that spawns a shell
and guix edit that spawns an editor, why no guix boot
that spawns an OS^W^W Emacs with appropriate defaults?

Disclaimer: I use the devil editor that goes by the number
of VI VI VI, so take this suggestion with a grain of salt.

Re: The e(macs)lephant in the room and the Guix Bang

[MSavoritias]

On 9/20/23 11:45, Nguyễn Gia Phong via Development of GNU Guix and the 
GNU System distribution. wrote:
> On 2023-09-20 at 10:21+02:00, Csepp wrote:
>> It's better if we have at least one *well documented* developer setup,
>> than if we have a bunch of (sometimes conflicting) partial docs
>> for setting up certain subsystems.
>>
>> Emacs can be pretty good, once you do (setq make-defaults-not-suck 1)
>> a bunch of times.
> Or even more outrageous, an overriden Emacs package
> with all the good stuff for Guix development.
> We already have guix shell that spawns a shell
> and guix edit that spawns an editor, why no guix boot
> that spawns an OS^W^W Emacs with appropriate defaults?
>
> Disclaimer: I use the devil editor that goes by the number
> of VI VI VI, so take this suggestion with a grain of salt.
>

Can't the guile editor be that?

It kind of tries to be already. We just need to promote it and dogfood 
it more.


MSavoritias

Re: The e(macs)lephant in the room and the Guix Bang

[Ricardo Wurmus]

MSavoritias <email@msavoritias.me> writes:

> On 9/20/23 11:45, Nguyễn Gia Phong via Development of GNU Guix and the
> GNU System distribution. wrote:
>> On 2023-09-20 at 10:21+02:00, Csepp wrote:
>>> It's better if we have at least one *well documented* developer setup,
>>> than if we have a bunch of (sometimes conflicting) partial docs
>>> for setting up certain subsystems.
>>>
>>> Emacs can be pretty good, once you do (setq make-defaults-not-suck 1)
>>> a bunch of times.
>> Or even more outrageous, an overriden Emacs package
>> with all the good stuff for Guix development.
>> We already have guix shell that spawns a shell
>> and guix edit that spawns an editor, why no guix boot
>> that spawns an OS^W^W Emacs with appropriate defaults?
>>
>> Disclaimer: I use the devil editor that goes by the number
>> of VI VI VI, so take this suggestion with a grain of salt.
>>
>
> Can't the guile editor be that?
>
> It kind of tries to be already. We just need to promote it and dogfood
> it more.

Do you mean Guile Studio?[1]

It was really only intended to be a pre-configured editor for new
Guilers, which is why it includes the picture language and Geiser with
picture display.

But as I wrote there

   There are many more things that can be done to make Emacs less
   confusing for people who use it just as a Guile IDE. I would be happy
   to hear your suggestions or apply patches to improve Guile Studio!

This is still true today.

[1]: https://elephly.net/guile-studio/

-- 
Ricardo

Re: The e(macs)lephant in the room and the Guix Bang

[MSavoritias]

On 9/20/23 17:03, Ricardo Wurmus wrote:
> MSavoritias <email@msavoritias.me> writes:
>
>> On 9/20/23 11:45, Nguyễn Gia Phong via Development of GNU Guix and the
>> GNU System distribution. wrote:
>>> On 2023-09-20 at 10:21+02:00, Csepp wrote:
>>>> It's better if we have at least one *well documented* developer setup,
>>>> than if we have a bunch of (sometimes conflicting) partial docs
>>>> for setting up certain subsystems.
>>>>
>>>> Emacs can be pretty good, once you do (setq make-defaults-not-suck 1)
>>>> a bunch of times.
>>> Or even more outrageous, an overriden Emacs package
>>> with all the good stuff for Guix development.
>>> We already have guix shell that spawns a shell
>>> and guix edit that spawns an editor, why no guix boot
>>> that spawns an OS^W^W Emacs with appropriate defaults?
>>>
>>> Disclaimer: I use the devil editor that goes by the number
>>> of VI VI VI, so take this suggestion with a grain of salt.
>>>
>> Can't the guile editor be that?
>>
>> It kind of tries to be already. We just need to promote it and dogfood
>> it more.
> Do you mean Guile Studio?[1]
>
> It was really only intended to be a pre-configured editor for new
> Guilers, which is why it includes the picture language and Geiser with
> picture display.
>
> But as I wrote there
>
>     There are many more things that can be done to make Emacs less
>     confusing for people who use it just as a Guile IDE. I would be happy
>     to hear your suggestions or apply patches to improve Guile Studio!
>
> This is still true today.
>
> [1]: https://elephly.net/guile-studio/
>
I did yeah. That's why i said we should promote it more to newcomers 
instead of plain Emacs.

I think guile and guix are close that it could easily be a guix-IDE too.


MSavoritias