emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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!


Le 2 nov. 2016 9:17 PM, <address@hidden> a écrit :
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@hiddenaddress@hiddenaddress@hiddenaddress@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
********************************************

reply via email to

[Prev in Thread] Current Thread [Next in Thread]