|
| From: | Rafik NACCACHE |
| Subject: | Re: Emacs-devel Digest, Vol 153, Issue 12 |
| Date: | Wed, 2 Nov 2016 22:26:03 +0100 |
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!
Send Emacs-devel mailing list submissions to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
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 <address@hidden>
To: Eli Zaretskii <address@hidden>
Cc: address@hidden, address@hidden, address@hidden,
address@hidden
Subject: Re: Can we go GTK-only?
Message-ID: <jwv7f8ldg3h.fsf-monnier+address@hidden >
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 <address@hidden>
To: Stefan Monnier <address@hidden>
Cc: address@hidden
Subject: Re: on using cl-do-symbols
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8
Stefan Monnier <address@hidden> 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 <address@hidden>
To: address@hidden
Subject: Re: on using cl-do-symbols
Message-ID: <jwvk2cl214c.fsf-monnier+address@hidden >
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 <address@hidden>
To: address@hidden
Subject: Re: Can we go GTK-only?
Message-ID: <address@hiddenorg >
Content-Type: text/plain; charset=utf-8
On Nov 02 2016, Stefan Monnier <address@hidden> 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 <address@hidden>
To: Mark Oteiza <address@hidden>
Cc: address@hidden
Subject: Re: [PATCH] eww-open-in-new-buffer
Message-ID: <address@hidden>
Content-Type: text/plain
Mark Oteiza <address@hidden> 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 <address@hidden>
To: address@hidden
Subject: Re: Can we go GTK-only?
Message-ID: <address@hiddenorg >
Content-Type: text/plain; charset=utf-8
On Nov 02 2016, Stefan Monnier <address@hidden> 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 <address@hidden>
To: address@hidden
Cc: Mark Oteiza <address@hidden>
Subject: Re: [Emacs-diffs] master 3f06795: Migrate auth-source to
cl-lib
Message-ID: <jwvpomdtzs0.fsf-monnier+address@hidden >
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 <address@hidden>
To: Stefan Monnier <address@hidden>
Cc: address@hidden, address@hidden, address@hidden,
address@hidden
Subject: Re: Can we go GTK-only?
Message-ID: <address@hidden>
> From: Stefan Monnier <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden, address@hidden
> 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 <address@hidden>
To: Stefan Monnier <address@hidden>
Cc: address@hidden
Subject: Re: [Emacs-diffs] master 3f06795: Migrate auth-source to
cl-lib
Message-ID: <address@hiddenlocaldomain>
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
address@hidden
https://lists.gnu.org/mailman/listinfo/emacs-devel
------------------------------
End of Emacs-devel Digest, Vol 153, Issue 12
********************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |