|
| From: | Pedro Andres Aranda Gutierrez |
| Subject: | Re: Emacs-devel Digest, Vol 204, Issue 28 |
| Date: | Sat, 27 Feb 2021 08:48:30 +0100 |
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: Emacs Survey: Toolbars (Eli Zaretskii)
2. Re: Consistent face for keys in *Help* and
`substitute-command-keys' (Eli Zaretskii)
3. Re: Pattern matching on match-string groups #elisp #question
(Mattias Engdegård)
4. Re: Consistent face for keys in *Help* and
`substitute-command-keys' (Stefan Kangas)
5. Re: master 297c0e0: New variable 'use-short-answers' to use
'y-or-n-p' instead of 'yes-or-no-p' (Stefan Kangas)
6. Re: Emacs Survey: Toolbars (Stefan Monnier)
7. Re: Consistent face for keys in *Help* and
`substitute-command-keys' (Eli Zaretskii)
8. RE: [External] : Re: Consistent face for keys in *Help* and
`substitute-command-keys' (Drew Adams)
9. Re: Emacs Survey: Toolbars (Eli Zaretskii)
10. RE: [External] : Re: Emacs Survey: Toolbars (Drew Adams)
11. Re: master 297c0e0: New variable 'use-short-answers' to use
'y-or-n-p' instead of 'yes-or-no-p' (Juri Linkov)
12. Re: Consistent face for keys in *Help* and
`substitute-command-keys' (martin rudalics)
13. Re: Emacs Survey: Toolbars (martin rudalics)
14. Re: Consistent face for keys in *Help* and
`substitute-command-keys' (Stefan Kangas)
15. Re: Consistent face for keys in *Help* and
`substitute-command-keys' (Eli Zaretskii)
16. Re: Has eval-and-compile changed in emacs 27? (Leo Liu)
17. Re: Has eval-and-compile changed in emacs 27? (Leo Liu)
18. Re: Emacs Survey: Toolbars (Stefan Monnier)
19. Re: Has eval-and-compile changed in emacs 27? (Stefan Monnier)
20. Re: Emacs Survey: Toolbars (Jeremy Bryant)
21. Re:Re: [elpa] externals/pyim 1e14e7c: V3.1 (tumashu)
22. Re: Has eval-and-compile changed in emacs 27? (Leo Liu)
23. Re: Has eval-and-compile changed in emacs 27? (Stefan Monnier)
24. Re: Pattern matching on match-string groups #elisp #question
(Stefan Monnier)
25. Re:Re: [elpa] externals/pyim 1e14e7c: V3.1 (tumashu)
26. Re: Requesting a paid version of Emacs (Richard Stallman)
27. Re: Has eval-and-compile changed in emacs 27? (Richard Stallman)
28. Re: feature/native-comp ec88bdb 1/4: * Add a simple growable
vector like type (Richard Stallman)
29. Re: Emacs Survey: Toolbars (Eli Zaretskii)
30. Re: [elpa] externals/pyim 1e14e7c: V3.1 (Eli Zaretskii)
31. Re: Has eval-and-compile changed in emacs 27? (Eli Zaretskii)
32. Re: Has eval-and-compile changed in emacs 27? (Leo Liu)
33. Re: emacs-27 7a23915: * lisp/tooltip.el (tooltip): Doc fix
for GTK. (Stephen Berman)
34. Re: Emacs Survey: Toolbars (Lars Ingebrigtsen)
35. Re: Requesting a paid version of Emacs (Robert Pluim)
36. Re: Has eval-and-compile changed in emacs 27?
(Basil L. Contovounesios)
37. Re: feature/native-comp ec88bdb 1/4: * Add a simple growable
vector like type (Robert Pluim)
38. Re: Has eval-and-compile changed in emacs 27?
(Basil L. Contovounesios)
39. Re: Has eval-and-compile changed in emacs 27?
(Basil L. Contovounesios)
40. Re: Pattern matching on match-string groups #elisp #question
(Mattias Engdegård)
41. Re: master 9291e73 02/12: Add new 'declare' forms for command
completion predicates (Basil L. Contovounesios)
42. Re: Run (some) tests more automagically? (Phillip Lord)
43. Re: Run (some) tests more automagically? (Lars Ingebrigtsen)
44. Re: Has eval-and-compile changed in emacs 27? (Eli Zaretskii)
45. Re: master fbc9c59: Make goto-line-history buffer local only
when so customized (Basil L. Contovounesios)
46. Re: master fbc9c59: Make goto-line-history buffer local only
when so customized (Alan Mackenzie)
47. Re: master fbc9c59: Make goto-line-history buffer local only
when so customized (Basil L. Contovounesios)
48. Re: master fbc9c59: Make goto-line-history buffer local only
when so customized (Alan Mackenzie)
49. Re: Has eval-and-compile changed in emacs 27? (Stefan Monnier)
50. RE: [External] : Re: Emacs Survey: Toolbars (Drew Adams)
51. Re: [External] : Re: Emacs Survey: Toolbars (Stefan Monnier)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Feb 2021 20:17:26 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Emacs Survey: Toolbars
Message-ID: <838s7crozt.fsf@gnu.org" target="_blank">838s7crozt.fsf@gnu.org>
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 25 Feb 2021 09:50:29 -0600
> Cc: emacs-devel@gnu.org
>
> How about introducing a new variable with the tentative name
> `this-mode-wants-toolbars' that defaults to nil? If it is nil, there
> are no toolbars. This variable can then be set to t when someone has
> made a toolbar that they know will be useful.
That makes little sense to me. Other applications that show tool bars
don't make them appear and disappear, only change as appropriate for
the context.
> One obvious drawback of this proposal is that it's slightly jarring when
> the toolbar appears and disappears when switching between windows.
Exactly.
> Perhaps we could show it if it is enabled in any buffer in a window on
> the current frame?
So you basically want NOT to make it disappear? Then why make it
disappear?
------------------------------
Message: 2
Date: Thu, 25 Feb 2021 20:25:27 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefan@marxist.se>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Consistent face for keys in *Help* and
`substitute-command-keys'
Message-ID: <831rd4romg.fsf@gnu.org" target="_blank">831rd4romg.fsf@gnu.org>
> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 25 Feb 2021 10:45:42 -0600
> Cc: larsi@gnus.org, emacs-devel@gnu.org
>
> 0. emacs -Q
> 1. M-x fundamental-mode RET
> 2. M-: (insert (propertize "foo" 'help-echo "foo \\[forward-line]")) RET
>
> No visible effect on the tooltip --with-x-toolkit={gtk,lucid,athena,no}.
And the face for keys is defined how?
------------------------------
Message: 3
Date: Thu, 25 Feb 2021 19:28:16 +0100
From: Mattias Engdegård <mattiase@acm.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, Ag Ibragimov
<agzam.ibragimov@gmail.com>, emacs-devel@gnu.org
Subject: Re: Pattern matching on match-string groups #elisp #question
Message-ID: <80CE2366-76F4-4548-B956-F16DFCE23E4C@acm.org" target="_blank">80CE2366-76F4-4548-B956-F16DFCE23E4C@acm.org>
Content-Type: text/plain; charset=us-ascii
25 feb. 2021 kl. 16.32 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
>> The same won't work with pcase-let, so it's either unsupported or a bug.
>
> I'd say it's a bug. The patch below would fix it. Mattias, WDYT?
Thank you, it looks like multiple bugs. The lack of (pred stringp) was of course an oversight but unrelated to pcase-let, right?
> (let* ((rx--pcase-vars nil)
> (regexp (rx--to-expr (rx--pcase-transform (cons 'seq regexps)))))
> - `(and (pred (string-match ,regexp))
> + `(and (pred stringp)
> + (app (lambda (s) (string-match ,regexp s)) (pred identity))
It does seem to work, but why exactly do we need this monstrosity instead of (pred (string-match ,regexp))? Is it because pcase-let throws away all `pred` clauses somewhere? It makes sense to do so but I haven't found exactly where this takes place in pcase.el yet...
Perhaps the assumption that non-binding clauses like `pred` (and what else, `guard`?) are all side-effect free and can be thrown away in pcase-let[*] should be documented? Not that I would have read it, of course...
I'll push a fix as soon as I understand the machinery a bit better, but right now I'm wary of getting my fingers snapped off by the gears and knives.
------------------------------
Message: 4
Date: Thu, 25 Feb 2021 12:48:37 -0600
From: Stefan Kangas <stefan@marxist.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Consistent face for keys in *Help* and
`substitute-command-keys'
Message-ID:
<CADwFkmk5PVhWNqaaKxBuzYK9szTUSXqgTuo86ZPozmNeS048kw@mail.gmail.com" target="_blank">CADwFkmk5PVhWNqaaKxBuzYK9szTUSXqgTuo86ZPozmNeS048kw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Eli Zaretskii <eliz@gnu.org> writes:
>> 0. emacs -Q
>> 1. M-x fundamental-mode RET
>> 2. M-: (insert (propertize "foo" 'help-echo "foo \\[forward-line]")) RET
>>
>> No visible effect on the tooltip --with-x-toolkit={gtk,lucid,athena,no}.
>
> And the face for keys is defined how?
(defface help-key-binding '((t :foreground "RoyalBlue3"))
"Face for keybindings in *Help* buffers."
:version "28.1"
:group 'help)
------------------------------
Message: 5
Date: Thu, 25 Feb 2021 13:02:29 -0600
From: Stefan Kangas <stefankangas@gmail.com>
To: Juri Linkov <juri@jurta.org>, emacs-devel@gnu.org
Subject: Re: master 297c0e0: New variable 'use-short-answers' to use
'y-or-n-p' instead of 'yes-or-no-p'
Message-ID:
<CADwFkm=zxiH5b=ScmpLuLx+GQi+J2Mt-yrO6JYO_E1-Am7xSNA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
juri@jurta.org (Juri Linkov) writes:
> branch: master
> commit 297c0e0306f111c1e7564b2bb49a7e1a925a55bb
> Author: Juri Linkov <juri@linkov.net>
> Commit: Juri Linkov <juri@linkov.net>
>
> New variable 'use-short-answers' to use 'y-or-n-p' instead of 'yes-or-no-p'
Good idea, thanks.
> + if (use_short_answers)
> + {
> + return call1 (intern ("y-or-n-p"), prompt);
> + }
> +
Just a nit: you don't need to wrap single statements in "{ ... }".
------------------------------
Message: 6
Date: Thu, 25 Feb 2021 14:03:26 -0500
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Kangas <stefankangas@gmail.com>, larsi@gnus.org,
emacs-devel@gnu.org
Subject: Re: Emacs Survey: Toolbars
Message-ID: <jwva6rsezxn.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain
> That makes little sense to me. Other applications that show tool bars
> don't make them appear and disappear, only change as appropriate for
> the context.
Which applications are you thinking of here, that would be comparable to
Emacs (i.e. are part music-player, part text editor, part hex editor, part
IRC client, ...)?
>> One obvious drawback of this proposal is that it's slightly jarring when
>> the toolbar appears and disappears when switching between windows.
> Exactly.
I think the solution is to have toolbars inside the window's text,
rather than attached to the frame.
For mpc.el I played with the idea of building up a "toolbar" that gets
inserted into the buffer, but I didn't the time needed to get something
good enough.
Stefan
------------------------------
Message: 7
Date: Thu, 25 Feb 2021 21:11:16 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefan@marxist.se>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Consistent face for keys in *Help* and
`substitute-command-keys'
Message-ID: <83zgzsq7xn.fsf@gnu.org" target="_blank">83zgzsq7xn.fsf@gnu.org>
> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 25 Feb 2021 12:48:37 -0600
> Cc: larsi@gnus.org, emacs-devel@gnu.org
>
> >> 2. M-: (insert (propertize "foo" 'help-echo "foo \\[forward-line]")) RET
> >>
> >> No visible effect on the tooltip --with-x-toolkit={gtk,lucid,athena,no}.
> >
> > And the face for keys is defined how?
>
> (defface help-key-binding '((t :foreground "RoyalBlue3"))
> "Face for keybindings in *Help* buffers."
> :version "28.1"
> :group 'help)
Ah, okay: you are putting the 'face' property, but so does
'tooltip-show'. So yes, the latter one overrides the former one.
So I guess we will need to change the design of this to avoid
overriding the whole face of a tooltip, or maybe add some special code
to help_echo_substitute_command_keys.
------------------------------
Message: 8
Date: Thu, 25 Feb 2021 19:14:57 +0000
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>, Eli Zaretskii <eliz@gnu.org>
Cc: "larsi@gnus.org" <larsi@gnus.org>, "emacs-devel@gnu.org"
<emacs-devel@gnu.org>
Subject: RE: [External] : Re: Consistent face for keys in *Help* and
`substitute-command-keys'
Message-ID:
<SA2PR10MB44744969B807FF0893D85FCFF39E9@SA2PR10MB4474.namprd10.prod.outlook.com" target="_blank">SA2PR10MB44744969B807FF0893D85FCFF39E9@SA2PR10MB4474.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
> (defface help-key-binding '((t :foreground "RoyalBlue3"))
IMO, that's too close to link color, which is "blue1".
------------------------------
Message: 9
Date: Thu, 25 Feb 2021 21:16:30 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Emacs Survey: Toolbars
Message-ID: <83y2fcq7ox.fsf@gnu.org" target="_blank">83y2fcq7ox.fsf@gnu.org>
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefankangas@gmail.com>, larsi@gnus.org,
> emacs-devel@gnu.org
> Date: Thu, 25 Feb 2021 14:03:26 -0500
>
> > That makes little sense to me. Other applications that show tool bars
> > don't make them appear and disappear, only change as appropriate for
> > the context.
>
> Which applications are you thinking of here, that would be comparable to
> Emacs (i.e. are part music-player, part text editor, part hex editor, part
> IRC client, ...)?
I don't see how this is relevant. The tool bar is part of the GUI,
which functions are shown there is immaterial.
> >> One obvious drawback of this proposal is that it's slightly jarring when
> >> the toolbar appears and disappears when switching between windows.
> > Exactly.
>
> I think the solution is to have toolbars inside the window's text,
> rather than attached to the frame.
Is this practical? Windows can be very narrow, and change dimensions
much more frequently in Emacs than frames. Tool bars don't live well
with frequent changes in dimensions.
If someone wants to turn tool bar off, let them do that. We don't
need to turn the Emacs appearance upside down just because of some
fashion: we already support that fashion.
------------------------------
Message: 10
Date: Thu, 25 Feb 2021 19:27:44 +0000
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier
<monnier@iro.umontreal.ca>
Cc: "larsi@gnus.org" <larsi@gnus.org>, "stefankangas@gmail.com"
<stefankangas@gmail.com>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: Emacs Survey: Toolbars
Message-ID:
<SA2PR10MB4474FF87D5F9321B17AE8025F39E9@SA2PR10MB4474.namprd10.prod.outlook.com" target="_blank">SA2PR10MB4474FF87D5F9321B17AE8025F39E9@SA2PR10MB4474.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
> If someone wants to turn tool bar off, let them do that. We don't
> need to turn the Emacs appearance upside down just because of some
> fashion: we already support that fashion.
(This is not what you're discussing now, I
guess, but it can affect whether a user's
choice of whether to use tool bars.)
I'll just mention again that users can have a
popup tool bar. IOW, show it only on demand,
for a single action.
Also, ability to show the tool-bar only for
the current frame.
https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus
This or a similar feature could be added to
vanilla Emacs.
------------------------------
Message: 11
Date: Thu, 25 Feb 2021 21:29:44 +0200
From: Juri Linkov <juri@jurta.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: master 297c0e0: New variable 'use-short-answers' to use
'y-or-n-p' instead of 'yes-or-no-p'
Message-ID: <87k0qwaqtz.fsf@mail.linkov.net" target="_blank">87k0qwaqtz.fsf@mail.linkov.net>
Content-Type: text/plain; charset="utf-8"
>> New variable 'use-short-answers' to use 'y-or-n-p' instead of 'yes-or-no-p'
>
> Good idea, thanks.
>
>> + if (use_short_answers)
>> + {
>> + return call1 (intern ("y-or-n-p"), prompt);
>> + }
>> +
>
> Just a nit: you don't need to wrap single statements in "{ ... }".
Thanks for noticing these extra braces added out of habit of adding parens
in Lisp. Eli already fixed this mistake immediately.
BTW, what do you think about such purely cosmetic patch?
Are there any aesthetic objections?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: read-char-choice-with-read-key.patch
Type: text/x-diff
Size: 4355 bytes
Desc: not available
URL: <https://lists.gnu.org/archive/html/emacs-devel/attachments/20210225/a048db76/attachment.patch>
------------------------------
Message: 12
Date: Thu, 25 Feb 2021 20:44:22 +0100
From: martin rudalics <rudalics@gmx.at>
To: Stefan Kangas <stefan@marxist.se>, Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Consistent face for keys in *Help* and
`substitute-command-keys'
Message-ID: <2674160e-dfba-8be3-0f7b-cac8e2487b08@gmx.at" target="_blank">2674160e-dfba-8be3-0f7b-cac8e2487b08@gmx.at>
Content-Type: text/plain; charset=utf-8; format=flowed
> 2. M-: (insert (propertize "foo" 'help-echo "foo \\[forward-line]")) RET
>
> No visible effect on the tooltip --with-x-toolkit={gtk,lucid,athena,no}.
It should work with 'x-show-tip'.
martin
------------------------------
Message: 13
Date: Thu, 25 Feb 2021 20:44:40 +0100
From: martin rudalics <rudalics@gmx.at>
To: Stefan Kangas <stefankangas@gmail.com>, Lars Ingebrigtsen
<larsi@gnus.org>, Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs Survey: Toolbars
Message-ID: <21fe1e55-8a20-625f-08e2-69ff4cc503d2@gmx.at" target="_blank">21fe1e55-8a20-625f-08e2-69ff4cc503d2@gmx.at>
Content-Type: text/plain; charset=utf-8; format=flowed
> One obvious drawback of this proposal is that it's slightly jarring when
> the toolbar appears and disappears when switching between windows.
Note that with GTK the outer frame shrinks/expands when the toolbar is
removed/added. Not talking about the GTK3 warnings when the toolbar
doesn't fit ...
martin
------------------------------
Message: 14
Date: Thu, 25 Feb 2021 13:47:07 -0600
From: Stefan Kangas <stefan@marxist.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Consistent face for keys in *Help* and
`substitute-command-keys'
Message-ID:
<CADwFkmmwP854hVbN6Q8uV0Wmp_8Ytz17BneWYNge27Si0y3AmA@mail.gmail.com" target="_blank">CADwFkmmwP854hVbN6Q8uV0Wmp_8Ytz17BneWYNge27Si0y3AmA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Eli Zaretskii <eliz@gnu.org> writes:
> Ah, okay: you are putting the 'face' property, but so does
> 'tooltip-show'. So yes, the latter one overrides the former one.
>
> So I guess we will need to change the design of this to avoid
> overriding the whole face of a tooltip, or maybe add some special code
> to help_echo_substitute_command_keys.
Oh, okay. I actually thought your concern was the opposite case here.
I think it is okay that tooltips do not use the `help-key-binding' face.
That seems in line with what other software does for tooltips, I
believe. But I could be wrong.
------------------------------
Message: 15
Date: Thu, 25 Feb 2021 22:32:30 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefan@marxist.se>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Consistent face for keys in *Help* and
`substitute-command-keys'
Message-ID: <83v9afriqp.fsf@gnu.org" target="_blank">83v9afriqp.fsf@gnu.org>
> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 25 Feb 2021 13:47:07 -0600
> Cc: larsi@gnus.org, emacs-devel@gnu.org
>
> I think it is okay that tooltips do not use the `help-key-binding' face.
If you are willing to give up on key sequences in tooltips, then why
do it in substitute-command-keys?
------------------------------
Message: 16
Date: Fri, 26 Feb 2021 05:55:51 +0800
From: Leo Liu <sdl.web@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <m1eeh3errs.fsf@gmail.com" target="_blank">m1eeh3errs.fsf@gmail.com>
Content-Type: text/plain
On 2021-02-25 11:28 -0500, Stefan Monnier wrote:
> Oh, I see: it's the (eval-when-compile (require 'url-parse)) because
> apparently `url-parse` now ends up loading `json` somehow.
I was trying to fix some elisp warnings in
https://github.com/erlang/otp/pull/4542 but there was failed tests:
../../../otp/lib/erlang/lib/tools-3.5/emacs/erldoc.el:534:1:Error: the following functions might not be defined at runtime: json-encode, cl-reduce, cl-mapcan
Somehow I stumbled upon a fix by moving (eval-when-compile (require
'url-parse)) to after (require 'cl-lib) to get rid of the cl-reduce,
cl-mapcan warnings in Emacs 27. But I never understand why. Any ideas?
------------------------------
Message: 17
Date: Fri, 26 Feb 2021 05:59:47 +0800
From: Leo Liu <sdl.web@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <m1a6rrerl8.fsf@gmail.com" target="_blank">m1a6rrerl8.fsf@gmail.com>
Content-Type: text/plain
On 2021-02-25 17:23 +0200, Eli Zaretskii wrote:
> I guess my crystal ball said that Leo was using the former...
> Sorry if my crystal ball is not clear enough today.
No problem at all ;)
------------------------------
Message: 18
Date: Thu, 25 Feb 2021 17:24:59 -0500
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Emacs Survey: Toolbars
Message-ID: <jwv35xjg55h.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain
>> > That makes little sense to me. Other applications that show tool bars
>> > don't make them appear and disappear, only change as appropriate for
>> > the context.
>> Which applications are you thinking of here, that would be comparable to
>> Emacs (i.e. are part music-player, part text editor, part hex editor, part
>> IRC client, ...)?
> I don't see how this is relevant. The tool bar is part of the GUI,
> which functions are shown there is immaterial.
It's relevant in the fact that some of those applications may come with
a toolbar while others don't, so a single application that provides
access too all those facilities (like Emacs) may want to sometimes show
a toolbar and sometimes not.
>> I think the solution is to have toolbars inside the window's text,
>> rather than attached to the frame.
> Is this practical? Windows can be very narrow, and change dimensions
> much more frequently in Emacs than frames. Tool bars don't live well
> with frequent changes in dimensions.
>
> If someone wants to turn tool bar off, let them do that. We don't
> need to turn the Emacs appearance upside down just because of some
> fashion: we already support that fashion.
I'm suggesting to *add* "in-buffer" toolbars (hopefully as a pure-ELisp
feature).
Stefan
------------------------------
Message: 19
Date: Thu, 25 Feb 2021 17:29:37 -0500
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Leo Liu <sdl.web@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <jwvwnuveqb8.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain
> Somehow I stumbled upon a fix by moving (eval-when-compile (require
> 'url-parse)) to after (require 'cl-lib) to get rid of the cl-reduce,
> cl-mapcan warnings in Emacs 27. But I never understand why. Any ideas?
That one's easy: the way the warning works is that when we process
a `eval-when-compile` we look at the `load-history` to see the functions
that have been defined during execution of its body, and then we remember
those as "only available now but maybe not at runtime".
If that loaded `cl-lib`, then a subsequent (require 'cl-lib) will be
a no-op and won't "unremember" the corresponding functions.
Stefan
------------------------------
Message: 20
Date: Thu, 25 Feb 2021 22:53:02 +0000
From: Jeremy Bryant <jb@jeremybryant.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rms@gnu.org, dimech@gmx.com, abrochard@gmx.com, bugs@gnu.support,
emacs-devel@gnu.org
Subject: Re: Emacs Survey: Toolbars
Message-ID: <878s7bg3ox.fsf@jeremybryant.net" target="_blank">878s7bg3ox.fsf@jeremybryant.net>
Content-Type: text/plain; charset=utf-8
In the spirit of this discussion on the merits and possibility of
planning (or not), there is an interesting quote below.
I found it useful for thinking about the special characteristics of
Emacs, and perhaps others on this list will find it interesting to
consider.
attributed (in the Free as in Freedom book)to RMS from a 1979 AI Lab memo
EMACS could not have been reached by a process of careful design, because such
processes arrive only at goals which are visible at the outset, and whose
desirability is established on the bottom line at the outset. Neither I nor
anyone else visualized an extensible editor until I had made one, nor
appreciated its value until he had experienced it. EMACS exists because I felt
free to make individually useful small improvements on a path whose end was not
in sight.
Although I couldn't locate the original source of exact quote, there is a longer piece
from the 1979 memo from RMS on the same subject.
Implications for the Process of System Design
It is generally accepted that when a program is to be written, specifications
should be designed in advance. If this is not done, the result will be inferior.
Some people know better than this, but none dare to speak up.
The writing of EMACS was as far from along these lines as can be imagined. It
is best thought of as a continuous deformation of TECO into something which,
for users, has no resemblance to TECO.
And indeed, there are ways in which EMACS shows the results of not having
been completely thought out in advance, if only in being based on TECO rather
than Lisp. (Nevertheless, EMACS has shown itself to be reliable and suitable for
widespread use). If EMACS hadTbeen specified in advance, it would resemble
the post-EMACS editors described above. However, the post-EMACS editors
were specified in advance by EMACS itself, and could not have been written if
not preceded by EMACS (this is not to say that they have copied slavishly; they
have continued the process of gradual development). And EMACS could never
have' been arrived at except in the way it actually was. The chain of necessary
steps leading to EMACS, starting with the display processor, was simply too long
for anyone to have imagined the final result before the first step had been taken.
If we had insisted on moving only toward destinations visible at the beginning,
we would never have got here from there!
This is true of all the details of the individual commands as well as of the
structure of the system. Each command in EMACS behaves as it does as a
result of experimentation by many different users customizing their editors in
£ MACS June 22, 1979
21
MIT Al Lab
different ways, in the years when the display processor existed but EMACS had
not yet been begun. This experimentation was possible only because a
programmable display editor existed. It would not have been possible to design
the EMACS standard command set without it.
Nor can one maintain the position that it was right to create EMACS this way
because it was research, but ordinary system development is a different matter.
This is because the difference between the two is also a matter of hindsight.
EMACS was not the result of an intentional "editor research project" (nor would
such a project have arrived at EMACS, because research projects aim only at
goals which are visible at the start). The display processor and command
dispatcher were seen only as an improvement to TECO; no one could have
known, when any step was taken, how much farther the path would lead. One
cannot even identify a "first" step, because the development, until the writing of
EMACS per se, blends smoothly back into the development' of TECO.
But why isn't such program of exploration doomed to be sidetracked by a blind
alley, which nobody will realize due to the lack of a planned goal? 'it is the
extensibility, and a flexibility of mind, which solves this problem: many alleys
will be tried at once, and blind alleys can be backed out of with minimal real
loss.
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Richard Stallman <rms@gnu.org>
>> Date: Mon, 21 Dec 2020 00:47:18 -0500
>> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
>>
>> > I wonder whether the survey stems from lack of vision of emacs
>> > admin and developers. For instance, Gcc has a Development Plan.
>> > Suggestions for changes to the plan are discussed on the Gcc
>> > mailing list and can be approved or rejected by the Gcc Steering
>> > Committee. How about Emacs?
>>
>> GCC has many developers who are paid by various companies.
>> That makes it easier to make plans and actually carry them out.
>
> There's another important difference. GCC implements programming
> languages defined by evolving standards that are developed by other
> bodies. The evolution of those language standards largely defines the
> GCC development plans. Other project, like GDB, Binutils, etc. have
> similar traits: they support hardware and software standards developed
> elsewhere.
>
> But Emacs is its own standard, defined by what we put into it, it
> depends very little on outside developments, and is only tangentially
> affected by those external developments. So those developments cannot
> determine our plans anywhere near to how the next C++ Standard affects
> GCC development, or the next DWARF2 version and various
> debugging-related features in the next generation of CPUs affect GDB
> development.
------------------------------
Message: 21
Date: Fri, 26 Feb 2021 08:58:04 +0800 (CST)
From: tumashu <tumashu@163.com>
To: "Eli Zaretskii" <eliz@gnu.org>
Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re:Re: [elpa] externals/pyim 1e14e7c: V3.1
Message-ID: <6fcc4384.62d.177dbd7bcbe.Coremail.tumashu@163.com" target="_blank">6fcc4384.62d.177dbd7bcbe.Coremail.tumashu@163.com>
Content-Type: text/plain; charset=GBK
At 2021-02-25 22:25:54, "Eli Zaretskii" <eliz@gnu.org> wrote:
>> Date: Thu, 25 Feb 2021 10:25:53 +0800 (CST)
>> From: tumashu <tumashu@163.com>
>> Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>,
>> "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>>
>> >I thought we agreed to have this in emacs.git.
>>
>> I have no objection, but I do not familar emacs.git, so I do not know how to do.
>
>We just add the files to the Emacs repository and update NEWS to call
>out the addition.
>
>Which files need to be added for this input method to be available to
>Emacs users?
pyim-common.el (need)
pyim-dhashcache.el (need)
pyim-dregcache.el (need)
pyim.el (need)
pyim-probe.el (need)
pyim-pymap.el (need)
.dir-locals.el the setting in this file is need, maybe have other approach.
-------------------------------------------------
README.md README for github and elpa
snapshots pyim usage screenshot.
Makefile used by travis
tests test case
.travis.yml run test case with the help of travis
------------------------------
Message: 22
Date: Fri, 26 Feb 2021 10:40:12 +0800
From: Leo Liu <sdl.web@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <m15z2feelv.fsf@gmail.com" target="_blank">m15z2feelv.fsf@gmail.com>
Content-Type: text/plain
On 2021-02-25 17:29 -0500, Stefan Monnier wrote:
> That one's easy: the way the warning works is that when we process
> a `eval-when-compile` we look at the `load-history` to see the functions
> that have been defined during execution of its body, and then we remember
> those as "only available now but maybe not at runtime".
>
> If that loaded `cl-lib`, then a subsequent (require 'cl-lib) will be
> a no-op and won't "unremember" the corresponding functions.
This sounds like nightmare :(
Is this new in Emacs 27? What prompted the change?
I think when managing dependencies I want to be able to look locally at
what I put in a elisp file and be done with it.
The new behaviour means I also need to chase dependencies and their
dependencies...
Another point is subsequent (require 'cl-lib) provides stronger
guarantee but is ignored which produces spurious warnings.
------------------------------
Message: 23
Date: Thu, 25 Feb 2021 22:54:43 -0500
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Leo Liu <sdl.web@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <jwvlfbbeb9e.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain
>> That one's easy: the way the warning works is that when we process
>> a `eval-when-compile` we look at the `load-history` to see the functions
>> that have been defined during execution of its body, and then we remember
>> those as "only available now but maybe not at runtime".
>>
>> If that loaded `cl-lib`, then a subsequent (require 'cl-lib) will be
>> a no-op and won't "unremember" the corresponding functions.
>
> This sounds like nightmare :(
>
> Is this new in Emacs 27?
No, it was new back when we added the "not known to exist at run-time",
i.e. a long time ago.
> What prompted the change?
We found it useful to try and warn the users when they did
(eval-when-compile (require FOO)) but FOO was also needed at run time.
Stefan
------------------------------
Message: 24
Date: Thu, 25 Feb 2021 23:31:14 -0500
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Mattias Engdegård <mattiase@acm.org>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, Ag Ibragimov
<agzam.ibragimov@gmail.com>, emacs-devel@gnu.org
Subject: Re: Pattern matching on match-string groups #elisp #question
Message-ID: <jwvft1jeahy.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain
>> I'd say it's a bug. The patch below would fix it. Mattias, WDYT?
> Thank you, it looks like multiple bugs. The lack of (pred stringp) was of
> course an oversight but unrelated to pcase-let, right?
Yes, it's unrelated. I just noticed it along the way.
>> (let* ((rx--pcase-vars nil)
>> (regexp (rx--to-expr (rx--pcase-transform (cons 'seq regexps)))))
>> - `(and (pred (string-match ,regexp))
>> + `(and (pred stringp)
>> + (app (lambda (s) (string-match ,regexp s)) (pred identity))
> It does seem to work, but why exactly do we need this monstrosity instead of
> (pred (string-match ,regexp))?
Good question. I'm not sure how best to explain or document it, sadly.
One of the reasons is that predicates are presumed to be (mostly) pure
functions, so `pcase` feels free to call them fewer times or more times
as it pleases.
But that also largely applies to `app`, so that's not a very
good explanation.
Maybe a better explanation is that `pcase-let` optimizes the pattern
match code under the assumption that the pattern will match, so it skips
the tests that determine whether the pattern matches or not.
[ That doesn't mean it skips all the tests: if the pattern is
(or `(a ,v) `(b ,_ ,v)) it *will* test to see if the first element is `a` in
order to decide what to bind `v` to, but it won't bother to check if
the first element is `b` since it presumes that the pattern does match
and it knows that there's no further alternative. ]
Note that this explanation is not very convincing either because it's
not clear if the test that it skipped is `(identity VAR)`
or `(identity (string-match ...))` so it's unclear whether the
`string-match` is eliminated.
> Is it because pcase-let throws away all `pred` clauses somewhere?
> It makes sense to do so but I haven't found exactly where this takes
> place in pcase.el yet...
The magic is in `pcase--if`. I.e. a lower-level than `pred`.
It's linked to the special undocumented pcase pattern `pcase--dontcare`
(whose name is not well chosen, suggestions for better names are
welcome) which is a pattern that not only can never match but also
prevents pcase from attempting to match any further patterns (IOW it
forces pcase to just go with the last branch that it failed to match).
You might also want to look at `byte-optimize--pcase` for another
example where I use this pattern.
> Perhaps the assumption that non-binding clauses like `pred` (and what else,
> `guard`?) are all side-effect free and can be thrown away in pcase-let[*]
> should be documented?
Agreed.
> Not that I would have read it, of course...
At least I'd get to point you to the doc and shame you publicly.
> I'll push a fix as soon as I understand the machinery a bit better, but
> right now I'm wary of getting my fingers snapped off by the gears
> and knives.
Come on, that's why we start with ten of those damn fingers. You surely
can still afford to risk one or two.
Stefan
------------------------------
Message: 25
Date: Fri, 26 Feb 2021 13:26:09 +0800 (CST)
From: tumashu <tumashu@163.com>
To: "Eli Zaretskii" <eliz@gnu.org>
Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re:Re: [elpa] externals/pyim 1e14e7c: V3.1
Message-ID: <30b0f73e.2c0d.177dccd2b8f.Coremail.tumashu@163.com" target="_blank">30b0f73e.2c0d.177dccd2b8f.Coremail.tumashu@163.com>
Content-Type: text/plain; charset=GBK
At 2021-02-25 22:25:54, "Eli Zaretskii" <eliz@gnu.org> wrote:
>> Date: Thu, 25 Feb 2021 10:25:53 +0800 (CST)
>> From: tumashu <tumashu@163.com>
>> Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>,
>> "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>>
>> >I thought we agreed to have this in emacs.git.
>>
>> I have no objection, but I do not familar emacs.git, so I do not know how to do.
>
>We just add the files to the Emacs repository and update NEWS to call
>out the addition.
>
>Which files need to be added for this input method to be available to
>Emacs users?
I think we have other problem to put pyim to emacs.git.
1. pyim require xr and rx, and xr is a GNU elpa package,
2. pyim support liberime, which is a melpa package.
------------------------------
Message: 26
Date: Fri, 26 Feb 2021 01:31:21 -0500
From: Richard Stallman <rms@gnu.org>
To: James Lu <jamtlu@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Requesting a paid version of Emacs
Message-ID: <E1lFWen-0007Ie-Ju@fencepost.gnu.org" target="_blank">E1lFWen-0007Ie-Ju@fencepost.gnu.org>
Content-Type: text/plain; charset=Utf-8
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Furthermore, most of the sync solutions for org-mode recommend proprietary
> Dropbox or Google Drive.
Dropbox and Google Drive are services, not programs. The distinction
of "proprietary" or "free" does not apply to them, at least not
straightforwardly. We define exactly what it means to say a program
is proprietary, but I don't know what it means to say that a service
is proprietary. Would you please explain what it is you mean in this
case?
Our moral requirement is not to recommend running any nonfree
software. It is possible -- I don't know -- that these solutions
involve running some nonfree software. If so, we should not recommend
them in Emacs or in Org mode.
Is there text in Emacs, or in Org mode, which recommends these? If
so, we should check the facts about them. Could you please show me
that text, and say precisely where it is published? With that info we
could start checking.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
------------------------------
Message: 27
Date: Fri, 26 Feb 2021 01:36:52 -0500
From: Richard Stallman <rms@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: sdl.web@gmail.com, emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <E1lFWk8-00086C-70@fencepost.gnu.org" target="_blank">E1lFWk8-00086C-70@fencepost.gnu.org>
Content-Type: text/plain; charset=Utf-8
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Oh, I see: it's the (eval-when-compile (require 'url-parse)) because
> apparently `url-parse` now ends up loading `json` somehow.
It's not a good thing for a package to load more other packages
unnecessarily. If it happens just once, it is not a big deal.
But if many libraries do it, it could lead to a cascade of bloat.
Does url-parse need json all the time, or only in rare special cases?
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
------------------------------
Message: 28
Date: Fri, 26 Feb 2021 01:39:17 -0500
From: Richard Stallman <rms@gnu.org>
To: Pip Cet <pipcet@gmail.com>
Cc: akrl@sdf.org, emacs-devel@gnu.org
Subject: Re: feature/native-comp ec88bdb 1/4: * Add a simple growable
vector like type
Message-ID: <E1lFWmT-0005Gi-3S@fencepost.gnu.org" target="_blank">E1lFWmT-0005Gi-3S@fencepost.gnu.org>
Content-Type: text/plain; charset=Utf-8
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> This simulates a vector that grows automatically, like _javascript_
> arrays do, but it's not very fast (it doesn't have to be for this
> application) and, if I understand correctly, not intended for general
> use.
That makes sense. But does it need to be an actual Lisp data type?
Could it be implemented in Lisp?
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
------------------------------
Message: 29
Date: Fri, 26 Feb 2021 08:52:10 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Emacs Survey: Toolbars
Message-ID: <83r1l3qq1x.fsf@gnu.org" target="_blank">83r1l3qq1x.fsf@gnu.org>
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org
> Date: Thu, 25 Feb 2021 17:24:59 -0500
>
> >> Which applications are you thinking of here, that would be comparable to
> >> Emacs (i.e. are part music-player, part text editor, part hex editor, part
> >> IRC client, ...)?
> > I don't see how this is relevant. The tool bar is part of the GUI,
> > which functions are shown there is immaterial.
>
> It's relevant in the fact that some of those applications may come with
> a toolbar while others don't
Which significant applications don't have a tool bar at all,
i.e. don't even have an option to display a tool bar?
> so a single application that provides access too all those
> facilities (like Emacs) may want to sometimes show a toolbar and
> sometimes not.
By what logic?
The tool bar in Emacs is very like the menu bar: it provides quick and
easy access to some frequently-used functions. Which application
doesn't have any such function to justify the lack of a tool bar?
> > If someone wants to turn tool bar off, let them do that. We don't
> > need to turn the Emacs appearance upside down just because of some
> > fashion: we already support that fashion.
>
> I'm suggesting to *add* "in-buffer" toolbars (hopefully as a pure-ELisp
> feature).
So your suggestion is to have _both_ the frame-global tool bar and
another tool bar displayed in some windows? That'd be fine with me
(we already have some modes display a header-line, which is a kind-of
tool bar, and we now have the tab-line as well, so we have similar
functionality already).
------------------------------
Message: 30
Date: Fri, 26 Feb 2021 09:43:21 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: tumashu <tumashu@163.com>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: [elpa] externals/pyim 1e14e7c: V3.1
Message-ID: <83im6fqnom.fsf@gnu.org" target="_blank">83im6fqnom.fsf@gnu.org>
> Date: Fri, 26 Feb 2021 13:26:09 +0800 (CST)
> From: tumashu <tumashu@163.com>
> Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>,
> "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>
> I think we have other problem to put pyim to emacs.git.
> 1. pyim require xr and rx, and xr is a GNU elpa package,
> 2. pyim support liberime, which is a melpa package.
That's unfortunate. Can these dependencies be removed in some way?
Also, are these dependencies needed always, or just for some features
of the pyim input method. IOW, if the user only wants to use the
input method, i.e. type "C-u C-\ pyim RET" and type the characters,
does such a user need these dependencies? If not, perhaps the
dependencies could be made optional if not removed.
And I think the dependency on MELPA is the most worrisome, as we try
not to encourage users to install packages from there, let alone force
them do it.
------------------------------
Message: 31
Date: Fri, 26 Feb 2021 09:54:28 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: rms@gnu.org
Cc: monnier@iro.umontreal.ca, sdl.web@gmail.com, emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <83eeh3qn63.fsf@gnu.org" target="_blank">83eeh3qn63.fsf@gnu.org>
> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 26 Feb 2021 01:36:52 -0500
> Cc: sdl.web@gmail.com, emacs-devel@gnu.org
>
> It's not a good thing for a package to load more other packages
> unnecessarily. If it happens just once, it is not a big deal.
> But if many libraries do it, it could lead to a cascade of bloat.
>
> Does url-parse need json all the time, or only in rare special cases?
I don't see json loaded by any file in the lisp/url directory, so it
must be some indirect load. The easiest way of finding out who loads
it would be to run Emacs under GDB with a breakpoint on Fload.
------------------------------
Message: 32
Date: Fri, 26 Feb 2021 16:40:23 +0800
From: Leo Liu <sdl.web@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <m11rd3dxxk.fsf@gmail.com" target="_blank">m11rd3dxxk.fsf@gmail.com>
Content-Type: text/plain
On 2021-02-25 22:54 -0500, Stefan Monnier wrote:
> No, it was new back when we added the "not known to exist at run-time",
> i.e. a long time ago.
But the erldoc.el has been compiling without warnings since 24.5 and it
suddenly changes in 27.
>> What prompted the change?
>
> We found it useful to try and warn the users when they did
> (eval-when-compile (require FOO)) but FOO was also needed at run time.
But it's been suggesting cl-reduce, cl-mapcan not defined at runtime
when I explicitly have (require 'cl-lib) in the file which seems
contradictory.
------------------------------
Message: 33
Date: Fri, 26 Feb 2021 09:42:54 +0100
From: Stephen Berman <stephen.berman@gmx.net>
To: emacs-devel@gnu.org
Cc: Stefan Kangas <stefan@marxist.se>
Subject: Re: emacs-27 7a23915: * lisp/tooltip.el (tooltip): Doc fix
for GTK.
Message-ID: <87wnuvb4oh.fsf@gmx.net" target="_blank">87wnuvb4oh.fsf@gmx.net>
Content-Type: text/plain
On Thu, 25 Feb 2021 23:46:54 -0500 (EST) stefankangas@gmail.com (Stefan Kangas) wrote:
> branch: emacs-27
> commit 7a23915618816ccdda03823412991e77003e3e1b
> Author: Stefan Kangas <stefan@marxist.se>
> Commit: Stefan Kangas <stefan@marxist.se>
>
> * lisp/tooltip.el (tooltip): Doc fix for GTK.
> ---
> lisp/tooltip.el | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/tooltip.el b/lisp/tooltip.el
> index 4a37e40..bb53a13 100644
> --- a/lisp/tooltip.el
> +++ b/lisp/tooltip.el
> @@ -138,7 +138,10 @@ of the `tooltip' face are used instead."
> :inherit variable-pitch)
> (t
> :inherit variable-pitch))
> - "Face for tooltips."
> + "Face for tooltips.
> +
> +When using the GTK toolkit, this face will only be used if
> +`x-gtk-use-system-tooltips' is non-nil."
> :group 'tooltip
> :group 'basic-faces)
The tooltip face is used under Gtk+ only when
`x-gtk-use-system-tooltips' is nil.
Steve Berman
------------------------------
Message: 34
Date: Fri, 26 Feb 2021 09:44:41 +0100
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas
<stefankangas@gmail.com>, emacs-devel@gnu.org
Subject: Re: Emacs Survey: Toolbars
Message-ID: <87lfbbmd52.fsf@gnus.org" target="_blank">87lfbbmd52.fsf@gnus.org>
Content-Type: text/plain
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I think the solution is to have toolbars inside the window's text,
> rather than attached to the frame.
Yeah, I think that's the way forward. Having the toolbar in the window
will allow much greater flexibility, and allow users to switch the
toolbar on in modes where it makes sense.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
------------------------------
Message: 35
Date: Fri, 26 Feb 2021 10:06:10 +0100
From: Robert Pluim <rpluim@gmail.com>
To: Richard Stallman <rms@gnu.org>
Cc: James Lu <jamtlu@gmail.com>, emacs-devel@gnu.org
Subject: Re: Requesting a paid version of Emacs
Message-ID: <87h7lz19ml.fsf@gmail.com" target="_blank">87h7lz19ml.fsf@gmail.com>
Content-Type: text/plain
>>>>> On Fri, 26 Feb 2021 01:31:21 -0500, Richard Stallman <rms@gnu.org> said:
Richard> Is there text in Emacs, or in Org mode, which recommends these? If
Richard> so, we should check the facts about them. Could you please show me
Richard> that text, and say precisely where it is published? With that info we
Richard> could start checking.
There is no text in Emacs or Org mode recommending the use of either
Dropbox or Google Drive.
Robert
--
------------------------------
Message: 36
Date: Fri, 26 Feb 2021 09:09:28 +0000
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rms@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
sdl.web@gmail.com
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <87pn0ndwl3.fsf@tcd.ie" target="_blank">87pn0ndwl3.fsf@tcd.ie>
Content-Type: text/plain
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Richard Stallman <rms@gnu.org>
>> Date: Fri, 26 Feb 2021 01:36:52 -0500
>> Cc: sdl.web@gmail.com, emacs-devel@gnu.org
>>
>> It's not a good thing for a package to load more other packages
>> unnecessarily. If it happens just once, it is not a big deal.
>> But if many libraries do it, it could lead to a cascade of bloat.
>>
>> Does url-parse need json all the time, or only in rare special cases?
>
> I don't see json loaded by any file in the lisp/url directory, so it
> must be some indirect load. The easiest way of finding out who loads
> it would be to run Emacs under GDB with a breakpoint on Fload.
url-parse.el has only three requires:
(require 'url-vars)
(require 'auth-source)
(eval-when-compile (require 'cl-lib))
auth-source.el has a known JSON backend, and indeed it loads:
(require 'json)
(require 'password-cache)
(require 'cl-lib)
(require 'eieio)
--
Basil
------------------------------
Message: 37
Date: Fri, 26 Feb 2021 10:10:25 +0100
From: Robert Pluim <rpluim@gmail.com>
To: Richard Stallman <rms@gnu.org>
Cc: Pip Cet <pipcet@gmail.com>, emacs-devel@gnu.org, akrl@sdf.org
Subject: Re: feature/native-comp ec88bdb 1/4: * Add a simple growable
vector like type
Message-ID: <87czwn19fi.fsf@gmail.com" target="_blank">87czwn19fi.fsf@gmail.com>
Content-Type: text/plain
>>>>> On Fri, 26 Feb 2021 01:39:17 -0500, Richard Stallman <rms@gnu.org> said:
Richard> [[[ To any NSA and FBI agents reading my email: please consider ]]]
Richard> [[[ whether defending the US Constitution against all enemies, ]]]
Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> This simulates a vector that grows automatically, like _javascript_
>> arrays do, but it's not very fast (it doesn't have to be for this
>> application) and, if I understand correctly, not intended for general
>> use.
Richard> That makes sense. But does it need to be an actual Lisp data type?
Richard> Could it be implemented in Lisp?
It is implemented in Lisp.
Robert
--
------------------------------
Message: 38
Date: Fri, 26 Feb 2021 09:21:01 +0000
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Leo Liu <sdl.web@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <875z2fdw1u.fsf@tcd.ie" target="_blank">875z2fdw1u.fsf@tcd.ie>
Content-Type: text/plain
Leo Liu <sdl.web@gmail.com> writes:
> On 2021-02-25 22:54 -0500, Stefan Monnier wrote:
>> No, it was new back when we added the "not known to exist at run-time",
>> i.e. a long time ago.
>
> But the erldoc.el has been compiling without warnings since 24.5 and it
> suddenly changes in 27.
>
>>> What prompted the change?
>>
>> We found it useful to try and warn the users when they did
>> (eval-when-compile (require FOO)) but FOO was also needed at run time.
>
> But it's been suggesting cl-reduce, cl-mapcan not defined at runtime
> when I explicitly have (require 'cl-lib) in the file which seems
> contradictory.
What's new in Emacs 27 is auth-source now does
(require 'cl-lib)
instead of
(eval-when-compile (require 'cl-lib))
lisp/auth-source.el: Depend on cl-lib unconditionally
90a7cd073b 2019-11-26 14:00:25 +0100
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=90a7cd073bfc7461e0bc824e9883499fe9026727
In turn, url-parse does
(require 'auth-source)
and erldoc does
(eval-when-compile (require 'url-parse))
(require 'cl-lib)
This combination seems to confuse the byte-compiler.
--
Basil
------------------------------
Message: 39
Date: Fri, 26 Feb 2021 09:33:13 +0000
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Leo Liu <sdl.web@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <87k0qvqili.fsf@tcd.ie" target="_blank">87k0qvqili.fsf@tcd.ie>
Content-Type: text/plain
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> and erldoc does
>
> (eval-when-compile (require 'url-parse))
> (require 'cl-lib)
>
> This combination seems to confuse the byte-compiler.
One solution is to transpose those lines and load cl-lib before
url-parse.
--
Basil
------------------------------
Message: 40
Date: Fri, 26 Feb 2021 11:24:48 +0100
From: Mattias Engdegård <mattiase@acm.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, Ag Ibragimov
<agzam.ibragimov@gmail.com>, emacs-devel@gnu.org
Subject: Re: Pattern matching on match-string groups #elisp #question
Message-ID: <258C930A-B183-4211-9917-0AD96C17A638@acm.org" target="_blank">258C930A-B183-4211-9917-0AD96C17A638@acm.org>
Content-Type: text/plain; charset=us-ascii
26 feb. 2021 kl. 05.31 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> Good question. I'm not sure how best to explain or document it, sadly.
> One of the reasons is that predicates are presumed to be (mostly) pure
> functions, so `pcase` feels free to call them fewer times or more times
> as it pleases.
>
> But that also largely applies to `app`, so that's not a very
> good explanation.
>
> Maybe a better explanation is that `pcase-let` optimizes the pattern
> match code under the assumption that the pattern will match, so it skips
> the tests that determine whether the pattern matches or not.
>
> [ That doesn't mean it skips all the tests: if the pattern is
> (or `(a ,v) `(b ,_ ,v)) it *will* test to see if the first element is `a` in
> order to decide what to bind `v` to, but it won't bother to check if
> the first element is `b` since it presumes that the pattern does match
> and it knows that there's no further alternative. ]
>
> Note that this explanation is not very convincing either because it's
> not clear if the test that it skipped is `(identity VAR)`
> or `(identity (string-match ...))` so it's unclear whether the
> `string-match` is eliminated.
Thank you, I think this is good enough -- I've pushed the fix (with tests, so it matters less whether I've understood it) to master. (If pcase one day gets uppity enough to optimise based on the target _expression_ as well, then a lot of tests will become meaningless.)
A clearer but less efficient pattern would be something like
(app (lambda (s) (and (string-match REGEXP s)
(list (match-string 1 s)
(match-string 2 s)
...)))
`(,VAR1 ,VAR2 ...))
which would, unless I'm mistaken, be the only way if string-match returned a match object instead of setting global match data.
Of course a sufficiently optimising compiler would eliminate the consing!
> It's linked to the special undocumented pcase pattern `pcase--dontcare`
> (whose name is not well chosen, suggestions for better names are
> welcome)
pcase--give-up
pcase--!,fail
------------------------------
Message: 41
Date: Fri, 26 Feb 2021 11:34:23 +0000
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gnu.org
Subject: Re: master 9291e73 02/12: Add new 'declare' forms for command
completion predicates
Message-ID: <87lfbb12rk.fsf@tcd.ie" target="_blank">87lfbb12rk.fsf@tcd.ie>
Content-Type: text/plain
Lars Ingebrigtsen <larsi@gnus.org> writes:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Why should explicit #'-quoting be needed for (declare (completion foo))
>> when it's not needed for any other declare form property, including the
>> new and related 'modes' property:
>>
>> (declare (modes foo))
>> (declare (gv-setter foo))
>> (declare (gv-expander foo))
>> (declare (obsolete foo ...))
>> (declare (interactive-only foo))
>> (declare (compiler-macro foo))
>> (declare (indent foo))
>>
>> How is (declare (completion ...)) any different to these?
>
> Most of those refer to symbols (or numbers), so #'-ing is irrelevant.
> But gv-setter (for one) does refer to a function, so there's precedence
> for using symbols instead of functions here indeed.
>
> Anybody else have an opinion?
It seems there were no objections, so I applied the patch.
Function-quote completion property of declare form
752278834b 2021-02-26 11:26:22 +0000
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=752278834b3d317a65135cdaa392b0468ce7372c
Thanks,
--
Basil
------------------------------
Message: 42
Date: Fri, 26 Feb 2021 11:44:45 +0000
From: Phillip Lord <phillip.lord@russet.org.uk>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gnu.org
Subject: Re: Run (some) tests more automagically?
Message-ID: <87zgzrrr2q.fsf@russet.org.uk" target="_blank">87zgzrrr2q.fsf@russet.org.uk>
Content-Type: text/plain
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>> It is supposed to do this. That was the point of moving all the tests to
>> a standard naming scheme in the first place.
>>
>> make check-maybe
>
> Oh! I had no idea; thanks.
It also seems not to be working. It picks up a missing log file and just
regenerates that, which is nice. But it doesn't seem to be picking up an
out-of-date .el dependency. I thought that it did. I will have a poke
when I can find time.
> It is very noisy; though:
>
> ----
> [hundreds of lines like this]:
> make[3]: 'src/undo-tests.log' is up to date.
> make[3]: 'src/xdisp-tests.log' is up to date.
> make[3]: 'src/xfaces-tests.log' is up to date.
> make[3]: 'src/xml-tests.log' is up to date.
> make[3]: Leaving directory '/home/larsi/src/emacs/trunk/test'
>
> SUMMARY OF TEST RESULTS
> -----------------------
> Files examined: 348
> Ran 4738 tests, 4659 results as expected, 0 unexpected, 79 skipped
> make[2]: Leaving directory '/home/larsi/src/emacs/trunk/test'
> make[1]: Leaving directory '/home/larsi/src/emacs/trunk/test'
> ----
>
> Perhaps sticking it in the admin/emake script and doing some filtering
> would be nice...
Having a target that was designed for a .git hook would seem sensible to
me. Something that we would normally expect to run in a second or two.
Phil
------------------------------
Message: 43
Date: Fri, 26 Feb 2021 12:50:08 +0100
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Phillip Lord <phillip.lord@russet.org.uk>
Cc: emacs-devel@gnu.org
Subject: Re: Run (some) tests more automagically?
Message-ID: <87pn0nkpzj.fsf@gnus.org" target="_blank">87pn0nkpzj.fsf@gnus.org>
Content-Type: text/plain
Phillip Lord <phillip.lord@russet.org.uk> writes:
> It also seems not to be working. It picks up a missing log file and just
> regenerates that, which is nice. But it doesn't seem to be picking up an
> out-of-date .el dependency. I thought that it did. I will have a poke
> when I can find time.
It seems to be working for me:
touch lisp/files.el
make check-maybe
[...]
make[3]: 'src/xfaces-tests.log' is up to date.
make[3]: 'src/xml-tests.log' is up to date.
GEN lisp/files-tests.log
make[3]: Leaving directory '/home/larsi/src/emacs/trunk/test'
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
------------------------------
Message: 44
Date: Fri, 26 Feb 2021 14:06:53 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: sdl.web@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <83a6rrqbhe.fsf@gnu.org" target="_blank">83a6rrqbhe.fsf@gnu.org>
> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Fri, 26 Feb 2021 09:33:13 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>
> > (eval-when-compile (require 'url-parse))
> > (require 'cl-lib)
> >
> > This combination seems to confuse the byte-compiler.
>
> One solution is to transpose those lines and load cl-lib before
> url-parse.
With a comment about the importance of the order, please.
------------------------------
Message: 45
Date: Fri, 26 Feb 2021 12:19:14 +0000
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: master fbc9c59: Make goto-line-history buffer local only
when so customized
Message-ID: <87wnuv3ttp.fsf@tcd.ie" target="_blank">87wnuv3ttp.fsf@tcd.ie>
Content-Type: text/plain
acm@muc.de (Alan Mackenzie) writes:
> branch: master
> commit fbc9c59b9eb02d49f426341ee32334784d224ce4
> Author: Alan Mackenzie <acm@muc.de>
> Commit: Alan Mackenzie <acm@muc.de>
>
> Make goto-line-history buffer local only when so customized
>
> * lisp/simple.el (goto-line-history-local): New customizable option.
> (goto-line-history): Define this simply with defvar, not defvar-local.
> (goto-line-read-args): Handle goto-line-history-local, and changes to it.
>
> * doc/emacs/basic.texi (Moving Point): Add a paragraph about
> goto-line-history-local.
>
> * etc/NEWS: Add an item under "Editing Changes in Emacs 28.1".
[...]
> diff --git a/etc/NEWS b/etc/NEWS
> index b96bcd9..7665d47 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -345,6 +345,11 @@ trying to be non-destructive.
> This command opens a new buffer called "*Memory Report*" and gives a
> summary of where Emacs is using memory currently.
>
> ++++
> +** The history list for the 'goto-line' command is now a single list
> +for all buffers by default. You can configure a separate list for
> +each buffer by customizing the user option 'goto-line-history-local'.
I think this contradicts a preceding entry:
** Input history for 'goto-line' is now local to every buffer.
Each buffer will keep a separate history of line numbers used with
'goto-line'. This should help making faster the process of finding
line numbers that were previously jumped to.
Thanks,
--
Basil
------------------------------
Message: 46
Date: Fri, 26 Feb 2021 13:01:46 +0000
From: Alan Mackenzie <acm@muc.de>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: emacs-devel@gnu.org
Subject: Re: master fbc9c59: Make goto-line-history buffer local only
when so customized
Message-ID: <YDjxOnQb5I9Lsf9+@ACM>
Content-Type: text/plain; charset=us-ascii
Hello, Basil.
On Fri, Feb 26, 2021 at 12:19:14 +0000, Basil L. Contovounesios wrote:
> acm@muc.de (Alan Mackenzie) writes:
> > branch: master
> > commit fbc9c59b9eb02d49f426341ee32334784d224ce4
> > Author: Alan Mackenzie <acm@muc.de>
> > Commit: Alan Mackenzie <acm@muc.de>
> > Make goto-line-history buffer local only when so customized
> > * lisp/simple.el (goto-line-history-local): New customizable option.
> > (goto-line-history): Define this simply with defvar, not defvar-local.
> > (goto-line-read-args): Handle goto-line-history-local, and changes to it.
> > * doc/emacs/basic.texi (Moving Point): Add a paragraph about
> > goto-line-history-local.
> > * etc/NEWS: Add an item under "Editing Changes in Emacs 28.1".
> [...]
> > diff --git a/etc/NEWS b/etc/NEWS
> > index b96bcd9..7665d47 100644
> > --- a/etc/NEWS
> > +++ b/etc/NEWS
> > @@ -345,6 +345,11 @@ trying to be non-destructive.
> > This command opens a new buffer called "*Memory Report*" and gives a
> > summary of where Emacs is using memory currently.
> > ++++
> > +** The history list for the 'goto-line' command is now a single list
> > +for all buffers by default. You can configure a separate list for
> > +each buffer by customizing the user option 'goto-line-history-local'.
> I think this contradicts a preceding entry:
> ** Input history for 'goto-line' is now local to every buffer.
> Each buffer will keep a separate history of line numbers used with
> 'goto-line'. This should help making faster the process of finding
> line numbers that were previously jumped to.
Well, I think "contradict" is not quite the right word. Whether the list
is buffer local or not is now customisable, which it wasn't before. The
default is somewhat arbitrary, as it always is in these things, with some
people proclaiming a particular setting "obviously" should be the
default, others saying the opposite is "obvious". That the list, before
that previous patch, wasn't buffer local points to the current default.
Or, have I misunderstood what you're saying?
> Thanks,
> --
> Basil
--
Alan Mackenzie (Nuremberg, Germany).
------------------------------
Message: 47
Date: Fri, 26 Feb 2021 13:15:02 +0000
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: master fbc9c59: Make goto-line-history buffer local only
when so customized
Message-ID: <875z2f3r8p.fsf@tcd.ie" target="_blank">875z2f3r8p.fsf@tcd.ie>
Content-Type: text/plain; charset=utf-8
Alan Mackenzie <acm@muc.de> writes:
>> > ++++
>> > +** The history list for the 'goto-line' command is now a single list
>> > +for all buffers by default. You can configure a separate list for
>> > +each buffer by customizing the user option 'goto-line-history-local'.
>
>> I think this contradicts a preceding entry:
>
>> ** Input history for 'goto-line' is now local to every buffer.
>> Each buffer will keep a separate history of line numbers used with
>> 'goto-line'. This should help making faster the process of finding
>> line numbers that were previously jumped to.
>
> Well, I think "contradict" is not quite the right word. Whether the list
> is buffer local or not is now customisable, which it wasn't before. The
> default is somewhat arbitrary, as it always is in these things, with some
> people proclaiming a particular setting "obviously" should be the
> default, others saying the opposite is "obvious". That the list, before
> that previous patch, wasn't buffer local points to the current default.
>
> Or, have I misunderstood what you're saying?
I think so. My point is that the older entry says goto-line has
buffer-local history by default, whereas the newer entry says goto-line
does not have buffer-local history by default.
The older entry came with the following change:
Make goto-line keep a separate input history per buffer
7c5d6a2afc 2019-12-24 17:40:15 +0100
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7c5d6a2afc6c23a7fff8456f506ee2aa2d37a3b9
The newer entry came with the following change:
Make goto-line-history buffer local only when so customized
fbc9c59b9e 2021-02-17 21:15:51 +0000
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=fbc9c59b9eb02d49f426341ee32334784d224ce4
The latter change reverts some parts of the former, and makes the
behaviour customisable, but the older NEWS entry was not updated to
reflect this. I was hoping you would merge the two NEWS entries or
simply delete the older one, since it no longer accurately represents
the default, and is duplicated by the newer entry.
This part of (info "(elisp) Minibuffer History") also needs updating:
-- Variable: goto-line-history
A history list for arguments to ‘goto-line’. This variable is
buffer local.
Thanks,
--
Basil
------------------------------
Message: 48
Date: Fri, 26 Feb 2021 13:36:02 +0000
From: Alan Mackenzie <acm@muc.de>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: emacs-devel@gnu.org
Subject: Re: master fbc9c59: Make goto-line-history buffer local only
when so customized
Message-ID: <YDj5QkgXuQaG11CZ@ACM>
Content-Type: text/plain; charset=utf-8
Hello, Basil.
On Fri, Feb 26, 2021 at 13:15:02 +0000, Basil L. Contovounesios wrote:
> Alan Mackenzie <acm@muc.de> writes:
> >> > ++++
> >> > +** The history list for the 'goto-line' command is now a single list
> >> > +for all buffers by default. You can configure a separate list for
> >> > +each buffer by customizing the user option 'goto-line-history-local'.
> >> I think this contradicts a preceding entry:
> >> ** Input history for 'goto-line' is now local to every buffer.
> >> Each buffer will keep a separate history of line numbers used with
> >> 'goto-line'. This should help making faster the process of finding
> >> line numbers that were previously jumped to.
> > Well, I think "contradict" is not quite the right word. Whether the list
> > is buffer local or not is now customisable, which it wasn't before. The
> > default is somewhat arbitrary, as it always is in these things, with some
> > people proclaiming a particular setting "obviously" should be the
> > default, others saying the opposite is "obvious". That the list, before
> > that previous patch, wasn't buffer local points to the current default.
> > Or, have I misunderstood what you're saying?
> I think so. My point is that the older entry says goto-line has
> buffer-local history by default, whereas the newer entry says goto-line
> does not have buffer-local history by default.
Yes, I had misunderstood, sorry. I was under the mistaken impression
that the previous change to the input history was in Emacs 27. So, yes,
you're correct, the two entries in NEWS do contradict eachother, and
need merging into a single entry.
I don't have time to do this today, I'll try and do it over the weekend.
[ .... ]
> The latter change reverts some parts of the former, and makes the
> behaviour customisable, but the older NEWS entry was not updated to
> reflect this. I was hoping you would merge the two NEWS entries or
> simply delete the older one, since it no longer accurately represents
> the default, and is duplicated by the newer entry.
> This part of (info "(elisp) Minibuffer History") also needs updating:
> -- Variable: goto-line-history
> A history list for arguments to ‘goto-line’. This variable is
> buffer local.
Hmm. OK. But what's this variable doing in the elisp manual, as
opposed to the emacs manual? It's purely a user convenience.
> Thanks,
> --
> Basil
--
Alan Mackenzie (Nuremberg, Germany).
------------------------------
Message: 49
Date: Fri, 26 Feb 2021 09:06:11 -0500
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Leo Liu <sdl.web@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Has eval-and-compile changed in emacs 27?
Message-ID: <jwvy2fbc4ew.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain
>> No, it was new back when we added the "not known to exist at run-time",
>> i.e. a long time ago.
> But the erldoc.el has been compiling without warnings since 24.5 and it
> suddenly changes in 27.
That's apparently a consequence of auth-source (`require`d by
`url-parse`) now `require`ing `json`.
>> We found it useful to try and warn the users when they did
>> (eval-when-compile (require FOO)) but FOO was also needed at run time.
> But it's been suggesting cl-reduce, cl-mapcan not defined at runtime
> when I explicitly have (require 'cl-lib) in the file which seems
> contradictory.
Yes, obviously the technique currently used doesn't always get it right.
Patches welcome ;-)
Stefan
------------------------------
Message: 50
Date: Fri, 26 Feb 2021 15:51:23 +0000
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>, Stefan Monnier
<monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas
<stefankangas@gmail.com>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: Emacs Survey: Toolbars
Message-ID:
<SA2PR10MB4474B652D979870598CD62F9F39D9@SA2PR10MB4474.namprd10.prod.outlook.com" target="_blank">SA2PR10MB4474B652D979870598CD62F9F39D9@SA2PR10MB4474.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
> > I think the solution is to have toolbars inside the window's text,
> > rather than attached to the frame.
>
> Yeah, I think that's the way forward. Having the toolbar in the window
> will allow much greater flexibility, and allow users to switch the
> toolbar on in modes where it makes sense.
By "inside the window's text" do you mean anywhere
within it, so for example a user could move it
around within that space? Or do you mean something
more like what Eli suggested - perhaps handled like
a header-line is handled?
In what you imagine, would more than one such tool
bar be possible within the window's text area?
I guess my overall request here is whether you can
perhaps flesh out more of what you (plural) have
in mind.
------------------------------
Message: 51
Date: Fri, 26 Feb 2021 11:27:20 -0500
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Drew Adams <drew.adams@oracle.com>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>,
Stefan Kangas <stefankangas@gmail.com>, "emacs-devel@gnu.org"
<emacs-devel@gnu.org>
Subject: Re: [External] : Re: Emacs Survey: Toolbars
Message-ID: <jwvv9aebxuc.fsf-monnier+emacs@gnu.org>
Content-Type: text/plain
> By "inside the window's text" do you mean anywhere
> within it, so for example a user could move it
I don't know what other people mean, but what I'm thinking of is
reflected in the chunk of code below I started writing some years ago.
You can `insert` the result into the buffer to put a toolbar wherever
you want (don't expect miracles: it has loads of shortcomings).
Stefan
(defun tool-bar-to-string (&optional map)
(let ((res ""))
(map-keymap
(lambda (k v)
(when (eq (car v) 'menu-item)
(let* ((name (nth 1 v)) ;Unused, AFAICT.
(cmd (nth 2 v))
(plist (nthcdr (if (consp (nth 3 v)) 4 3) v))
(help-echo (plist-get plist :help))
(image (plist-get plist :image))
(button (propertize " " 'help-echo help-echo
'keymap (let ((map (make-sparse-keymap)))
(define-key map [mouse-1] cmd)
map)
'face 'tool-bar ;; 'custom-button
'mouse-face 'custom-button-mouse
'rear-nonsticky '(display keymap help-echo)
'display image)))
(setq res (concat res (propertize " " 'display '(space :width 1)
'face 'custom-button
)
button)))))
(or map (key-binding [tool-bar])))
res))
------------------------------
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 204, Issue 28
********************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |