* Re: Emacs-devel Digest, Vol 204, Issue 28
[not found] <mailman.35.1614358824.18242.emacs-devel@gnu.org>
@ 2021-02-27 7:48 ` Pedro Andres Aranda Gutierrez
2021-02-27 7:58 ` Eli Zaretskii
2021-02-28 6:17 ` Richard Stallman
0 siblings, 2 replies; 9+ messages in thread
From: Pedro Andres Aranda Gutierrez @ 2021-02-27 7:48 UTC (permalink / raw)
To: emacs-devel; +Cc: stefankangas, Juri Linkov
[-- Attachment #1: Type: text/plain, Size: 83617 bytes --]
>> + 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
>n Lisp. Eli already fixed this mistake immediately.
>
>BTW, what do you think about such purely cosmetic patch?
>Are there any aesthetic objections?
Hi,
I've been recently working with people with diverse abilities and enormous
programming skills and guess what... most love programming 'languages with
braces' over pure identantion stuff, because they help them knowing in
which context they are. So, those braces may be 'superfluous' from the
language point of view but they don't harm the code and favour
inclusiveness ;-)
Just my.02 cents
/PA
On Fri, 26 Feb 2021 at 18:21, <emacs-devel-request@gnu.org> wrote:
> 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>
>
> > 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>
>
> > 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>
> 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>
> 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>
>
> > 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
> >
>
> 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>
>
> > 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
> >
>
> 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>
> 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>
> 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>
> 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>
> 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>
>
> > 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
>
> > 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>
>
> > 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>
>
> > 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
> 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>
>
> > 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>
> 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>
> 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
> >
>
> 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
> ********************************************
>
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
[-- Attachment #2: Type: text/html, Size: 118550 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs-devel Digest, Vol 204, Issue 28
2021-02-27 7:48 ` Emacs-devel Digest, Vol 204, Issue 28 Pedro Andres Aranda Gutierrez
@ 2021-02-27 7:58 ` Eli Zaretskii
2021-02-27 11:34 ` Pedro Andres Aranda Gutierrez
2021-02-27 14:50 ` Stefan Monnier
2021-02-28 6:17 ` Richard Stallman
1 sibling, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2021-02-27 7:58 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: juri, stefankangas, emacs-devel
> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Sat, 27 Feb 2021 08:48:30 +0100
> Cc: stefankangas@gmail.com, Juri Linkov <juri@linkov.net>
>
> I've been recently working with people with diverse abilities and enormous programming skills and guess
> what... most love programming 'languages with braces' over pure identantion stuff, because they help them
> knowing in which context they are. So, those braces may be 'superfluous' from the language point of view
> but they don't harm the code and favour inclusiveness ;-)
I removed those braces because they are against our coding style, not
because of my personal preferences.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs-devel Digest, Vol 204, Issue 28
2021-02-27 7:58 ` Eli Zaretskii
@ 2021-02-27 11:34 ` Pedro Andres Aranda Gutierrez
2021-02-27 14:50 ` Stefan Monnier
1 sibling, 0 replies; 9+ messages in thread
From: Pedro Andres Aranda Gutierrez @ 2021-02-27 11:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Juri Linkov, stefankangas, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
Hi Eli,
I know, I'm not blaming anyone :-) Just saying that they are sometimes that
little push some people may need to get involved. I can assure you that we
are loosing talent...
Time to revise coding style?
My .02cents/PA
On Sat, 27 Feb 2021 at 08:58, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> > Date: Sat, 27 Feb 2021 08:48:30 +0100
> > Cc: stefankangas@gmail.com, Juri Linkov <juri@linkov.net>
> >
> > I've been recently working with people with diverse abilities and
> enormous programming skills and guess
> > what... most love programming 'languages with braces' over pure
> identantion stuff, because they help them
> > knowing in which context they are. So, those braces may be 'superfluous'
> from the language point of view
> > but they don't harm the code and favour inclusiveness ;-)
>
> I removed those braces because they are against our coding style, not
> because of my personal preferences.
>
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
[-- Attachment #2: Type: text/html, Size: 1866 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs-devel Digest, Vol 204, Issue 28
2021-02-27 7:58 ` Eli Zaretskii
2021-02-27 11:34 ` Pedro Andres Aranda Gutierrez
@ 2021-02-27 14:50 ` Stefan Monnier
2021-02-27 14:59 ` Eli Zaretskii
1 sibling, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2021-02-27 14:50 UTC (permalink / raw)
To: Eli Zaretskii
Cc: emacs-devel, stefankangas, Pedro Andres Aranda Gutierrez, juri
>> knowing in which context they are. So, those braces may be
>> 'superfluous' from the language point of view but they don't harm the
>> code and favour inclusiveness ;-)
That's indeed a good point, thanks.
> I removed those braces because they are against our coding style, not
> because of my personal preferences.
Looks like I need to go re-read our coding style ;-)
I mean, I know that we don't need those braces here and I don't put them
in the code I write (because they make my code too sparse for my taste),
but I didn't know our style was *against* their presence (rather than
merely allowing or even recommending their absence).
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs-devel Digest, Vol 204, Issue 28
2021-02-27 14:50 ` Stefan Monnier
@ 2021-02-27 14:59 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2021-02-27 14:59 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, stefankangas, paaguti, juri
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>, juri@linkov.net,
> stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Sat, 27 Feb 2021 09:50:39 -0500
>
> > I removed those braces because they are against our coding style, not
> > because of my personal preferences.
>
> Looks like I need to go re-read our coding style ;-)
> I mean, I know that we don't need those braces here and I don't put them
> in the code I write (because they make my code too sparse for my taste),
> but I didn't know our style was *against* their presence (rather than
> merely allowing or even recommending their absence).
See standards.info, node "Formatting".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: Emacs-devel Digest, Vol 204, Issue 28
2021-02-27 7:48 ` Emacs-devel Digest, Vol 204, Issue 28 Pedro Andres Aranda Gutierrez
2021-02-27 7:58 ` Eli Zaretskii
@ 2021-02-28 6:17 ` Richard Stallman
2021-03-01 6:04 ` David Masterson
1 sibling, 1 reply; 9+ messages in thread
From: Richard Stallman @ 2021-02-28 6:17 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez; +Cc: juri, stefankangas, emacs-devel
[[[ 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. ]]]
The reason we don't use braces in cases like this
if (use_short_answers)
{
return call1 (intern ("y-or-n-p"), prompt);
}
is that the braces cause fewer real lines of code to fit on the
screen. Because of that, they are not merely superfluous, they are an
impediment to reading the code.
--
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs-devel Digest, Vol 204, Issue 28
2021-02-28 6:17 ` Richard Stallman
@ 2021-03-01 6:04 ` David Masterson
2021-03-02 13:11 ` Pedro Andres Aranda Gutierrez
0 siblings, 1 reply; 9+ messages in thread
From: David Masterson @ 2021-03-01 6:04 UTC (permalink / raw)
To: Richard Stallman
Cc: emacs-devel, stefankangas, Pedro Andres Aranda Gutierrez, juri
Richard Stallman <rms@gnu.org> writes:
> [[[ 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. ]]]
>
> The reason we don't use braces in cases like this
>
> if (use_short_answers)
> {
> return call1 (intern ("y-or-n-p"), prompt);
> }
>
> is that the braces cause fewer real lines of code to fit on the
> screen. Because of that, they are not merely superfluous, they are an
> impediment to reading the code.
Different people look at it... differently. It probably depends on how
you were taught. I was taught C coding with the above style and my eye
is used to seeing the code structure this way. Remove the braces above
and it gets a little harder for me when you have a chain of these
if-thens.
--
David Masterson
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs-devel Digest, Vol 204, Issue 28
2021-03-01 6:04 ` David Masterson
@ 2021-03-02 13:11 ` Pedro Andres Aranda Gutierrez
2021-03-03 5:57 ` Richard Stallman
0 siblings, 1 reply; 9+ messages in thread
From: Pedro Andres Aranda Gutierrez @ 2021-03-02 13:11 UTC (permalink / raw)
To: David Masterson; +Cc: emacs-devel, stefankangas, Richard Stallman, juri
Hi Richard
I was talking about visually impaired people who use tts and, frankly speaking, a brace stands out much more than an indentation. The feedback I have is explicit braces are helpful for them when reading through the code.
Just my.02 cents,/PA
Enviado desde mi iPhone
> El 1 mar 2021, a las 7:04, David Masterson <dsmasterson92630@outlook.com> escribió:
>
> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ 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. ]]]
>>
>> The reason we don't use braces in cases like this
>>
>> if (use_short_answers)
>> {
>> return call1 (intern ("y-or-n-p"), prompt);
>> }
>>
>> is that the braces cause fewer real lines of code to fit on the
>> screen. Because of that, they are not merely superfluous, they are an
>> impediment to reading the code.
>
> Different people look at it... differently. It probably depends on how
> you were taught. I was taught C coding with the above style and my eye
> is used to seeing the code structure this way. Remove the braces above
> and it gets a little harder for me when you have a chain of these
> if-thens.
>
> --
> David Masterson
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Emacs-devel Digest, Vol 204, Issue 28
2021-03-02 13:11 ` Pedro Andres Aranda Gutierrez
@ 2021-03-03 5:57 ` Richard Stallman
0 siblings, 0 replies; 9+ messages in thread
From: Richard Stallman @ 2021-03-03 5:57 UTC (permalink / raw)
To: Pedro Andres Aranda Gutierrez
Cc: emacs-devel, stefankangas, dsmasterson92630, juri
[[[ 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. ]]]
> I was talking about visually impaired people who use tts and,
> frankly speaking, a brace stands out much more than an
> indentation. The feedback I have is explicit braces are helpful
> for them when reading through the code.
To put braces around every one-line conditional body would have
advantages and disadvantages. I think the disadvantages would
outweigh the advantages, so we should stick with the current coding
conventions.
--
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-03-03 5:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.35.1614358824.18242.emacs-devel@gnu.org>
2021-02-27 7:48 ` Emacs-devel Digest, Vol 204, Issue 28 Pedro Andres Aranda Gutierrez
2021-02-27 7:58 ` Eli Zaretskii
2021-02-27 11:34 ` Pedro Andres Aranda Gutierrez
2021-02-27 14:50 ` Stefan Monnier
2021-02-27 14:59 ` Eli Zaretskii
2021-02-28 6:17 ` Richard Stallman
2021-03-01 6:04 ` David Masterson
2021-03-02 13:11 ` Pedro Andres Aranda Gutierrez
2021-03-03 5:57 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).