Re: Emacs-devel Digest, Vol 153, Issue 12

Re: Emacs-devel Digest, Vol 153, Issue 12

[Rafik NACCACHE]

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

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, <emacs-devel-request@gnu.org> 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 <monnier@iro.umontreal.ca>
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: perry@piermont.com, dancol@dancol.org, raeburn@raeburn.org,
>         emacs-devel@gnu.org
> Subject: Re: Can we go GTK-only?
> Message-ID: <jwv7f8ldg3h.fsf-monnier+Inbox@gnu.org>
> 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 <mvoteiza@udel.edu>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> 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 <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) ?).  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 <monnier@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>
> 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 <Nikolaus@rath.org>
> 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 <monnier@iro.umontreal.ca> 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 <larsi@gnus.org>
> To: Mark Oteiza <mvoteiza@udel.edu>
> Cc: emacs-devel@gnu.org
> Subject: Re: [PATCH] eww-open-in-new-buffer
> Message-ID: <m3d1idit4o.fsf@gnus.org>
> Content-Type: text/plain
>
> Mark Oteiza <mvoteiza@udel.edu> 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 <Nikolaus@rath.org>
> 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 <monnier@iro.umontreal.ca> 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 <monnier@iro.umontreal.ca>
> To: emacs-devel@gnu.org
> Cc: Mark Oteiza <mvoteiza@udel.edu>
> Subject: Re: [Emacs-diffs] master 3f06795: Migrate auth-source to
>         cl-lib
> Message-ID: <jwvpomdtzs0.fsf-monnier+emacsdiffs@gnu.org>
> 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 <eliz@gnu.org>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> 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 <monnier@iro.umontreal.ca>
> > 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 <mvoteiza@udel.edu>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> 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
> ********************************************
>

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