Guile & Emacs chat at emacs hackathon/bug-crush SF

Guile & Emacs chat at emacs hackathon/bug-crush SF

[Christopher Allan Webber]

Heya everyone,

I was at the Emacs hackathon / bug crushing event and I gave a couple
demos that were Guile related, one showing off guile-emacs, and one
showing off Guix's Emacs integration.  So the good news is: the talk
went super, super well (on both, but especially guile-emacs), and
enthusiasm was high!  When I showed guile-emacs live, there were some
amazed expressions to see oh hey... this is *really* working!

I also had a conversation with John Wiegley, current maintainer of
emacs, and he said several things:

 - He thinks it would be *great* to have Emacs running on Scheme, a
   clear win, assuming it's integrated and runs fast and works well.

 - However, Guile would have to be able to make a promise: once Emacs
   ran on top of Guile, Emacs would have to be able to have say over
   anything that could end up changing actual semantics in Emacs
   (mainly, anything that would break Emacs user's source code).

   (I think there's an easy answer to this: guile-emacs is already
   aiming for heavy backwards compatibility and should just preserve
   that at this level.)

 - If we could prove that performance was better in guile-emacs, that's
   an easy way to win enthusiasm.

 - A good goal to work towards: all of emacs' tests should pass using
   guile-emacs.

So that's all a ways off, but I'm feeling enthusiastic that it's
possible!

 - Chris

PS: I'd like to see bipt's elisp branch merged with master.  I might try
to help... I'm trying to learn enough to do so.  However I don't have a
lot of time, and especially not a lot of experience with compilers..

Re: Guile & Emacs chat at emacs hackathon/bug-crush SF

[Christopher Allan Webber]

So even better news: I've successfully rebased BT Templeton's wip elisp
branch on top of guile master... you can get it here:

  https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip

Maybe I should update the Guix package to make use of that?

What's needed to get elisp updates into Guile master?

[Christopher Allan Webber]

Christopher Allan Webber writes:

> So even better news: I've successfully rebased BT Templeton's wip elisp
> branch on top of guile master... you can get it here:
>
>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>
> Maybe I should update the Guix package to make use of that?

So I'd like to get this merged in before it bitrots too heavily.
It would be a shame to not get it in, after how far it's come!

Now that it's rebased and running on master, there are two issues I see
that would need to be addressed:

 - The most recent commit disables three tests (specific to elisp).
   They should probably be re-enabled, or at worst at least commented
   out with a warning rather than being switched to expect-fail as they
   are right now.

   I'd prefer re-enabling them with fixes; for now, commenting out with
   clear explaination still seems better than bitrot though.  (The other
   tests all do pass.)

 - The commits are not in ChangeLog style format and are fairly terse in
   their message.  I imagine it's a requirement to fix that.  This seems
   like the bigger challenge; if anyone but the original author were to
   do it, there would have to be some careful reading to figure out what
   the purpose of each commit and change meant.  That seems like some
   work.  I'm not sure I have the time for it... are there any
   volunteers?

Is there general agreement that if we can get these two things done,
that it would be worth merging this?

 - Chris

Re: What's needed to get elisp updates into Guile master?

[Mathieu Lirzin]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Christopher Allan Webber writes:
>
>> So even better news: I've successfully rebased BT Templeton's wip elisp
>> branch on top of guile master... you can get it here:
>>
>>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>>
>> Maybe I should update the Guix package to make use of that?
>
> So I'd like to get this merged in before it bitrots too heavily.
> It would be a shame to not get it in, after how far it's come!

Agreed.

> Now that it's rebased and running on master, there are two issues I see
> that would need to be addressed:
>
>  - The most recent commit disables three tests (specific to elisp).
>    They should probably be re-enabled, or at worst at least commented
>    out with a warning rather than being switched to expect-fail as they
>    are right now.
>
>    I'd prefer re-enabling them with fixes; for now, commenting out with
>    clear explaination still seems better than bitrot though.  (The other
>    tests all do pass.)

I don't understand why you would want to do that. 'expect-fail' is the
correct semantic for a test that should pass but is known to currently
fail, like in TDD.  Do I miss something?

>  - The commits are not in ChangeLog style format and are fairly terse in
>    their message.  I imagine it's a requirement to fix that.  This seems
>    like the bigger challenge; if anyone but the original author were to
>    do it, there would have to be some careful reading to figure out what
>    the purpose of each commit and change meant.  That seems like some
>    work.  I'm not sure I have the time for it... are there any
>    volunteers?

You should bring that on emacs-devel where most people seem to think
that a 'git commit -m "..."' with the actual diff is self explanatory.
:)

Indeed, it seems a tedious job to add those change logs since it
requires to understand the purpose of the commit.  The volunteer should
be familiar with Elisp in general and the limitations of
current/previous Guile implementation.

> Is there general agreement that if we can get these two things done,
> that it would be worth merging this?

I think it would be great.

-- 
Mathieu Lirzin

Re: What's needed to get elisp updates into Guile master?

[Christopher Allan Webber]

Mathieu Lirzin writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Christopher Allan Webber writes:
>>
>>> So even better news: I've successfully rebased BT Templeton's wip elisp
>>> branch on top of guile master... you can get it here:
>>>
>>>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>>>
>>> Maybe I should update the Guix package to make use of that?
>>
>> So I'd like to get this merged in before it bitrots too heavily.
>> It would be a shame to not get it in, after how far it's come!
>
> Agreed.
>
>> Now that it's rebased and running on master, there are two issues I see
>> that would need to be addressed:
>>
>>  - The most recent commit disables three tests (specific to elisp).
>>    They should probably be re-enabled, or at worst at least commented
>>    out with a warning rather than being switched to expect-fail as they
>>    are right now.
>>
>>    I'd prefer re-enabling them with fixes; for now, commenting out with
>>    clear explaination still seems better than bitrot though.  (The other
>>    tests all do pass.)
>
> I don't understand why you would want to do that. 'expect-fail' is the
> correct semantic for a test that should pass but is known to currently
> fail, like in TDD.  Do I miss something?

Ah, okay!  Now I understand.  So I think leaving these as-is is fine in
merging this.

>>  - The commits are not in ChangeLog style format and are fairly terse in
>>    their message.  I imagine it's a requirement to fix that.  This seems
>>    like the bigger challenge; if anyone but the original author were to
>>    do it, there would have to be some careful reading to figure out what
>>    the purpose of each commit and change meant.  That seems like some
>>    work.  I'm not sure I have the time for it... are there any
>>    volunteers?
>
> You should bring that on emacs-devel where most people seem to think
> that a 'git commit -m "..."' with the actual diff is self explanatory.
> :)

I'm afraid to.  The emacs list has had strong responses moving between
tremendous enthusiasm for the guile-emacs work to outright hostility.  I
think there are only a couple of hostile people, but they are vocal.
I'd prefer to have the next stage of things merged before I reach out
again.

But maybe I'm being irrational.  I could probably still ask for help.

> Indeed, it seems a tedious job to add those change logs since it
> requires to understand the purpose of the commit.  The volunteer should
> be familiar with Elisp in general and the limitations of
> current/previous Guile implementation.

Yeah it's tough.

>> Is there general agreement that if we can get these two things done,
>> that it would be worth merging this?
>
> I think it would be great.

Great!

Re: What's needed to get elisp updates into Guile master?

[Mathieu Lirzin]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Mathieu Lirzin writes:
>>
>> You should bring that on emacs-devel where most people seem to think
>> that a 'git commit -m "..."' with the actual diff is self explanatory.
>> :)
>
> I'm afraid to.  The emacs list has had strong responses moving between
> tremendous enthusiasm for the guile-emacs work to outright hostility.  I
> think there are only a couple of hostile people, but they are vocal.
> I'd prefer to have the next stage of things merged before I reach out
> again.
>
> But maybe I'm being irrational.  I could probably still ask for help.

I was implicitly referring to a current discussion on emacs-devel:

  https://lists.gnu.org/archive/html/emacs-devel/2016-03/msg00180.html

Sorry for not giving the context of my sarcasm at first.

Anyway, thanks for giving guile-emacs some love!  :)

--
Mathieu Lirzin

Re: What's needed to get elisp updates into Guile master?

[Christopher Allan Webber]

Mathieu Lirzin writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Mathieu Lirzin writes:
>>>
>>> You should bring that on emacs-devel where most people seem to think
>>> that a 'git commit -m "..."' with the actual diff is self explanatory.
>>> :)
>>
>> I'm afraid to.  The emacs list has had strong responses moving between
>> tremendous enthusiasm for the guile-emacs work to outright hostility.  I
>> think there are only a couple of hostile people, but they are vocal.
>> I'd prefer to have the next stage of things merged before I reach out
>> again.
>>
>> But maybe I'm being irrational.  I could probably still ask for help.
>
> I was implicitly referring to a current discussion on emacs-devel:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2016-03/msg00180.html
>
> Sorry for not giving the context of my sarcasm at first.
>
> Anyway, thanks for giving guile-emacs some love!  :)

I saw that conversation right after your email and I still didn't pick
up on it.  Heh!

Someone from #emacs might actually help though!  (I'm not going to name
them and put them on the spot.)

 - Chris

Re: What's needed to get elisp updates into Guile master?

[Taylan Ulrich Bayırlı/Kammer]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Mathieu Lirzin writes:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>
>>> Mathieu Lirzin writes:
>>>>
>>>> You should bring that on emacs-devel where most people seem to think
>>>> that a 'git commit -m "..."' with the actual diff is self explanatory.
>>>> :)
>>>
>>> I'm afraid to.  The emacs list has had strong responses moving between
>>> tremendous enthusiasm for the guile-emacs work to outright hostility.  I
>>> think there are only a couple of hostile people, but they are vocal.
>>> I'd prefer to have the next stage of things merged before I reach out
>>> again.
>>>
>>> But maybe I'm being irrational.  I could probably still ask for help.
>>
>> I was implicitly referring to a current discussion on emacs-devel:
>>
>>   https://lists.gnu.org/archive/html/emacs-devel/2016-03/msg00180.html
>>
>> Sorry for not giving the context of my sarcasm at first.
>>
>> Anyway, thanks for giving guile-emacs some love!  :)
>
> I saw that conversation right after your email and I still didn't pick
> up on it.  Heh!
>
> Someone from #emacs might actually help though!  (I'm not going to name
> them and put them on the spot.)

Don't know if you mean me, but in any case I also have it in my mid-term
TODO to start working on guile-emacs.  Life-Status report:

Expect a few more months of "downtime" on my side.  (Recreational
purposes, though I'm available for emergency situations like if 'guix
pull' stops working. :P) After that, I'll have a time-frame of maximally
one year during which I'll be free from occupational work, in which time
I have to juggle my time between looking into how to best go on with my
occupational life (the software industry is awful and I wish to be
politically active in some way but programming is my only skill), and
working on various software projects including Guix contributions, Guile
contributions, RnRS/SRFI contributions, and Guile-Emacs.

The Guix and Guile contributions I have on my TODO aren't very big so
hopefully Guile-Emacs can get a good amount of time allocated to it.
OTOH, it will need a ton of tedious learning on my side if I have to
work on nontrivial C code, and especially the BDW-GC.  All in all don't
set your expectations too high please.  If more experienced hackers can
work on Guile-Emacs, that would be ideal.

>  - Chris

Taylan

Re: What's needed to get elisp updates into Guile master?

[Christopher Allan Webber]

Taylan Ulrich Bayırlı/Kammer writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Mathieu Lirzin writes:
>>
>>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>>
>>>> Mathieu Lirzin writes:
>>>>>
>>>>> You should bring that on emacs-devel where most people seem to think
>>>>> that a 'git commit -m "..."' with the actual diff is self explanatory.
>>>>> :)
>>>>
>>>> I'm afraid to.  The emacs list has had strong responses moving between
>>>> tremendous enthusiasm for the guile-emacs work to outright hostility.  I
>>>> think there are only a couple of hostile people, but they are vocal.
>>>> I'd prefer to have the next stage of things merged before I reach out
>>>> again.
>>>>
>>>> But maybe I'm being irrational.  I could probably still ask for help.
>>>
>>> I was implicitly referring to a current discussion on emacs-devel:
>>>
>>>   https://lists.gnu.org/archive/html/emacs-devel/2016-03/msg00180.html
>>>
>>> Sorry for not giving the context of my sarcasm at first.
>>>
>>> Anyway, thanks for giving guile-emacs some love!  :)
>>
>> I saw that conversation right after your email and I still didn't pick
>> up on it.  Heh!
>>
>> Someone from #emacs might actually help though!  (I'm not going to name
>> them and put them on the spot.)
>
> Don't know if you mean me, but in any case I also have it in my mid-term
> TODO to start working on guile-emacs.  Life-Status report:

Great!  I didn't mean you, so maybe we have overlap.  Really, whoever
steps up to do it, great!

> Expect a few more months of "downtime" on my side.  (Recreational
> purposes, though I'm available for emergency situations like if 'guix
> pull' stops working. :P) After that, I'll have a time-frame of maximally
> one year during which I'll be free from occupational work, in which time
> I have to juggle my time between looking into how to best go on with my
> occupational life (the software industry is awful and I wish to be
> politically active in some way but programming is my only skill), and
> working on various software projects including Guix contributions, Guile
> contributions, RnRS/SRFI contributions, and Guile-Emacs.
>
> The Guix and Guile contributions I have on my TODO aren't very big so
> hopefully Guile-Emacs can get a good amount of time allocated to it.
> OTOH, it will need a ton of tedious learning on my side if I have to
> work on nontrivial C code, and especially the BDW-GC.  All in all don't
> set your expectations too high please.  If more experienced hackers can
> work on Guile-Emacs, that would be ideal.

Great!  guile-emacs could definitely use the help.  Thanks for your
interest, and if you do have time, your time! :)

 - Chris

Elisp branch ready for merge (??)

[Christopher Allan Webber]

Well, I didn't think I'd have time to do this (and in a sense I didn't)
but:
  https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip

I've rebased the whole branch against git master and added ChangeLog
style entries.  "make check" is passing.  It seems to me that it's ready
for merge.  I did the best I could on the ChangeLog additions, both with
my limited ChangeLog experience and from my limited Guile internals
experience.  So, corrections welcome, but otherwise...

I think we really should not delay on this, and we should try to merge
this as soon as possible.  This already has bitrotted before, and if we
wait on it, it could bitrot again.  It would be great to get this pulled
into Guile proper.

Plus it would be a nice bullet point in the next release! :)

 - Chris

Re: Elisp branch ready for merge (??)

[Taylan Ulrich Bayırlı/Kammer]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Well, I didn't think I'd have time to do this (and in a sense I didn't)
> but:
>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>
> I've rebased the whole branch against git master and added ChangeLog
> style entries.  "make check" is passing.  It seems to me that it's ready
> for merge.  I did the best I could on the ChangeLog additions, both with
> my limited ChangeLog experience and from my limited Guile internals
> experience.  So, corrections welcome, but otherwise...

Exciting!

Small remark: the "title" line of the commit messages should be complete
sentences.

> I think we really should not delay on this, and we should try to merge
> this as soon as possible.  This already has bitrotted before, and if we
> wait on it, it could bitrot again.  It would be great to get this pulled
> into Guile proper.
>
> Plus it would be a nice bullet point in the next release! :)

+1

Would also be good that one doesn't need to keep two versions of Guile
around when hacking on Guile-Emacs.

>  - Chris

Taylan

Re: Elisp branch ready for merge (??)

[Mathieu Lirzin]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Well, I didn't think I'd have time to do this (and in a sense I didn't)
> but:
>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>
> I've rebased the whole branch against git master and added ChangeLog
> style entries.  "make check" is passing.  It seems to me that it's ready
> for merge.  I did the best I could on the ChangeLog additions, both with
> my limited ChangeLog experience and from my limited Guile internals
> experience.  So, corrections welcome, but otherwise...

Nice!

Small nitpick.  Could you remove the extra spaces at the start of
indented lines?  :)

I know this practice is/was a common practice in Guile but even if it
looks prettier with indentation, this is not the proper change log
format described by GCS and recognized by 'change-log-mode' in Emacs.

-- 

Mathieu Lirzin

Re: Elisp branch ready for merge (??)

[Christopher Allan Webber]

Mathieu Lirzin writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Well, I didn't think I'd have time to do this (and in a sense I didn't)
>> but:
>>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>>
>> I've rebased the whole branch against git master and added ChangeLog
>> style entries.  "make check" is passing.  It seems to me that it's ready
>> for merge.  I did the best I could on the ChangeLog additions, both with
>> my limited ChangeLog experience and from my limited Guile internals
>> experience.  So, corrections welcome, but otherwise...
>
> Nice!
>
> Small nitpick.  Could you remove the extra spaces at the start of
> indented lines?  :)
>
> I know this practice is/was a common practice in Guile but even if it
> looks prettier with indentation, this is not the proper change log
> format described by GCS and recognized by 'change-log-mode' in Emacs.

I could... but I'm hesitant to do so if it's not the standard ways to do
things in Guile's repository.  I'll leave that question to whoever is
interested in merging it.  If they'd like me to change it, I'll do it,
and since they have commit access, I consider them the authority.

Re: Elisp branch ready for merge (??)

[Christopher Allan Webber]

Taylan Ulrich Bayırlı/Kammer writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Well, I didn't think I'd have time to do this (and in a sense I didn't)
>> but:
>>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>>
>> I've rebased the whole branch against git master and added ChangeLog
>> style entries.  "make check" is passing.  It seems to me that it's ready
>> for merge.  I did the best I could on the ChangeLog additions, both with
>> my limited ChangeLog experience and from my limited Guile internals
>> experience.  So, corrections welcome, but otherwise...
>
> Exciting!
>
> Small remark: the "title" line of the commit messages should be complete
> sentences.

Yes, though I didn't write them.  I also don't know in each case what a
complete sentence would be.  I did my best job by filling in the
ChangeLog style part.  Often times my figuring out the ChangeLog stuff
was based on some sentence fragment.

Changing the one part that is the original author's writing to something
different... I can do it by attempting to guess, but I'm worried about
removing that context.

One thing I could do is leave in the description: "Original title: foo"

What do you think of that?

>> I think we really should not delay on this, and we should try to merge
>> this as soon as possible.  This already has bitrotted before, and if we
>> wait on it, it could bitrot again.  It would be great to get this pulled
>> into Guile proper.
>>
>> Plus it would be a nice bullet point in the next release! :)
>
> +1
>
> Would also be good that one doesn't need to keep two versions of Guile
> around when hacking on Guile-Emacs.

I agree! :)

Re: Elisp branch ready for merge (??)

[Mathieu Lirzin]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Mathieu Lirzin writes:
>
[...]
>> Small nitpick.  Could you remove the extra spaces at the start of
>> indented lines?  :)
>>
>> I know this practice is/was a common practice in Guile but even if it
>> looks prettier with indentation, this is not the proper change log
>> format described by GCS and recognized by 'change-log-mode' in Emacs.
>
> I could... but I'm hesitant to do so if it's not the standard ways to do
> things in Guile's repository.  I'll leave that question to whoever is
> interested in merging it.  If they'd like me to change it, I'll do it,
> and since they have commit access, I consider them the authority.

Sure, it will be an opportunity to discuss this major issue!  ;)

-- 
Mathieu Lirzin

Re: Elisp branch ready for merge (??)

[Taylan Ulrich Bayırlı/Kammer]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Taylan Ulrich Bayırlı/Kammer writes:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>
>>> Well, I didn't think I'd have time to do this (and in a sense I didn't)
>>> but:
>>>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>>>
>>> I've rebased the whole branch against git master and added ChangeLog
>>> style entries.  "make check" is passing.  It seems to me that it's ready
>>> for merge.  I did the best I could on the ChangeLog additions, both with
>>> my limited ChangeLog experience and from my limited Guile internals
>>> experience.  So, corrections welcome, but otherwise...
>>
>> Exciting!
>>
>> Small remark: the "title" line of the commit messages should be complete
>> sentences.
>
> Yes, though I didn't write them.  I also don't know in each case what a
> complete sentence would be.  I did my best job by filling in the
> ChangeLog style part.  Often times my figuring out the ChangeLog stuff
> was based on some sentence fragment.
>
> Changing the one part that is the original author's writing to something
> different... I can do it by attempting to guess, but I'm worried about
> removing that context.
>
> One thing I could do is leave in the description: "Original title: foo"
>
> What do you think of that?

In some cases it seems the title is already a sentence, just lacking
capitalization and punctuation.  (It seems Guile doesn't have a strict
rule about the punctuation though.)

In other cases it seems like titles that should be "Add foobar" are
shortened to just "foobar", e.g.:

- guile-backtrace function
- eval-when
- fset macro
- defsubst
- compiler macros
- elisp @@ macro

All in all it looks like most titles should be straightforward to fix.
Fixing any would be better than fixing none IMO.  And I'd say mentioning
the original title is unnecessary for the obvious ones, though we should
get Robin's sanctioning for what we do.  Is Robin perhaps available for
some basic feedback?

Taylan

Re: Elisp branch ready for merge (??)

[Christopher Allan Webber]

Taylan Ulrich Bayırlı/Kammer writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Taylan Ulrich Bayırlı/Kammer writes:
>>
>>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>>
>>>> Well, I didn't think I'd have time to do this (and in a sense I didn't)
>>>> but:
>>>>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>>>>
>>>> I've rebased the whole branch against git master and added ChangeLog
>>>> style entries.  "make check" is passing.  It seems to me that it's ready
>>>> for merge.  I did the best I could on the ChangeLog additions, both with
>>>> my limited ChangeLog experience and from my limited Guile internals
>>>> experience.  So, corrections welcome, but otherwise...
>>>
>>> Exciting!
>>>
>>> Small remark: the "title" line of the commit messages should be complete
>>> sentences.
>>
>> Yes, though I didn't write them.  I also don't know in each case what a
>> complete sentence would be.  I did my best job by filling in the
>> ChangeLog style part.  Often times my figuring out the ChangeLog stuff
>> was based on some sentence fragment.
>>
>> Changing the one part that is the original author's writing to something
>> different... I can do it by attempting to guess, but I'm worried about
>> removing that context.
>>
>> One thing I could do is leave in the description: "Original title: foo"
>>
>> What do you think of that?
>
> In some cases it seems the title is already a sentence, just lacking
> capitalization and punctuation.  (It seems Guile doesn't have a strict
> rule about the punctuation though.)
>
> In other cases it seems like titles that should be "Add foobar" are
> shortened to just "foobar", e.g.:
>
> - guile-backtrace function
> - eval-when
> - fset macro
> - defsubst
> - compiler macros
> - elisp @@ macro
>
> All in all it looks like most titles should be straightforward to fix.
> Fixing any would be better than fixing none IMO.

You are probably right.

> And I'd say mentioning the original title is unnecessary for the
> obvious ones, though we should get Robin's sanctioning for what we do.
> Is Robin perhaps available for some basic feedback?

I haven't heard from them, but if they chose to reach out it would be of
course most welcome!

 - Chris

Re: Guile & Emacs chat at emacs hackathon/bug-crush SF

[Mikael Djurfeldt]

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

This is wonderful news! :-)

I've actually tried out guile-emacs recently. What would be wonderful to
have is some kind of simple "map" over what has been done so far (e.g. the
large-scale structure of the code and what the relationship between the
elisp and guile interpreter currently is). Maybe that exists and I didn't
find it?

Best regards,
Mikael D.

On Sun, Mar 6, 2016 at 9:32 AM, Christopher Allan Webber <
cwebber@dustycloud.org> wrote:

> Heya everyone,
>
> I was at the Emacs hackathon / bug crushing event and I gave a couple
> demos that were Guile related, one showing off guile-emacs, and one
> showing off Guix's Emacs integration.  So the good news is: the talk
> went super, super well (on both, but especially guile-emacs), and
> enthusiasm was high!  When I showed guile-emacs live, there were some
> amazed expressions to see oh hey... this is *really* working!
>
> I also had a conversation with John Wiegley, current maintainer of
> emacs, and he said several things:
>
>  - He thinks it would be *great* to have Emacs running on Scheme, a
>    clear win, assuming it's integrated and runs fast and works well.
>
>  - However, Guile would have to be able to make a promise: once Emacs
>    ran on top of Guile, Emacs would have to be able to have say over
>    anything that could end up changing actual semantics in Emacs
>    (mainly, anything that would break Emacs user's source code).
>
>    (I think there's an easy answer to this: guile-emacs is already
>    aiming for heavy backwards compatibility and should just preserve
>    that at this level.)
>
>  - If we could prove that performance was better in guile-emacs, that's
>    an easy way to win enthusiasm.
>
>  - A good goal to work towards: all of emacs' tests should pass using
>    guile-emacs.
>
> So that's all a ways off, but I'm feeling enthusiastic that it's
> possible!
>
>  - Chris
>
> PS: I'd like to see bipt's elisp branch merged with master.  I might try
> to help... I'm trying to learn enough to do so.  However I don't have a
> lot of time, and especially not a lot of experience with compilers..
>
>

[-- Attachment #2: Type: text/html, Size: 2684 bytes --]

Re: Guile & Emacs chat at emacs hackathon/bug-crush SF

[Stefan Husmann]

Mikael Djurfeldt writes:

> This is wonderful news! :-)
>
> I've actually tried out guile-emacs recently. What would be wonderful to
> have is some kind of simple "map" over what has been done so far (e.g. the
> large-scale structure of the code and what the relationship between the
> elisp and guile interpreter currently is). Maybe that exists and I didn't
> find it?
>
> Best regards,
> Mikael D.
>
> On Sun, Mar 6, 2016 at 9:32 AM, Christopher Allan Webber <
> cwebber@dustycloud.org> wrote:
>
>> Heya everyone,
>>
>> I was at the Emacs hackathon / bug crushing event and I gave a couple
>> demos that were Guile related, one showing off guile-emacs, and one
>> showing off Guix's Emacs integration.  So the good news is: the talk
>> went super, super well (on both, but especially guile-emacs), and
>> enthusiasm was high!  When I showed guile-emacs live, there were some
>> amazed expressions to see oh hey... this is *really* working!
>>
>> I also had a conversation with John Wiegley, current maintainer of
>> emacs, and he said several things:
>>
>>  - He thinks it would be *great* to have Emacs running on Scheme, a
>>    clear win, assuming it's integrated and runs fast and works well.
>>
>>  - However, Guile would have to be able to make a promise: once Emacs
>>    ran on top of Guile, Emacs would have to be able to have say over
>>    anything that could end up changing actual semantics in Emacs
>>    (mainly, anything that would break Emacs user's source code).
>>
>>    (I think there's an easy answer to this: guile-emacs is already
>>    aiming for heavy backwards compatibility and should just preserve
>>    that at this level.)
>>
>>  - If we could prove that performance was better in guile-emacs, that's
>>    an easy way to win enthusiasm.
>>
>>  - A good goal to work towards: all of emacs' tests should pass using
>>    guile-emacs.
>>
>> So that's all a ways off, but I'm feeling enthusiastic that it's
>> possible!
>>
>>  - Chris
>>
>> PS: I'd like to see bipt's elisp branch merged with master.  I might try
>> to help... I'm trying to learn enough to do so.  However I don't have a
>> lot of time, and especially not a lot of experience with compilers..
>>
>>

Hello,
I only know the article in emacs wiki:
https://www.emacswiki.org/emacs/GuileEmacs

especially the part 3 "Long Term Issues".

Best Regards
-- 
Stefan Husmann

Re: Elisp branch ready for merge (??)

[Christopher Allan Webber]

Christopher Allan Webber writes:

> Well, I didn't think I'd have time to do this (and in a sense I didn't)
> but:
>   https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip
>
> I've rebased the whole branch against git master and added ChangeLog
> style entries.  "make check" is passing.  It seems to me that it's ready
> for merge.  I did the best I could on the ChangeLog additions, both with
> my limited ChangeLog experience and from my limited Guile internals
> experience.  So, corrections welcome, but otherwise...
>
> I think we really should not delay on this, and we should try to merge
> this as soon as possible.  This already has bitrotted before, and if we
> wait on it, it could bitrot again.  It would be great to get this pulled
> into Guile proper.
>
> Plus it would be a nice bullet point in the next release! :)
>
>  - Chris

I've been given commit access to Guile proper (horray!) and I pushed a
rebased version of this branch to origin at wip-elisp!  Have fun!

 - Chris