* Re: Emacs-devel Digest, Vol 153, Issue 12
[not found] <mailman.15177.1478117793.22738.emacs-devel@gnu.org>
@ 2016-11-02 21:26 ` Rafik NACCACHE
0 siblings, 0 replies; only message in thread
From: Rafik NACCACHE @ 2016-11-02 21:26 UTC (permalink / raw)
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] only message in thread