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 écrit : > 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=utf-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=utf-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=6952 > > 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=utf-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=6952 > > (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=us-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 eieio > > 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 > ******************************************** >