* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
@ 2013-02-28 17:01 Drew Adams
2014-02-10 7:31 ` Lars Ingebrigtsen
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2013-02-28 17:01 UTC (permalink / raw)
To: 13841
emacs -Q
C-h k
Then choose menu item Options > Line Wrapping in This Buffer > Truncate
Long Lines.
You see binary output instead of useful help:
<menu-bar> <options> <line-wrapping> <truncate> runs the command #[nil
"ILLEGIBLE, INCOMPREHENSIBLE BINARY INCANTATIONS" [visual-line-mode
word-wrap 0 nil toggle-truncate-lines 1] 2 nil nil], which is an
interactive compiled Lisp function.
It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
(anonymous)
Not documented.
For reference wrt this regression, this is what Emacs 23.4 shows
instead - much more readable and helpful:
<menu-bar> <options> <line-wrapping> <truncate> runs the command
(lambda nil (interactive) (if visual-line-mode (visual-line-mode 0))
(setq word-wrap nil) (toggle-truncate-lines 1)), which is an
interactive Lisp function.
It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
(anonymous)
Not documented.
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-02-25 on ODIEONE
Bzr revision: 111879 yamaoka@jpl.org-20130225224731-cv9gznq5nqf3ei7g
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2013-02-28 17:01 bug#13841: 24.3.50; Regression - unreadable `C-h k' help Drew Adams
@ 2014-02-10 7:31 ` Lars Ingebrigtsen
2016-04-28 22:37 ` Lars Ingebrigtsen
0 siblings, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-10 7:31 UTC (permalink / raw)
To: Drew Adams; +Cc: 13841
"Drew Adams" <drew.adams@oracle.com> writes:
> C-h k
>
> Then choose menu item Options > Line Wrapping in This Buffer > Truncate
> Long Lines.
>
> You see binary output instead of useful help:
>
> <menu-bar> <options> <line-wrapping> <truncate> runs the command #[nil
> "ILLEGIBLE, INCOMPREHENSIBLE BINARY INCANTATIONS" [visual-line-mode
> word-wrap 0 nil toggle-truncate-lines 1] 2 nil nil], which is an
> interactive compiled Lisp function.
>
> It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
>
> (anonymous)
>
> Not documented.
>
> For reference wrt this regression, this is what Emacs 23.4 shows
> instead - much more readable and helpful:
>
> <menu-bar> <options> <line-wrapping> <truncate> runs the command
> (lambda nil (interactive) (if visual-line-mode (visual-line-mode 0))
> (setq word-wrap nil) (toggle-truncate-lines 1)), which is an
> interactive Lisp function.
>
> It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
Perhaps that's just because it didn't byte-compile the function? So
we're making progress.
Anyway, if we put lambdas into menus, `C-h k' isn't very helpful:
(bindings--define-key menu [truncate]
`(menu-item "Truncate Long Lines"
,(lambda ()
(interactive)
(if visual-line-mode (visual-line-mode 0))
(setq word-wrap nil)
(toggle-truncate-lines 1))
:help "Truncate long lines at window edge"
:button (:radio . (or truncate-lines
(truncated-partial-width-window-p)))
:visible (menu-bar-menu-frame-live-and-visible-p)
:enable (not (truncated-partial-width-window-p))))
I think the right solution here would be for `C-h k' just to say that
it's an anonymous function and leave it at that.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2014-02-10 7:31 ` Lars Ingebrigtsen
@ 2016-04-28 22:37 ` Lars Ingebrigtsen
2016-04-29 16:22 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2016-04-28 22:37 UTC (permalink / raw)
To: Drew Adams; +Cc: 13841
Lars Ingebrigtsen <larsi@gnus.org> writes:
> I think the right solution here would be for `C-h k' just to say that
> it's an anonymous function and leave it at that.
Or perhaps it should just do this with byte-compiled functions.
Anyway, here's a test case:
(key-binding [(menu-bar) options line-wrapping word-wrap] t)
=>
#[nil "\b\204\b\300\301!\210\302\303!\207" [visual-line-mode 1 message "Visual-Line mode enabled"] 2 nil nil]
The binary bit, at least, is probably not something we want to show to
the user. But the rest? It might help with chasing down code, which is
what I often use `C-h k' for...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-04-28 22:37 ` Lars Ingebrigtsen
@ 2016-04-29 16:22 ` Drew Adams
2016-04-30 11:46 ` Michael Heerdegen
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Drew Adams @ 2016-04-29 16:22 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 13841
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > I think the right solution here would be for `C-h k' just to say that
> > it's an anonymous function and leave it at that.
>
> Or perhaps it should just do this with byte-compiled functions.
> Anyway, here's a test case:
[...]
> The binary bit, at least, is probably not something we want to show to
> the user. But the rest? It might help with chasing down code, which is
> what I often use `C-h k' for...
This is a REGRESSION. With Emacs 23.4, emacs -Q C-h k, same
recipe, you see this:
<menu-bar> <options> <line-wrapping> <truncate> runs the command
(lambda nil (interactive) (if visual-line-mode (visual-line-mode 0))
(setq word-wrap nil) (toggle-truncate-lines 1)), which is an
interactive Lisp function.
It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
(anonymous)
Not documented.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-04-29 16:22 ` Drew Adams
@ 2016-04-30 11:46 ` Michael Heerdegen
2016-04-30 15:37 ` Drew Adams
[not found] ` <<87inyze2tq.fsf@web.de>
[not found] ` <<<87inyze2tq.fsf@web.de>
2 siblings, 1 reply; 17+ messages in thread
From: Michael Heerdegen @ 2016-04-30 11:46 UTC (permalink / raw)
To: Drew Adams; +Cc: Lars Ingebrigtsen, 13841
Drew Adams <drew.adams@oracle.com> writes:
> This is a REGRESSION. With Emacs 23.4, emacs -Q C-h k, same
> recipe, you see this:
The difference to newer Emacsen is that this menu command had been a
quoted lambda in Emacs 23 (that didn't get compiled), and has been
unquoted since then (good!). So I guess it's not a regression since
23.4.
Michael.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-04-30 11:46 ` Michael Heerdegen
@ 2016-04-30 15:37 ` Drew Adams
2016-04-30 15:52 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2016-04-30 15:37 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Lars Ingebrigtsen, 13841
> > This is a REGRESSION. With Emacs 23.4, emacs -Q C-h k, same
> > recipe, you see this:
>
> The difference to newer Emacsen is that this menu command had been a
> quoted lambda in Emacs 23 (that didn't get compiled), and has been
> unquoted since then (good!). So I guess it's not a regression since
> 23.4.
Not sure what you're saying about when or whether a regression
was introduced.
In fact, this is a regression that was introduced in Emacs 24.3
(probably you meant that, not 23.4). In 24.2 and prior there
was no such problem.
Sure, it is a good thing in general that code gets byte-compiled.
That doesn't mean that everything is better, and this is one
downside to simply replacing (in effect) source code with byte
code.
A big advantage of Emacs and its use of Lisp is seeing into
and manipulating, at runtime, the programs that underlie the
behavior. Simply replacing (in effect) source code with byte
code works against that introspection (whether by people or
by program).
If byte-compiling is going to be done in such an automatic,
blanket way, then perhaps a pointer needs to be kept to the
source code, for uses such as this.
In this particular case, at least, showing users byte code
is not helpful. I hope we can all agree on that, at least.
And in this particular case, at least, a simple fix should
be to use a named function and not an anonymous one (in
`menu-bar-line-wrapping-menu').
But a more general solution should be sought to the various
problems introduced by the aggressive/eager byte-compiling
that is the underlying cause of this regression.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-04-30 15:37 ` Drew Adams
@ 2016-04-30 15:52 ` Eli Zaretskii
2016-05-01 13:50 ` Michael Heerdegen
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2016-04-30 15:52 UTC (permalink / raw)
To: Drew Adams; +Cc: michael_heerdegen, larsi, 13841
> Date: Sat, 30 Apr 2016 07:37:50 -0800 (GMT-08:00)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 13841@debbugs.gnu.org
>
> > > This is a REGRESSION. With Emacs 23.4, emacs -Q C-h k, same
> > > recipe, you see this:
> >
> > The difference to newer Emacsen is that this menu command had been a
> > quoted lambda in Emacs 23 (that didn't get compiled), and has been
> > unquoted since then (good!). So I guess it's not a regression since
> > 23.4.
>
> Not sure what you're saying about when or whether a regression
> was introduced.
>
> In fact, this is a regression that was introduced in Emacs 24.3
> (probably you meant that, not 23.4). In 24.2 and prior there
> was no such problem.
Of course, there was a problem! Showing users a bunch of convoluted
Lisp when they ask what a key does is plain usability bug! It doesn't
matter whether that Lisp is compiled or not, it's no way of _helping_
the user understand what the function does.
If you don't mind the Lisp form, you shouldn't mind the byte-compiled
form, either. And if you cannot read bytecode, you can disassemble
it, then it should be as crystal-clear to you as the Emacs 23 vintage
result.
> And in this particular case, at least, a simple fix should
> be to use a named function and not an anonymous one (in
> `menu-bar-line-wrapping-menu').
Indeed. And in any other case like this.
So let's stop talking about "regressions", and start talking about the
real problem here. Which also suggests an easy solution.
> But a more general solution should be sought to the various
> problems introduced by the aggressive/eager byte-compiling
> that is the underlying cause of this regression.
A more general solution is not to have lambda functions hang on keys
and mouse clicks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
[not found] ` <<83wpnfnlf1.fsf@gnu.org>
@ 2016-04-30 17:20 ` Drew Adams
2016-04-30 17:29 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2016-04-30 17:20 UTC (permalink / raw)
To: Eli Zaretskii, Drew Adams; +Cc: michael_heerdegen, larsi, 13841
> If you don't mind the Lisp form, you shouldn't mind the byte-compiled
> form, either.
Excuse me, but this is sheer nonsense. I find it really
hard to believe that you are saying such a thing, Eli.
You who care so much about reasonably understandable
messages and doc for users.
Emacs users often (perhaps usually) read straightforward
Lisp code. They do not read byte-code (except for rare
exceptions - perhaps).
Source code is intended to be read by humans. Compiled
code, not so much.
> And if you cannot read bytecode, you can disassemble
> it, then it should be as crystal-clear to you as the Emacs 23 vintage
> result.
Wunderbar. That's what you want to offer users, as
opposed to fixing this bug. Just tell them, when they
see gibberish from `C-h f' that this is no bug but Emacs
doing everything it can to help them. ALL THEY NEED TO DO,
to decipher the gibberish, is to disassemble it.
Sheesh. Really hard to believe this.
> > And in this particular case, at least, a simple fix should
> > be to use a named function and not an anonymous one (in
> > `menu-bar-line-wrapping-menu').
>
> Indeed. And in any other case like this.
>
> So let's stop talking about "regressions", and start talking about the
> real problem here. Which also suggests an easy solution.
Well, it is a regression. But if you don't want to talk
about it, then don't(!) - please just fix it.
> > But a more general solution should be sought to the various
> > problems introduced by the aggressive/eager byte-compiling
> > that is the underlying cause of this regression.
>
> A more general solution is not to have lambda functions hang on keys
> and mouse clicks.
That's not a more general solution to aggressive/eager
byte-compiling. That's the same "easy solution" that we
should apply to fixing this regression. But that's all
we need, to close this particular bug.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-04-30 17:20 ` Drew Adams
@ 2016-04-30 17:29 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2016-04-30 17:29 UTC (permalink / raw)
To: Drew Adams; +Cc: michael_heerdegen, larsi, 13841
> Date: Sat, 30 Apr 2016 09:20:38 -0800 (GMT-08:00)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael_heerdegen@web.de, larsi@gnus.org, 13841@debbugs.gnu.org
>
> > If you don't mind the Lisp form, you shouldn't mind the byte-compiled
> > form, either.
>
> Excuse me, but this is sheer nonsense. I find it really
> hard to believe that you are saying such a thing, Eli.
> You who care so much about reasonably understandable
> messages and doc for users.
Lisp code is not documentation. I find it really hard to believe you
are saying such a thing, after filing so many bug reports about
unclear and unusable documentation.
> Emacs users often (perhaps usually) read straightforward
> Lisp code. They do not read byte-code (except for rare
> exceptions - perhaps).
They should read neither as documentation.
> Source code is intended to be read by humans. Compiled
> code, not so much.
But neither is documentation.
> > And if you cannot read bytecode, you can disassemble
> > it, then it should be as crystal-clear to you as the Emacs 23 vintage
> > result.
>
> Wunderbar. That's what you want to offer users, as
> opposed to fixing this bug.
No, I'm saying that we should not show code as documentation.
> > A more general solution is not to have lambda functions hang on keys
> > and mouse clicks.
>
> That's not a more general solution to aggressive/eager
> byte-compiling.
Yes, it is. If no code is show as documentation, aggressive/eager
byte-compiling will hurt no one.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
[not found] ` <<83inyzngx7.fsf@gnu.org>
@ 2016-04-30 18:14 ` Drew Adams
0 siblings, 0 replies; 17+ messages in thread
From: Drew Adams @ 2016-04-30 18:14 UTC (permalink / raw)
To: Eli Zaretskii, Drew Adams; +Cc: michael_heerdegen, larsi, 13841
I agree that user help should show documentation, not just
Lisp code. But certainly - far more important - not byte code.
The fix for this bug (and any that are similar) is to
use a named function with a doc string. I think (hope)
we agree about that.
(We can disagree that if a user can read Lisp source code
then s?he should be able to also read byte code, or she
is just as likely to be able to do that.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-04-30 15:52 ` Eli Zaretskii
@ 2016-05-01 13:50 ` Michael Heerdegen
2016-05-01 15:09 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Michael Heerdegen @ 2016-05-01 13:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 13841
Eli Zaretskii <eliz@gnu.org> writes:
> A more general solution is not to have lambda functions hang on keys
> and mouse clicks.
Or just give the lambda a docstring.
Michael.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-05-01 13:50 ` Michael Heerdegen
@ 2016-05-01 15:09 ` Eli Zaretskii
2016-05-01 15:13 ` Lars Ingebrigtsen
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2016-05-01 15:09 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: larsi, 13841
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Drew Adams <drew.adams@oracle.com>, larsi@gnus.org, 13841@debbugs.gnu.org
> Date: Sun, 01 May 2016 15:50:45 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > A more general solution is not to have lambda functions hang on keys
> > and mouse clicks.
>
> Or just give the lambda a docstring.
No, I think we should forbid using a lambda as a user-visible key
binding.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-05-01 15:09 ` Eli Zaretskii
@ 2016-05-01 15:13 ` Lars Ingebrigtsen
2016-05-01 15:43 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2016-05-01 15:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Michael Heerdegen, 13841
Eli Zaretskii <eliz@gnu.org> writes:
> No, I think we should forbid using a lambda as a user-visible key
> binding.
I think we should avoid doing so in the code in Emacs (we already avoid
using lambdas as function definitions for normal keystrokes, but it's
present in some menus), but I don't think we should make that invalid in
general. I think it's fine for a user to define menus (or keystrokes)
"sloppily" for private use.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-05-01 15:13 ` Lars Ingebrigtsen
@ 2016-05-01 15:43 ` Eli Zaretskii
2019-10-09 3:28 ` bug#20157: " Lars Ingebrigtsen
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2016-05-01 15:43 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: michael_heerdegen, 13841
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, drew.adams@oracle.com, 13841@debbugs.gnu.org
> Date: Sun, 01 May 2016 17:13:33 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > No, I think we should forbid using a lambda as a user-visible key
> > binding.
>
> I think we should avoid doing so in the code in Emacs
That's what I meant, yes.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#20157: bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2016-05-01 15:43 ` Eli Zaretskii
@ 2019-10-09 3:28 ` Lars Ingebrigtsen
2019-10-09 10:57 ` Michael Heerdegen
0 siblings, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-09 3:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, 13841, 20157
Eli Zaretskii <eliz@gnu.org> writes:
>> > No, I think we should forbid using a lambda as a user-visible key
>> > binding.
>>
>> I think we should avoid doing so in the code in Emacs
>
> That's what I meant, yes.
I have now fixed this in menu-bar.el for the original reported case (and
the ones in nearby menus). There may be more lurking other places, but
we can fix those if somebody reports them, I guess.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2019-10-09 3:28 ` bug#20157: " Lars Ingebrigtsen
@ 2019-10-09 10:57 ` Michael Heerdegen
2019-10-09 18:57 ` Lars Ingebrigtsen
0 siblings, 1 reply; 17+ messages in thread
From: Michael Heerdegen @ 2019-10-09 10:57 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 20157, 13841
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
Lars Ingebrigtsen <larsi@gnus.org> writes:
> I have now fixed this in menu-bar.el for the original reported case (and
> the ones in nearby menus). There may be more lurking other places, but
> we can fix those if somebody reports them, I guess.
Thanks.
I don't recall: did we want to fix only compiled lambdas, or any
anonymous functions (including quoted lambdas)?
Attached a quick rough search for candidates (search for "-->") - is any
of them problematic?
Regards,
Michael.
[-- Attachment #2: menu-bar-lambdas.el --]
[-- Type: application/emacs-lisp, Size: 33109 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13841: 24.3.50; Regression - unreadable `C-h k' help
2019-10-09 10:57 ` Michael Heerdegen
@ 2019-10-09 18:57 ` Lars Ingebrigtsen
0 siblings, 0 replies; 17+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-09 18:57 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 20157, 13841
Michael Heerdegen <michael_heerdegen@web.de> writes:
> I don't recall: did we want to fix only compiled lambdas, or any
> anonymous functions (including quoted lambdas)?
All key bindings (including menu ones) should be to named functions, I
think. That allows inspection via `C-h k' and the user can jump to the
function definition to see what it does.
> Attached a quick rough search for candidates (search for "-->") - is any
> of them problematic?
All of them should be changed, I think, although the
tab-bar-make-keymap-1 looks a bit difficult to deal with.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-10-09 18:57 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-28 17:01 bug#13841: 24.3.50; Regression - unreadable `C-h k' help Drew Adams
2014-02-10 7:31 ` Lars Ingebrigtsen
2016-04-28 22:37 ` Lars Ingebrigtsen
2016-04-29 16:22 ` Drew Adams
2016-04-30 11:46 ` Michael Heerdegen
2016-04-30 15:37 ` Drew Adams
2016-04-30 15:52 ` Eli Zaretskii
2016-05-01 13:50 ` Michael Heerdegen
2016-05-01 15:09 ` Eli Zaretskii
2016-05-01 15:13 ` Lars Ingebrigtsen
2016-05-01 15:43 ` Eli Zaretskii
2019-10-09 3:28 ` bug#20157: " Lars Ingebrigtsen
2019-10-09 10:57 ` Michael Heerdegen
2019-10-09 18:57 ` Lars Ingebrigtsen
[not found] ` <<87inyze2tq.fsf@web.de>
[not found] ` <<4e02c2a0-6e68-4091-a64d-131bcfc2fc49@default>
[not found] ` <<83wpnfnlf1.fsf@gnu.org>
2016-04-30 17:20 ` Drew Adams
2016-04-30 17:29 ` Eli Zaretskii
[not found] ` <<<87inyze2tq.fsf@web.de>
[not found] ` <<<4e02c2a0-6e68-4091-a64d-131bcfc2fc49@default>
[not found] ` <<<83wpnfnlf1.fsf@gnu.org>
[not found] ` <<f6490f90-dac1-4e7f-bb98-34877820dcb6@default>
[not found] ` <<83inyzngx7.fsf@gnu.org>
2016-04-30 18:14 ` Drew Adams
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).