From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Rafik NACCACHE Newsgroups: gmane.emacs.devel Subject: Re: Emacs-devel Digest, Vol 153, Issue 12 Date: Wed, 2 Nov 2016 22:26:03 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0122f24cb565300540581672 X-Trace: blaine.gmane.org 1478122056 24600 195.159.176.226 (2 Nov 2016 21:27:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Nov 2016 21:27:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 02 22:27:29 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c233k-00023c-NK for ged-emacs-devel@m.gmane.org; Wed, 02 Nov 2016 22:27:01 +0100 Original-Received: from localhost ([::1]:57828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c233n-0002lL-I8 for ged-emacs-devel@m.gmane.org; Wed, 02 Nov 2016 17:27:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c232z-0002dE-9o for emacs-devel@gnu.org; Wed, 02 Nov 2016 17:26:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c232u-0007bM-4x for emacs-devel@gnu.org; Wed, 02 Nov 2016 17:26:13 -0400 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:38423) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c232t-0007au-NQ for emacs-devel@gnu.org; Wed, 02 Nov 2016 17:26:08 -0400 Original-Received: by mail-wm0-x229.google.com with SMTP id n67so63623430wme.1 for ; Wed, 02 Nov 2016 14:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=kHHhtYsxAW32G3xuuUrQMTiJvX5o7640bzl7/PZOzmQ=; b=SGN7kIe+kTJIKWRxCzTaaVUQeMuOCS8Ksa2z0EzC7RWbxAHU/C/r8MmGiPijPE0nmM s5NcTzOW5yn6oD4XJdOecVVbwHwxWDlxFa/mUB2/uSNwkf4bK5BWbk2OIV8zOm3NiE8D qMix+4KEWqqKDaNrcWMpOz1mynC2EX3CPBD4p1wW6VSZx06RPk41W44IAzWV7tN1kDrK PT1JE9vSPmLPtiTf7y1Fk3mA3LSsiy/HdOdd4CrYYmi8XTC4G6bB0lVYenHvY7XDM6cE xSIe+htuIsU0LgI4SEi2vRzIgR4OdIj1hByhU6MNKvVURx0U89rZeYn2nFSRlFixZkE1 ibvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kHHhtYsxAW32G3xuuUrQMTiJvX5o7640bzl7/PZOzmQ=; b=mfSa6/i48h8pDGvUPqKSnFYGKCN9UYYJjUvMQ6X039Oo6tKAWIxXVSTh/gjG1mkH1M 2g2leNVzIOZBA+voYJ6TW9f18QEWC4O4EQ+C8QOkWdbeMdAzwphcbc26iJO56zCefmCw NaQrVejbDwy4RBMpt2eXLo3Y2gnclshsWe0qGdeuIzqrbFZkVI/hYRKoyHdaaNU18/gL VGfTmhgdXj8S1TkZe3S18XjalYU/q4jVLfFnICzFFX7CC2lsDqK8PsaTjjuMndu1uZBB JiM6Vkw9kpbYE5mvzblvUDOOfLHFHggpXGiyu8iqOEMjsB3jIVNjOIa+o2KmdVxTuHrk YFOQ== X-Gm-Message-State: ABUngvf6pqA7+P5PQ3OdEy4UKwuXWV0SmwUWQ5YKA+CU4bWh1VidWTjlYqdjofg3cNttKQ3grrRixY8t+ZXERg== X-Received: by 10.194.168.129 with SMTP id zw1mr5827944wjb.26.1478121965821; Wed, 02 Nov 2016 14:26:05 -0700 (PDT) Original-Received: by 10.194.144.165 with HTTP; Wed, 2 Nov 2016 14:26:03 -0700 (PDT) Original-Received: by 10.194.144.165 with HTTP; Wed, 2 Nov 2016 14:26:03 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209130 Archived-At: --089e0122f24cb565300540581672 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey thank you! In readme I noticed that you talk about EDN. I actually am not using it, just plain Clojure maps. Can you please change it? Also please fix the keywordize story and I'll merge your PR. Thank you so much! Le 2 nov. 2016 9:17 PM, a =C3=A9crit : > Send Emacs-devel mailing list submissions to > emacs-devel@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/emacs-devel > or, via email, send a message with subject or body 'help' to > emacs-devel-request@gnu.org > > You can reach the person managing the list at > emacs-devel-owner@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Emacs-devel digest..." > > > Today's Topics: > > 1. Re: Can we go GTK-only? (Stefan Monnier) > 2. Re: on using cl-do-symbols (Mark Oteiza) > 3. Re: on using cl-do-symbols (Stefan Monnier) > 4. Re: Can we go GTK-only? (Nikolaus Rath) > 5. Re: [PATCH] eww-open-in-new-buffer (Lars Ingebrigtsen) > 6. Re: Can we go GTK-only? (Nikolaus Rath) > 7. Re: [Emacs-diffs] master 3f06795: Migrate auth-source to > cl-lib (Stefan Monnier) > 8. Re: Can we go GTK-only? (Eli Zaretskii) > 9. Re: [Emacs-diffs] master 3f06795: Migrate auth-source to > cl-lib (Mark Oteiza) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 02 Nov 2016 12:04:48 -0400 > From: Stefan Monnier > To: Eli Zaretskii > Cc: perry@piermont.com, dancol@dancol.org, raeburn@raeburn.org, > emacs-devel@gnu.org > Subject: Re: Can we go GTK-only? > Message-ID: > Content-Type: text/plain > > > "Should", not "will". And on some systems, only with very recent > > library versions. > > Again: which system are you think of that's had a buggy > malloc-with-threads in the last, say, ten years? > > > Stefan > > > > ------------------------------ > > Message: 2 > Date: Wed, 02 Nov 2016 13:56:12 -0400 > From: Mark Oteiza > To: Stefan Monnier > Cc: emacs-devel@gnu.org > Subject: Re: on using cl-do-symbols > Message-ID: <874m3p22bn.fsf@udel.edu> > Content-Type: text/plain; charset=3Dutf-8 > > > Stefan Monnier writes: > >> The warning is that there is an unused binding for `sym'. > >> cl-do-symbols does create an outer (let (sym) ?) and then inside > >> mapatoms, another (lambda (sym) ?). Does the outer let-binding in > >> cl-do-symbols need to be there? > > > > I guess it is there so as to obey the CL definition which says: > > > > When result-form is evaluated, var is bound and has the value nil. > > > > If that's the case, then the let-binding can be moved so it only > > covers the `,(nth 2 spec)` part of the code. Personally, I'd be happy > > to disobey the CL specification in this regard since I find it > > completely silly. > > I agree--I can't think of a reason why var should be part of > result-form. Interestingly, in the dynamic binding part of dolist, var > is indeed set to nil. > > > > ------------------------------ > > Message: 3 > Date: Wed, 02 Nov 2016 14:23:05 -0400 > From: Stefan Monnier > To: emacs-devel@gnu.org > Subject: Re: on using cl-do-symbols > Message-ID: > Content-Type: text/plain > > > Interestingly, in the dynamic binding part of dolist, var is indeed > > set to nil. > > Yes, that's for backward compatibility (the lexical part doesn't need > to care about that backward compatibility ;-). > > > Stefan > > > > > ------------------------------ > > Message: 4 > Date: Wed, 02 Nov 2016 12:25:03 -0700 > From: Nikolaus Rath > To: emacs-devel@gnu.org > Subject: Re: Can we go GTK-only? > Message-ID: <87wpglr8fk.fsf@thinkpad.rath.org> > Content-Type: text/plain; charset=3Dutf-8 > > On Nov 02 2016, Stefan Monnier wrote: > >> "Should", not "will". And on some systems, only with very recent > >> library versions. > > > > Again: which system are you think of that's had a buggy > > malloc-with-threads in the last, say, ten years? > > GNU libc on Linux in 2008, it seems: > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D6952 > > Best, > Nikolaus > > > -- > GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F > Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > ?Time flies like an arrow, fruit flies like a Banana.? > > > > ------------------------------ > > Message: 5 > Date: Wed, 02 Nov 2016 20:22:47 +0100 > From: Lars Ingebrigtsen > To: Mark Oteiza > Cc: emacs-devel@gnu.org > Subject: Re: [PATCH] eww-open-in-new-buffer > Message-ID: > Content-Type: text/plain > > Mark Oteiza writes: > > > I wanted something akin to "open in new tab" for eww, so I wrote the > > following. > > > > M-RET seemed a good binding. One thing that bugs me about this is that > > eww-current-url in eww-suggest-uris didn't quite fit: as the new > > function is, it doesn't make sense if url is (eww-current-url). > > > > So, I made changes to eww-suggest-uris. Alternatively, > > eww-open-in-new-buffer could check if url is equal to eww-current-url > > and just clone instead of invoking eww. That might be better. > > Looks good to me, I think. It should probably have a NEWS entry and an > eww manual entry, though. > > > (defcustom eww-suggest-uris > > '(eww-links-at-point > > - url-get-url-at-point > > - eww-current-url) > > + url-get-url-at-point) > > And this should have a :version "26.1". > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > > > > ------------------------------ > > Message: 6 > Date: Wed, 02 Nov 2016 12:25:03 -0700 > From: Nikolaus Rath > To: emacs-devel@gnu.org > Subject: Re: Can we go GTK-only? > Message-ID: <87vaw5r89d.fsf@thinkpad.rath.org> > Content-Type: text/plain; charset=3Dutf-8 > > On Nov 02 2016, Stefan Monnier wrote: > >> "Should", not "will". And on some systems, only with very recent > >> library versions. > > > > Again: which system are you think of that's had a buggy > > malloc-with-threads in the last, say, ten years? > > GNU libc on Linux in 2008, it seems: > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D6952 > > (Just providing the link, personally I think that even with such bugs it > it safe to assume a threadsafe malloc both then and now. Otherwise you > may just as well assume that nothing works anywhere at all). > > Best, > Nikolaus > > > -- > GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F > Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > ?Time flies like an arrow, fruit flies like a Banana.? > > > > ------------------------------ > > Message: 7 > Date: Wed, 02 Nov 2016 16:06:01 -0400 > From: Stefan Monnier > To: emacs-devel@gnu.org > Cc: Mark Oteiza > Subject: Re: [Emacs-diffs] master 3f06795: Migrate auth-source to > cl-lib > Message-ID: > Content-Type: text/plain > > > +(eval-when-compile > > + (require 'cl-lib) > > + (require 'eieio)) > > AFAIK eieio's macros always end up returning code which depends on eieio > functions, so a compile-time only `require` of eieio doesn't make > much sense. > > > Stefan > > > > ------------------------------ > > Message: 8 > Date: Wed, 02 Nov 2016 22:13:13 +0200 > From: Eli Zaretskii > To: Stefan Monnier > Cc: perry@piermont.com, dancol@dancol.org, raeburn@raeburn.org, > emacs-devel@gnu.org > Subject: Re: Can we go GTK-only? > Message-ID: <83eg2tmyhy.fsf@gnu.org> > > > From: Stefan Monnier > > Cc: perry@piermont.com, dancol@dancol.org, raeburn@raeburn.org, > emacs-devel@gnu.org > > Date: Wed, 02 Nov 2016 12:04:48 -0400 > > > > > "Should", not "will". And on some systems, only with very recent > > > library versions. > > > > Again: which system are you think of that's had a buggy > > malloc-with-threads in the last, say, ten years? > > Even glibc had a bug. And one or 2 of *BSDs. > > > > ------------------------------ > > Message: 9 > Date: Wed, 2 Nov 2016 16:16:24 -0400 > From: Mark Oteiza > To: Stefan Monnier > Cc: emacs-devel@gnu.org > Subject: Re: [Emacs-diffs] master 3f06795: Migrate auth-source to > cl-lib > Message-ID: <20161102201624.GA18839@holos.localdomain> > Content-Type: text/plain; charset=3Dus-ascii > > On 02/11/16 at 04:06pm, Stefan Monnier wrote: > > > +(eval-when-compile > > > + (require 'cl-lib) > > > + (require 'eieio)) > > > > AFAIK eieio's macros always end up returning code which depends on eiei= o > > functions, so a compile-time only `require` of eieio doesn't make > > much sense. > > You're right, thanks. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/emacs-devel > > ------------------------------ > > End of Emacs-devel Digest, Vol 153, Issue 12 > ******************************************** > --089e0122f24cb565300540581672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hey thank you!

In readme I noticed that you talk about EDN. I actually am n= ot using it, just plain Clojure maps. Can you please change it?

Also please=C2=A0 fix the keywordize story and I'll merg= e your PR.

Thank you so much!


Le=C2=A02 nov. 20= 16 9:17 PM, <emacs-devel= -request@gnu.org> a =C3=A9crit=C2=A0:
Send Emacs-devel mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 emacs-de= vel@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.gnu.org/= mailman/listinfo/emacs-devel
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = emacs-devel-request@gnu.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 em= acs-devel-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emacs-devel digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Can we go GTK-only? (Stefan Monnier)
=C2=A0 =C2=A02. Re: on using cl-do-symbols (Mark Oteiza)
=C2=A0 =C2=A03. Re: on using cl-do-symbols (Stefan Monnier)
=C2=A0 =C2=A04. Re: Can we go GTK-only? (Nikolaus Rath)
=C2=A0 =C2=A05. Re: [PATCH] eww-open-in-new-buffer (Lars Ingebrigtsen)
=C2=A0 =C2=A06. Re: Can we go GTK-only? (Nikolaus Rath)
=C2=A0 =C2=A07. Re: [Emacs-diffs] master 3f06795: Migrate auth-source to =C2=A0 =C2=A0 =C2=A0 cl-lib (Stefan Monnier)
=C2=A0 =C2=A08. Re: Can we go GTK-only? (Eli Zaretskii)
=C2=A0 =C2=A09. Re: [Emacs-diffs] master 3f06795: Migrate auth-source to =C2=A0 =C2=A0 =C2=A0 cl-lib (Mark Oteiza)


-----------------------------------------------------------------= -----

Message: 1
Date: Wed, 02 Nov 2016 12:04:48 -0400
From: Stefan Monnier <monnie= r@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org><= br> Cc: perry@piermont.com, dancol@dancol.org, raeburn@raeburn.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 emacs-de= vel@gnu.org
Subject: Re: Can we go GTK-only?
Message-ID: <= jwv7f8ldg3h.fsf-monnier+Inbox@gnu.org>
Content-Type: text/plain

> "Should", not "will".=C2=A0 And on some systems, o= nly with very recent
> library versions.

Again: which system are you think of that's had a buggy
malloc-with-threads in the last, say, ten years?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan



------------------------------

Message: 2
Date: Wed, 02 Nov 2016 13:56:12 -0400
From: Mark Oteiza <mvoteiza@udel.ed= u>
To: Stefan Monnier <monnier@= iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: on using cl-do-symbols
Message-ID: <874m3p22bn.fsf@u= del.edu>
Content-Type: text/plain; charset=3Dutf-8


Stefan Monnier <monnier@iro.= umontreal.ca> writes:
>> The warning is that there is an unused binding for `sym'.
>> cl-do-symbols does create an outer (let (sym) ?) and then inside >> mapatoms, another (lambda (sym) ?).=C2=A0 Does the outer let-bindi= ng in
>> cl-do-symbols need to be there?
>
> I guess it is there so as to obey the CL definition which says:
>
>=C2=A0 =C2=A0 =C2=A0When result-form is evaluated, var is bound and has= the value nil.
>
> If that's the case, then the let-binding can be moved so it only > covers the `,(nth 2 spec)` part of the code.=C2=A0 Personally, I'd= be happy
> to disobey the CL specification in this regard since I find it
> completely silly.

I agree--I can't think of a reason why var should be part of
result-form.=C2=A0 Interestingly, in the dynamic binding part of dolist, va= r
is indeed set to nil.



------------------------------

Message: 3
Date: Wed, 02 Nov 2016 14:23:05 -0400
From: Stefan Monnier <monnie= r@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: on using cl-do-symbols
Message-ID: <jwvk2cl214c.fsf-monnier+gmane.emacs.devel@gnu.org><= br> Content-Type: text/plain

> Interestingly, in the dynamic binding part of dolist, var is indeed > set to nil.

Yes, that's for backward compatibility (the lexical part doesn't ne= ed
to care about that backward compatibility ;-).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan




------------------------------

Message: 4
Date: Wed, 02 Nov 2016 12:25:03 -0700
From: Nikolaus Rath <Nikolaus@rath.= org>
To: emacs-devel@gnu.org
Subject: Re: Can we go GTK-only?
Message-ID: <87wpglr= 8fk.fsf@thinkpad.rath.org>
Content-Type: text/plain; charset=3Dutf-8

On Nov 02 2016, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> "Should", not "will".=C2=A0 And on some system= s, only with very recent
>> library versions.
>
> Again: which system are you think of that's had a buggy
> malloc-with-threads in the last, say, ten years?

GNU libc on Linux in 2008, it seems:

https://sourceware.org/bugzilla/show_bug.= cgi?id=3D6952

Best,
Nikolaus


--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0?Time flies like an arrow, = fruit flies like a Banana.?



------------------------------

Message: 5
Date: Wed, 02 Nov 2016 20:22:47 +0100
From: Lars Ingebrigtsen <larsi@gnus.or= g>
To: Mark Oteiza <mvoteiza@udel.edu<= /a>>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] eww-open-in-new-buffer
Message-ID: <m3d1idit4o.fsf@g= nus.org>
Content-Type: text/plain

Mark Oteiza <mvoteiza@udel.edu&= gt; writes:

> I wanted something akin to "open in new tab" for eww, so I w= rote the
> following.
>
> M-RET seemed a good binding.=C2=A0 One thing that bugs me about this i= s that
> eww-current-url in eww-suggest-uris didn't quite fit: as the new > function is, it doesn't make sense if url is (eww-current-url). >
> So, I made changes to eww-suggest-uris.=C2=A0 Alternatively,
> eww-open-in-new-buffer could check if url is equal to eww-current-url<= br> > and just clone instead of invoking eww.=C2=A0 That might be better.
Looks good to me, I think.=C2=A0 It should probably have a NEWS entry and a= n
eww manual entry, though.

>=C2=A0 (defcustom eww-suggest-uris
>=C2=A0 =C2=A0 '(eww-links-at-point
> -=C2=A0 =C2=A0 url-get-url-at-point
> -=C2=A0 =C2=A0 eww-current-url)
> +=C2=A0 =C2=A0 url-get-url-at-point)

And this should have a :version "26.1".

--
(domestic pets only, the antidote for overdose, milk.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no



------------------------------

Message: 6
Date: Wed, 02 Nov 2016 12:25:03 -0700
From: Nikolaus Rath <Nikolaus@rath.= org>
To: emacs-devel@gnu.org
Subject: Re: Can we go GTK-only?
Message-ID: <87vaw5r= 89d.fsf@thinkpad.rath.org>
Content-Type: text/plain; charset=3Dutf-8

On Nov 02 2016, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> "Should", not "will".=C2=A0 And on some system= s, only with very recent
>> library versions.
>
> Again: which system are you think of that's had a buggy
> malloc-with-threads in the last, say, ten years?

GNU libc on Linux in 2008, it seems:

https://sourceware.org/bugzilla/show_bug.= cgi?id=3D6952

(Just providing the link, personally I think that even with such bugs it it safe to assume a threadsafe malloc both then and now. Otherwise you
may just as well assume that nothing works anywhere at all).

Best,
Nikolaus


--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0?Time flies like an arrow, = fruit flies like a Banana.?



------------------------------

Message: 7
Date: Wed, 02 Nov 2016 16:06:01 -0400
From: Stefan Monnier <monnie= r@iro.umontreal.ca>
To: emacs-devel@gnu.org
Cc: Mark Oteiza <mvoteiza@udel.edu<= /a>>
Subject: Re: [Emacs-diffs] master 3f06795: Migrate auth-source to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cl-lib
Message-ID: <jwvpomdtzs0.fsf-monnier+emacsdiffs@gnu.org>
Content-Type: text/plain

> +(eval-when-compile
> +=C2=A0 (require 'cl-lib)
> +=C2=A0 (require 'eieio))

AFAIK eieio's macros always end up returning code which depends on eiei= o
functions, so a compile-time only `require` of eieio doesn't make
much sense.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan



------------------------------

Message: 8
Date: Wed, 02 Nov 2016 22:13:13 +0200
From: Eli Zaretskii <eliz@gnu.org>= ;
To: Stefan Monnier <monnier@= iro.umontreal.ca>
Cc: perry@piermont.com, dancol@dancol.org, raeburn@raeburn.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 emacs-de= vel@gnu.org
Subject: Re: Can we go GTK-only?
Message-ID: <83eg2tmyhy.fsf@gn= u.org>

> From: Stefan Monnier <m= onnier@iro.umontreal.ca>
> Cc: perry@piermont.com,=C2= =A0 dancol@dancol.org,=C2=A0 raeburn@raeburn.org,=C2=A0 emacs-devel@gnu.org
> Date: Wed, 02 Nov 2016 12:04:48 -0400
>
> > "Should", not "will".=C2=A0 And on some syste= ms, only with very recent
> > library versions.
>
> Again: which system are you think of that's had a buggy
> malloc-with-threads in the last, say, ten years?

Even glibc had a bug.=C2=A0 And one or 2 of *BSDs.



------------------------------

Message: 9
Date: Wed, 2 Nov 2016 16:16:24 -0400
From: Mark Oteiza <mvoteiza@udel.ed= u>
To: Stefan Monnier <monnier@= iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 3f06795: Migrate auth-source to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cl-lib
Message-ID: <20161102201624.GA18839@holos.localdomain>
Content-Type: text/plain; charset=3Dus-ascii

On 02/11/16 at 04:06pm, Stefan Monnier wrote:
> > +(eval-when-compile
> > +=C2=A0 (require 'cl-lib)
> > +=C2=A0 (require 'eieio))
>
> AFAIK eieio's macros always end up returning code which depends on= eieio
> functions, so a compile-time only `require` of eieio doesn't make<= br> > much sense.

You're right, thanks.



------------------------------

Subject: Digest Footer

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/emacs-= devel

------------------------------

End of Emacs-devel Digest, Vol 153, Issue 12
********************************************
--089e0122f24cb565300540581672--