bug#38818: Dired: mention deleting buffers, not just windows

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

At (info "(emacs) Dired Enter")

   Typing ‘q’ (‘quit-window’) buries the Dired buffer, and deletes its
   window if the window was created just for that buffer.

Add:

  To delete the buffer instead of just burying it, type "1 q".

  To make deleting the buffer the default instead of burying it, use
  (setq ... ...)

  Users might find this helps keeping their buffer-list free of old
  dired buffers crowding.

emacs-version "26.3"

bug#38818: Dired: mention deleting buffers, not just windows

[martin rudalics]

 > At (info "(emacs) Dired Enter")
 >
 >     Typing ‘q’ (‘quit-window’) buries the Dired buffer, and deletes its
 >     window if the window was created just for that buffer.
 >
 > Add:
 >
 >    To delete the buffer instead of just burying it, type "1 q".

We can add that typing "q" with a prefix argument will kill the
buffer, but I'm afraid we have no facility supplying ...

 >    To make deleting the buffer the default instead of burying it, use
 >    (setq ... ...)

... that.

 >    Users might find this helps keeping their buffer-list free of old
 >    dired buffers crowding.

martin

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

>>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:
>> At (info "(emacs) Dired Enter")
>> 
>> Typing ‘q’ (‘quit-window’) buries the Dired buffer, and deletes its
>> window if the window was created just for that buffer.
>> 
>> Add:
>> 
>> To delete the buffer instead of just burying it, type "1 q".

mr> We can add that typing "q" with a prefix argument will kill the
mr> buffer,

Yes please do. As in (info "(elisp) Quitting Windows"). Which you might
as well add a link to...

mr> but I'm afraid we have no facility supplying ...

>> To make deleting the buffer the default instead of burying it, use
>> (setq ... ...)

mr> ... that.

OK, but there really should be a way. Else heavy dired users commonly
end up with plenty of old buffers by the end of the day.

(Note that if they toggled the default to now kill, instead of burying
the buffer, they would need a way to make an exception. E.g., the argument
would then instead bury, not kill.)

(Also let's say they have one or two dired buffers they really do want
to keep around, despite their "q" hitting habit.

Well then perhaps there should be a "dired-mark-this-buffer-as-q-kill-proof"
command... Or maybe even a regexp list that the user can put in their
.emacs file.)

bug#38818: Dired: mention deleting buffers, not just windows

[martin rudalics]

 > mr> but I'm afraid we have no facility supplying ...
 >
 >>> To make deleting the buffer the default instead of burying it, use
 >>> (setq ... ...)
 >
 > mr> ... that.
 >
 > OK, but there really should be a way. Else heavy dired users commonly
 > end up with plenty of old buffers by the end of the day.

Since this is about 'quit-window' we would have to decide what to do
with non-dired buffers (*Backtrace*, for example).  Kill them as well?
Provide a separate function 'dired-quit'?

 > (Note that if they toggled the default to now kill, instead of burying
 > the buffer, they would need a way to make an exception. E.g., the argument
 > would then instead bury, not kill.)
 >
 > (Also let's say they have one or two dired buffers they really do want
 > to keep around, despite their "q" hitting habit.
 >
 > Well then perhaps there should be a "dired-mark-this-buffer-as-q-kill-proof"
 > command... Or maybe even a regexp list that the user can put in their
 > .emacs file.)

I don't use dired so I can't tell.  But we could add a buffer-local
variable say 'quit-window-kill-buffer' that would tell for that buffer
what to do whenever quitting a window that shows it: The values being
'auto-kill' (always kill it automatically), 'survive' (don't kill it
even when 'quit-window' was called with a prefix argument) and nil to
do what it does now.  The question remains how to set that variable
conveniently.

martin

bug#38818: Dired: mention deleting buffers, not just windows

[Michael Heerdegen]

Hi Dan,

doesn't `kill-buffer-and-window' (C-x 4 0) already do what you want?

Michael.

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

>>>>> "MH" == Michael Heerdegen <michael_heerdegen@web.de> writes:

MH> doesn't `kill-buffer-and-window' (C-x 4 0) already do what you want?

Actually
 C-x k runs the command kill-buffer
is good enough perhaps.

Anyway the user, in dired, uses lots of v's and q's, to browse a tree.
The v's go in, and the q's go out.
After the day is finished, the files are all gone from the buffer list,
but the directories all remain.

So q when in a directory should do the same as q in (file) view mode,
which is View-quit.

So the
  q runs the command quit-window (found in dired-mode-map)
in dired-mode-map is the culprit.

So quit-window doesn't need to be changed at all. Instead q in
dired-mode-map needs a new binding.

OK, in dired, M-x View-quit does nothing. Makes sense, we are not in view-mode.

So dired's q should be mapped to kill-buffer instead... (Except
kill-buffer asks the user which buffer. So a new function is needed,
with no asking.)

Anyway this all could be controlled by a new variable:

dired-keep-directorys-around-upon-quitting-it

t: current behaviour (bury buffer)
nil: kill buffer
ask: ask upon each q what to do.

bug#38818: Dired: mention deleting buffers, not just windows

[Michael Heerdegen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> Anyway this all could be controlled by a new variable:

The default should be the current behavior, to avoid that users lose
marks by accident.  Also, there could be a prompt if there are any marks
in the buffer.

But... if the default is the same as now, you would not gain any advantage,
since you can already change the key binding without much effort.

I also don't see a discontinuity in the interface because unlike buffers
in view-mode, dired buffers can be edited, and killing them by accident
can be problematic, so it's per se ok for q not just to kill them.  But
I see the annoyance of tons of unneeded dired buffers lying around,
too.  Maybe asking for confirmation when a buffer has been edited by the
user would be a good idea.

Michael.

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

Yup, confirmation when edited or marks sounds good.

Otherwise if the user really wanted to keep the buffer around, he could
just do C-x C-b to switch to another buffer.

Wait, looking at C-h b,

i		dired-maybe-insert-subdir
j		dired-goto-file
k		dired-do-kill-lines
l		dired-do-redisplay
m		dired-mark
n		dired-next-line
o		dired-find-file-other-window
p		dired-previous-line
q		quit-window
s		dired-sort-toggle-or-edit
t		dired-toggle-marks
u		dired-unmark
v		dired-view-file
w		dired-copy-filename-as-kill
x		dired-do-flagged-delete
y		dired-show-file-type

So we "see" the problem is caused by just reusing quit-window instead of a
more tailored dired command...

One also notices
  dired-clean-up-buffers-too is a variable defined in ‘dired-x.el’.

So previously people had been working on related problems, but never got
around to all the left over directories.

MH> But... if the default is the same as now, you would not gain any advantage,
MH> since you can already change the key binding without much effort.

Actually I don't know how to bind kill-buffer to q and not have it still
ask me which buffer, but just kill it (marks and all, for now I guess.)
I'm not a lisp wiz.

bug#38818: Dired: mention deleting buffers, not just windows

[Michael Heerdegen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> One also notices
>   dired-clean-up-buffers-too is a variable defined in ‘dired-x.el’.
>
> So previously people had been working on related problems, but never got
> around to all the left over directories.

But that's not very related: AFAIK that means that if you have a buffer
visiting a file, and you kill that file in dired, Emacs asks whether to
kill the associated, and now obsolete, file buffer.  The analogue would
be to kill a dired buffer when you deleted its directory.

> Actually I don't know how to bind kill-buffer to q and not have it still
> ask me which buffer, but just kill it (marks and all, for now I guess.)
> I'm not a lisp wiz.

Does `kill-current-buffer' or `kill-buffer-and-window' (aka C-x 4 0) do
what you want?

Michael.

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

OK, I'll use
(add-hook
 'dired-load-hook
 (function
  (lambda ()
    (load "dired-x")
    (define-key dired-mode-map "q" 'kill-current-buffer)
    )))
until something more fancy is invented.

bug#38818: Dired: mention deleting buffers, not just windows

[Michael Heerdegen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> OK, I'll use
> (add-hook
>  'dired-load-hook
>  (function
>   (lambda ()
>     (load "dired-x")
>     (define-key dired-mode-map "q" 'kill-current-buffer)
>     )))
> until something more fancy is invented.

Slightly better version:

(add-hook
 'dired-load-hook
 (defun my-dired-load-hook-fun ()
   (require 'dired-x)
   (define-key dired-mode-map "q" #'kill-current-buffer)))

-- a named function can't accidentally be added multiple times to a
hook, lambda already self-quotes, and `require' doesn't unnecessarily
reload a file.

BTW, the q binding in dired-mode-map originates from special-mode-map
from which dired-mode-map inherits.  These are all bindings that it inherits:

SPC		scroll-up-command
-		negative-argument
0 .. 9		digit-argument
<		beginning-of-buffer
>		end-of-buffer
?		describe-mode
g		revert-buffer
h		describe-mode
q		quit-window
DEL		scroll-down-command
S-SPC		scroll-down-command
<remap>		Prefix Command

So the q binding is somewhat standard, and other modes may share your
problem.

Ok, I can't help further, I don't want to propose a solution.

Michael.

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

>> (add-hook
>> 'dired-load-hook
>> (function
>> (lambda ()
>> (load "dired-x")
>> (define-key dired-mode-map "q" 'kill-current-buffer)
>> )))

>>>>> "MH" == Michael Heerdegen <michael_heerdegen@web.de> writes:

MH> Slightly better version:

MH> (add-hook
MH>  'dired-load-hook
MH>  (defun my-dired-load-hook-fun ()
MH>    (require 'dired-x)
MH>    (define-key dired-mode-map "q" #'kill-current-buffer)))

MH> -- a named function can't accidentally be added multiple times to a
MH> hook, lambda already self-quotes, and `require' doesn't unnecessarily
MH> reload a file.

OK!
(info "(emacs) Hooks") just mentions the old fashioned way.
Maybe someone should update it.
OK maybe it is intentionally still full of those lambdas, for small jobs.

bug#38818: Dired: mention deleting buffers, not just windows

[Michael Heerdegen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> (info "(emacs) Hooks") just mentions the old fashioned way.
> Maybe someone should update it.
> OK maybe it is intentionally still full of those lambdas, for small jobs.

Using lambdas should be ok most of the time.  But there's a certain risk
of unintentionally having two copies of a function in a hook when the
code is executed multiple times, e.g. if you load your init file twice,
once compiled, and once the lisp source, because `add-hook' then can't
know that it's the same function.  Most of the time even this has no
visible effect, but when it has, it can be surprising and finding the
cause can be hard, so I try to just avoid adding lambdas to hooks in my
init file.

Michael.

bug#38818: Dired: mention deleting buffers, not just windows

[Drew Adams]

> But I see the annoyance of tons of unneeded dired buffers lying around,
> too.

`C-x C-v' prevents that.

---

Also, with Dired+ you can use `C-M-R' to toggle
reusing Dired buffers (instead of accumulating
them).  `RET' and `^' then automatically do what
`C-x C-v': replace the previous Dired buffer
with the new one.

It's a toggle because you can easily want to
sometimes keep Dired buffers by default and
sometimes want to replace them by default,
depending on what you're doing.

When keeping by default you can always use
`C-x C-v' to replace occasionally.

bug#38818: Dired: mention deleting buffers, not just windows

[Drew Adams]

> Using lambdas should be ok most of the time.  But there's a certain
> risk
> of unintentionally having two copies of a function in a hook when the
> code is executed multiple times, e.g. if you load your init file twice,
> once compiled, and once the lisp source, because `add-hook' then can't
> know that it's the same function.  Most of the time even this has no
> visible effect, but when it has, it can be surprising and finding the
> cause can be hard, so I try to just avoid adding lambdas to hooks in my
> init file.

Also, if you're testing stuff and you add a lambda
form to a hook, and later you want to remove it,
you need to use exactly the same text - same
whitespace, everything.  The lambda form is taken,
in effect, as text, and it looks for an exact
textual match.

It's very good to get in the habit of not using
lambdas on hooks.

bug#38818: Dired: mention deleting buffers, not just windows

[Noam Postavsky]

Drew Adams <drew.adams@oracle.com> writes:

> you need to use exactly the same text - same
> whitespace, everything.  The lambda form is taken,
> in effect, as text, and it looks for an exact
> textual match.

No, it's compared as a Lisp object with `equal', whitespace is not
significant.  If the lambda form is uncompiled then it's a list, if it's
compiled then it will be bytecode function object.

bug#38818: Dired: mention deleting buffers, not just windows

[Pieter van Oostrum]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Slightly better version:
>
> (add-hook
>  'dired-load-hook
>  (defun my-dired-load-hook-fun ()
>    (require 'dired-x)
>    (define-key dired-mode-map "q" #'kill-current-buffer)))

The documentation of defun says that its result is undefined. So either
it should not be relied upon, or (if the result is reliably the defined
function) it should be documented as such.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: Dired: mention deleting buffers, not just windows

[Richard Stallman]

[[[ 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. ]]]

How about this addition?

diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi
index 7354eb1..b52871e 100644
--- a/doc/lispref/modes.texi
+++ b/doc/lispref/modes.texi
@@ -135,13 +135,26 @@ non-@code{nil} value, it returns that value; otherwise it returns
 @node Setting Hooks
 @subsection Setting Hooks
 
-  Here's an example that uses a mode hook to turn on Auto Fill mode when
-in Lisp Interaction mode:
+  Here's an example that adds a funtion to a mode hook to turn
+on Auto Fill mode when in Lisp Interaction mode:
 
 @example
 (add-hook 'lisp-interaction-mode-hook 'auto-fill-mode)
 @end example
 
+  The value of a hook variable should be a list of functions.  You can
+manipulate that list using the normal Lisp facilities, but the modular
+way is to use the functions @code{add-hook} and @code{remove-hook},
+defined below.  They take care to handle some unusual situations and
+avoid problems.
+
+  It works to put a @code{lambda}-expression function on a hook, but
+we recommend avoiding this because it can lead to confusion.  If you
+add the same @code{lambda}-expression a second time but write it
+slightly differently, you will get two equivalent but distinct
+functions on the hook.  If you then remove one of them, the other will
+still be on it.
+
 @defun add-hook hook function &optional depth local
 This function is the handy way to add function @var{function} to hook
 variable @var{hook}.  You can use it for abnormal hooks as well as for

-- 
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)

bug#38818: Dired: mention deleting buffers, not just windows

[Drew Adams]

> How about this addition?

LGTM.

> +  It works to put a @code{lambda}-expression function on a hook, but
> +we recommend avoiding this because it can lead to confusion.  If you
> +add the same @code{lambda}-expression a second time but write it
> +slightly differently, you will get two equivalent but distinct
> +functions on the hook.  If you then remove one of them, the other will
> +still be on it.

But see Noam's reply to my message.

Given that, we might want to describe better
how two lambda forms that you might think
represent the same function can be considered
different in this context.

(I know I've been bitten by that, in particular
not recalling exactly how I wrote a lambda form
that I added, when I later wanted to remove it,
and not bothering to check its form on the hook.
But I'm sure Noam is right in what he says.)

Alternatively, maybe the language should just
be vague enough to skirt the conditions that
can treat two seemingly "equal" anonymous
functions as different.  IOW, that's not really
the point here, which is just to tell users that
they probably want to use named functions on hooks.

Your "because it can lead to confusion" is maybe
sufficient, here.

bug#38818: Dired: mention deleting buffers, not just windows

[Michael Heerdegen]

Pieter van Oostrum <pieter-l@vanoostrum.org> writes:

> > Slightly better version:
> >
> > (add-hook
> >  'dired-load-hook
> >  (defun my-dired-load-hook-fun ()
> >    (require 'dired-x)
> >    (define-key dired-mode-map "q" #'kill-current-buffer)))
>
> The documentation of defun says that its result is undefined. So either
> it should not be relied upon, or (if the result is reliably the defined
> function) it should be documented as such.

Indeed: the return value of `defun' even changed recently (from
returning the definition to returning the defined symbol).  Same for
defalias.

I think I'll file another bug report: adding user defined functions to
hooks not only has the common pitfall which is not warned about - the
alternative, using named functions, is also quite inconvenient since
defun's return value is unspecified.  I guess most users currently do it
wrong.  Or do I miss something?


Thanks,

Michael.

bug#38818: Dired: mention deleting buffers, not just windows

[Richard Stallman]

[[[ 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. ]]]

  > Given that, we might want to describe better
  > how two lambda forms that you might think
  > represent the same function can be considered
  > different in this context.

It seems clear to me, but I don't insist on the wording I suggested.

-- 
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)

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

>>>>> "PvO" == Pieter van Oostrum <pieter-l@vanoostrum.org> writes:
PvO> Michael Heerdegen <michael_heerdegen@web.de> writes:

>> Slightly better version:
>> 
>> (add-hook
>> 'dired-load-hook
>> (defun my-dired-load-hook-fun ()
>> (require 'dired-x)
>> (define-key dired-mode-map "q" #'kill-current-buffer)))

PvO> The documentation of defun says that its result is undefined. So either
PvO> it should not be relied upon, or (if the result is reliably the defined
PvO> function) it should be documented as such.

OK. So what is the best way I should write it for my .emacs file? Thanks.

bug#38818: Dired: mention deleting buffers, not just windows

[Pieter van Oostrum]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

>>>>>> "PvO" == Pieter van Oostrum <pieter-l@vanoostrum.org> writes:
> PvO> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>>> Slightly better version:
>>> 
>>> (add-hook
>>> 'dired-load-hook
>>> (defun my-dired-load-hook-fun ()
>>> (require 'dired-x)
>>> (define-key dired-mode-map "q" #'kill-current-buffer)))
>
> PvO> The documentation of defun says that its result is undefined. So either
> PvO> it should not be relied upon, or (if the result is reliably the defined
> PvO> function) it should be documented as such.
>
> OK. So what is the best way I should write it for my .emacs file? Thanks.

Well, this is how I do it.

(defun my-dired-load-hook-fun ()
       (require 'dired-x)
       (define-key dired-mode-map "q" #'kill-current-buffer))

(add-hook 'dired-load-hook 'my-dired-load-hook-fun)

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

>>>>> "PvO" == Pieter van Oostrum <pieter-l@vanoostrum.org> writes:
PvO> Well, this is how I do it.

PvO> (defun my-dired-load-hook-fun ()
PvO>        (require 'dired-x)
PvO>        (define-key dired-mode-map "q" #'kill-current-buffer))

PvO> (add-hook 'dired-load-hook 'my-dired-load-hook-fun)

OK, but this does not seem environmentally friendly, leaving a function
(that I hereby promise not to use a second time,) lying around.

Well I guess I could undefun it... But one never can find out how (Bug!:
(info "(eintr) Change a defun") etc. Info pages never say how!)
Plus seems a little bulky to do a defun ... undefun each time in a
.emacs file.

bug#38818: Dired: mention deleting buffers, not just windows

[Pieter van Oostrum]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

>>>>>> "PvO" == Pieter van Oostrum <pieter-l@vanoostrum.org> writes:
> PvO> Well, this is how I do it.
>
> PvO> (defun my-dired-load-hook-fun ()
> PvO>        (require 'dired-x)
> PvO>        (define-key dired-mode-map "q" #'kill-current-buffer))
>
> PvO> (add-hook 'dired-load-hook 'my-dired-load-hook-fun)
>
> OK, but this does not seem environmentally friendly, leaving a function
> (that I hereby promise not to use a second time,) lying around.
>
> Well I guess I could undefun it... But one never can find out how (Bug!:
> (info "(eintr) Change a defun") etc. Info pages never say how!)
> Plus seems a little bulky to do a defun ... undefun each time in a
> .emacs file.

Your version does that too, if the defun semantics would be what you expected. It leaves exactly the same function in the name space. If you don't want that then use the lambda form. But you said your version was better. Why then if you want the function to be anonymous?
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

OK I'll go back to the lambda way I had in
https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-01/msg00000.html

OK can find lots of "defun" documentation, but it never mentions how to
undefine one. For that one needs a web search
https://www.google.com/search?q=emacs+undefine+a+function

bug#38818: Dired: mention deleting buffers, not just windows

[Michael Heerdegen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> >>>>> "PvO" == Pieter van Oostrum <pieter-l@vanoostrum.org> writes:
> PvO> Well, this is how I do it.
>
> PvO> (defun my-dired-load-hook-fun ()
> PvO>        (require 'dired-x)
> PvO>        (define-key dired-mode-map "q" #'kill-current-buffer))
>
> PvO> (add-hook 'dired-load-hook 'my-dired-load-hook-fun)
>
> OK, but this does not seem environmentally friendly, leaving a function
> (that I hereby promise not to use a second time,) lying around.

Your lambda will also keep lying around.  The name "dired-load-hook"
will keep lying around.

And: for most of the hooks you want to add stuff to you probably can't
be sure that it won't be run more than once.  Undefining cries for
errors.  It's also not necessary, those few additional names hardly make
a difference.


Michael.

bug#38818: Dired: mention deleting buffers, not just windows

[Noam Postavsky]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> OK, I'll use
> (add-hook
>  'dired-load-hook
>  (function
>   (lambda ()
>     (load "dired-x")
>     (define-key dired-mode-map "q" 'kill-current-buffer)
>     )))
> until something more fancy is invented.

With regards to all the subsequent lambda vs defun stuff, you could also
use with-eval-after-load instead of dired-load-hook:

(with-eval-after-load 'dired
  (require 'dired-x)
  (define-key dired-mode-map "q" 'kill-current-buffer))

Actually, this does also use a lambda behind the scenes and has similar
drawbacks, but for some reason it doesn't seem to bother people as much.

bug#38818: Dired: mention deleting buffers, not just windows

[Pieter van Oostrum]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> 積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:
>
>> >>>>> "PvO" == Pieter van Oostrum <pieter-l@vanoostrum.org> writes:
>> PvO> Well, this is how I do it.
>>
>> PvO> (defun my-dired-load-hook-fun ()
>> PvO>        (require 'dired-x)
>> PvO>        (define-key dired-mode-map "q" #'kill-current-buffer))
>>
>> PvO> (add-hook 'dired-load-hook 'my-dired-load-hook-fun)
>>
>> OK, but this does not seem environmentally friendly, leaving a function
>> (that I hereby promise not to use a second time,) lying around.
>
> Your lambda will also keep lying around.  The name "dired-load-hook"
> will keep lying around.

Yes, of course, I want that.

> And: for most of the hooks you want to add stuff to you probably can't
> be sure that it won't be run more than once.  Undefining cries for
> errors.  It's also not necessary, those few additional names hardly make
> a difference.

For me it doesn't. It was Dan who complained about that.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: Dired: mention deleting buffers, not just windows

[Pieter van Oostrum]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> OK I'll go back to the lambda way I had in
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-01/msg00000.html

You can make it a bit simpler by eliminating the (function ... ) around the lambda.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: Dired: mention deleting buffers, not just windows

[Richard Stallman]

[[[ 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. ]]]

  > OK can find lots of "defun" documentation, but it never mentions how to
  > undefine one.

Would you please say precisely where you found that "defun" documentation?
Then we could think about whether to add something there.

In the Lisp Reference manual, defun is described in
node Defining Functions.  We could add an xref to the node
Function Cells about this.


-- 
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)

bug#38818: Dired: mention deleting buffers, not just windows

[Pieter van Oostrum]

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. ]]]
>
>   > OK can find lots of "defun" documentation, but it never mentions how to
>   > undefine one.
>
> Would you please say precisely where you found that "defun" documentation?
> Then we could think about whether to add something there.

C-h f defun

> In the Lisp Reference manual, defun is described in
> node Defining Functions.  We could add an xref to the node
> Function Cells about this.
>

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: Dired: mention deleting buffers, not just windows

[Pieter van Oostrum]

And, by the way, that message arrived here with the CJK characters in Dan Jacobson's name mangled. Whereas the normally are 積丹尼, they now are <some unprintable characters>, and message-send-mail crashes on it.

Debugger entered--Lisp error: (cl-assertion-failed ((save-excursion (goto-char (point-min)) (not (re-search-forward "[^\0-\377]" nil t))) nil))
  cl--assertion-failed((save-excursion (goto-char (point-min)) (not (re-search-forward "[^\0-\377]" nil t))))
  message-send-mail(nil)
  message-send-via-mail(nil)

The raw header is:

To: =?iso-8859-1?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson
 <jidanni@jidanni.org>
which translates to unprintable characters, which cause this error.
Normally it would be
From: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson
so it seems to be a mixup of encodings on RMS's side.

When these unprintable characters re in the message body, you get an error message with a choice:

Non-printable characters found.  Continue sending? (delete, replace, send, edit, ?):

but when they are in the header it just bails out with an uncomprehensible error
cl--assertion-failed: Assertion failed: (save-excursion (goto-char (point-min)) (not (re-search-forward "[^.-ÿ]" nil t)))
which isn't helpful at all.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: Dired: mention deleting buffers, not just windows

[Eli Zaretskii]

> From: Pieter van Oostrum <pieter-l@vanoostrum.org>
> Date: Sun, 05 Jan 2020 09:06:48 +0100
> Cc: michael_heerdegen@web.de, Dan Jacobson <jidanni@jidanni.org>,
>  38818@debbugs.gnu.org
> 
> And, by the way, that message arrived here with the CJK characters in Dan Jacobson's name mangled. Whereas the normally are 積丹尼, they now are <some unprintable characters>, and message-send-mail crashes on it.

Please report this as a separate bug, and please include the offending
email message (as an attachment) with your report.

Thanks.

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

Sounds like RMS's personal CJK-mangling mail system. But he doesn't have time to fix it.

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

OK, as to what to put into my .emacs, I'll stick to what is in the books.

bug#38818: Dired: mention deleting buffers, not just windows

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: Pieter van Oostrum <pieter-l@vanoostrum.org>,  rms@gnu.org,  michael_heerdegen@web.de,  38818@debbugs.gnu.org
> Date: Mon, 06 Jan 2020 02:19:03 +0800
> 
> Sounds like RMS's personal CJK-mangling mail system. But he doesn't have time to fix it.

It isn't just RMS's email, it's also your email: it claims to be
text/plain and doesn't state any charset, but comes with a non-ASCII
name.

bug#38818: jidanni's mail headers not perfect?!

[積丹尼 Dan Jacobson]

EZ> it claims to be text/plain and doesn't state any charset, but comes with a non-ASCII name.

Naw....

From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson <jidanni@jidanni.org>
      ^^^^^^^^^^^
is all one needs.
Content-Type: text/plain
is discussing the body, not the header.

bug#38818: jidanni's mail headers not perfect?!

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: pieter-l@vanoostrum.org,  rms@gnu.org,  michael_heerdegen@web.de,  38818@debbugs.gnu.org, larsi@gnus.org
> Date: Mon, 06 Jan 2020 03:09:33 +0800
> 
> EZ> it claims to be text/plain and doesn't state any charset, but comes with a non-ASCII name.
> 
> Naw....
> 
> From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson <jidanni@jidanni.org>
>       ^^^^^^^^^^^

Why do you think this arrives intact to people's MUA?

bug#38818: jidanni's mail headers not perfect?!

[Pieter van Oostrum]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
>> Cc: pieter-l@vanoostrum.org, rms@gnu.org, michael_heerdegen@web.de,
>> 38818@debbugs.gnu.org, larsi@gnus.org
>> Date: Mon, 06 Jan 2020 03:09:33 +0800
>> 
>> EZ> it claims to be text/plain and doesn't state any charset, but comes with a non-ASCII name.
>> 
>> Naw....
>> 
>> From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson <jidanni@jidanni.org>
>>       ^^^^^^^^^^^
>
> Why do you think this arrives intact to people's MUA?

What would be wrong with that? It seems to me that it conforms to RFC 2047.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: Dired: mention deleting buffers, not just windows

[Richard Stallman]

[[[ 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. ]]]

  > > Would you please say precisely where you found that "defun" documentation?
  > > Then we could think about whether to add something there.

  > C-h f defun

That is supposed to document defun specifically.
I don't have an opinion about whether it should document related topics.
I will leave that discussion to others.

-- 
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)

bug#38818: Dired: mention deleting buffers, not just windows

[Richard Stallman]

[[[ 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. ]]]

  > Sounds like RMS's personal CJK-mangling mail system. But he
  > doesn't have time to fix it.

That code is part of Rmail.  I don't think it has changed,
but it seems other systems now react strangely to it, so it
needs to be changed.

I could fix, it but I might need an hour to figure out the
way things are supposed to work nowadays, and I can't spare that.

-- 
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)

Re: improvement in functions.texi

[Richard Stallman]

[[[ 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 propose this improvement in functions.texi.  The biggest change
is moving the description of define-inline into the node Inline Functions
where it semantically fits better.  But this also adds a cross
reference in Defining Functions to information about undefining.

diff -u /home/rms/emacs-git/build-oct-2/doc/lispref/functions.texi.\~2\~ /home/rms/emacs-git/build-oct-2/doc/lispref/functions.texi
--- /home/rms/emacs-git/build-oct-2/doc/lispref/functions.texi.~2~	2019-10-26 08:57:05.985082189 -0400
+++ /home/rms/emacs-git/build-oct-2/doc/lispref/functions.texi	2020-01-05 16:12:09.453450858 -0500
@@ -575,8 +575,9 @@
 @cindex defining a function
 
   We usually give a name to a function when it is first created.  This
-is called @dfn{defining a function}, and it is done with the
-@code{defun} macro.
+is called @dfn{defining a function}, and we usually do it with the
+@code{defun} macro.  This section also describes other ways to define
+a function.
 
 @defmac defun name args [doc] [declare] [interactive] body@dots{}
 @code{defun} is the usual way to define new Lisp functions.  It
@@ -681,95 +682,8 @@
 and tells the Lisp compiler to perform inline expansion on it.
 @xref{Inline Functions}.
 
-  Alternatively, you can define a function by providing the code which
-will inline it as a compiler macro.  The following macros make this
-possible.
-
-@c FIXME: Can define-inline use the interactive spec?
-@defmac define-inline name args [doc] [declare] body@dots{}
-Define a function @var{name} by providing code that does its inlining,
-as a compiler macro.  The function will accept the argument list
-@var{args} and will have the specified @var{body}.
-
-If present, @var{doc} should be the function's documentation string
-(@pxref{Function Documentation}); @var{declare}, if present, should be
-a @code{declare} form (@pxref{Declare Form}) specifying the function's
-metadata.
-@end defmac
-
-Functions defined via @code{define-inline} have several advantages
-with respect to macros defined by @code{defsubst} or @code{defmacro}:
-
-@itemize @minus
-@item
-They can be passed to @code{mapcar} (@pxref{Mapping Functions}).
-
-@item
-They are more efficient.
-
-@item
-They can be used as @dfn{place forms} to store values
-(@pxref{Generalized Variables}).
-
-@item
-They behave in a more predictable way than @code{cl-defsubst}
-(@pxref{Argument Lists,,, cl, Common Lisp Extensions for GNU Emacs
-Lisp}).
-@end itemize
-
-Like @code{defmacro}, a function inlined with @code{define-inline}
-inherits the scoping rules, either dynamic or lexical, from the call
-site.  @xref{Variable Scoping}.
-
-The following macros should be used in the body of a function defined
-by @code{define-inline}.
-
-@defmac inline-quote expression
-Quote @var{expression} for @code{define-inline}.  This is similar to
-the backquote (@pxref{Backquote}), but quotes code and accepts only
-@code{,}, not @code{,@@}.
-@end defmac
-
-@defmac inline-letevals (bindings@dots{}) body@dots{}
-This is similar to @code{let} (@pxref{Local Variables}): it sets up
-local variables as specified by @var{bindings}, and then evaluates
-@var{body} with those bindings in effect.  Each element of
-@var{bindings} should be either a symbol or a list of the form
-@w{@code{(@var{var} @var{expr})}}; the result is to evaluate
-@var{expr} and bind @var{var} to the result.  The tail of
-@var{bindings} can be either @code{nil} or a symbol which should hold
-a list of arguments, in which case each argument is evaluated, and the
-symbol is bound to the resulting list.
-@end defmac
-
-@defmac inline-const-p expression
-Return non-@code{nil} if the value of @var{expression} is already
-known.
-@end defmac
-
-@defmac inline-const-val expression
-Return the value of @var{expression}.
-@end defmac
-
-@defmac inline-error format &rest args
-Signal an error, formatting @var{args} according to @var{format}.
-@end defmac
-
-Here's an example of using @code{define-inline}:
-
-@lisp
-(define-inline myaccessor (obj)
-  (inline-letevals (obj)
-    (inline-quote (if (foo-p ,obj) (aref (cdr ,obj) 3) (aref ,obj 2)))))
-@end lisp
-
-@noindent
-This is equivalent to
-
-@lisp
-(defsubst myaccessor (obj)
-  (if (foo-p obj) (aref (cdr obj) 3) (aref obj 2)))
-@end lisp
+  To undefine a function name, use @code{fmakunbound}.
+@xref{Function Cells}.
 
 @node Calling Functions
 @section Calling Functions
@@ -2154,8 +2068,12 @@
   An @dfn{inline function} is a function that works just like an
 ordinary function, except for one thing: when you byte-compile a call
 to the function (@pxref{Byte Compilation}), the function's definition
-is expanded into the caller.  To define an inline function, use
-@code{defsubst} instead of @code{defun}.
+is expanded into the caller.
+
+  The simple way to define an inline function, is to write
+@code{defsubst} instead of @code{defun}.  The rest of the definition
+looks just the same, but using @code{defsubst} says to make it inline
+for byte compilation.
 
 @defmac defsubst name args [doc] [declare] [interactive] body@dots{}
 This macro defines an inline function.  Its syntax is exactly the same
@@ -2193,9 +2111,95 @@
 worry about how many times the body uses the arguments, as you do for
 macros.
 
-  As an alternative to @code{defsubst}, you can use
-@code{define-inline} to define functions via their exhaustive compiler
-macro.  @xref{Defining Functions, define-inline}.
+  Alternatively, you can define a function by providing the code which
+will inline it as a compiler macro.  The following macros make this
+possible.
+
+@c FIXME: Can define-inline use the interactive spec?
+@defmac define-inline name args [doc] [declare] body@dots{}
+Define a function @var{name} by providing code that does its inlining,
+as a compiler macro.  The function will accept the argument list
+@var{args} and will have the specified @var{body}.
+
+If present, @var{doc} should be the function's documentation string
+(@pxref{Function Documentation}); @var{declare}, if present, should be
+a @code{declare} form (@pxref{Declare Form}) specifying the function's
+metadata.
+@end defmac
+
+Functions defined via @code{define-inline} have several advantages
+with respect to macros defined by @code{defsubst} or @code{defmacro}:
+
+@itemize @minus
+@item
+They can be passed to @code{mapcar} (@pxref{Mapping Functions}).
+
+@item
+They are more efficient.
+
+@item
+They can be used as @dfn{place forms} to store values
+(@pxref{Generalized Variables}).
+
+@item
+They behave in a more predictable way than @code{cl-defsubst}
+(@pxref{Argument Lists,,, cl, Common Lisp Extensions for GNU Emacs
+Lisp}).
+@end itemize
+
+Like @code{defmacro}, a function inlined with @code{define-inline}
+inherits the scoping rules, either dynamic or lexical, from the call
+site.  @xref{Variable Scoping}.
+
+The following macros should be used in the body of a function defined
+by @code{define-inline}.
+
+@defmac inline-quote expression
+Quote @var{expression} for @code{define-inline}.  This is similar to
+the backquote (@pxref{Backquote}), but quotes code and accepts only
+@code{,}, not @code{,@@}.
+@end defmac
+
+@defmac inline-letevals (bindings@dots{}) body@dots{}
+This is similar to @code{let} (@pxref{Local Variables}): it sets up
+local variables as specified by @var{bindings}, and then evaluates
+@var{body} with those bindings in effect.  Each element of
+@var{bindings} should be either a symbol or a list of the form
+@w{@code{(@var{var} @var{expr})}}; the result is to evaluate
+@var{expr} and bind @var{var} to the result.  The tail of
+@var{bindings} can be either @code{nil} or a symbol which should hold
+a list of arguments, in which case each argument is evaluated, and the
+symbol is bound to the resulting list.
+@end defmac
+
+@defmac inline-const-p expression
+Return non-@code{nil} if the value of @var{expression} is already
+known.
+@end defmac
+
+@defmac inline-const-val expression
+Return the value of @var{expression}.
+@end defmac
+
+@defmac inline-error format &rest args
+Signal an error, formatting @var{args} according to @var{format}.
+@end defmac
+
+Here's an example of using @code{define-inline}:
+
+@lisp
+(define-inline myaccessor (obj)
+  (inline-letevals (obj)
+    (inline-quote (if (foo-p ,obj) (aref (cdr ,obj) 3) (aref ,obj 2)))))
+@end lisp
+
+@noindent
+This is equivalent to
+
+@lisp
+(defsubst myaccessor (obj)
+  (if (foo-p obj) (aref (cdr obj) 3) (aref obj 2)))
+@end lisp
 
 @node Declare Form
 @section The @code{declare} Form

Diff finished.  Sun Jan  5 16:20:31 2020

-- 
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)

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

積丹尼 Dan Jacobson <jidanni@jidanni.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. ]]]
>
>   > Sounds like RMS's personal CJK-mangling mail system. But he
>   > doesn't have time to fix it.
>
> That code is part of Rmail.  I don't think it has changed,
> but it seems other systems now react strangely to it, so it
> needs to be changed.
>
> I could fix, it but I might need an hour to figure out the
> way things are supposed to work nowadays, and I can't spare that.
>
> -- 
> 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)

-- 
Pieter van Oostrum <pieter@vanoostrum.org>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: jidanni's mail headers not perfect?!

[Eli Zaretskii]

> From: Pieter van Oostrum <pieter-l@vanoostrum.org>
> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>   rms@gnu.org,
>   michael_heerdegen@web.de,  38818@debbugs.gnu.org,  larsi@gnus.org
> Date: Sun, 05 Jan 2020 21:48:54 +0100
> 
> >> EZ> it claims to be text/plain and doesn't state any charset, but comes with a non-ASCII name.
> >> 
> >> Naw....
> >> 
> >> From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson <jidanni@jidanni.org>
> >>       ^^^^^^^^^^^
> >
> > Why do you think this arrives intact to people's MUA?
> 
> What would be wrong with that? It seems to me that it conforms to RFC 2047.

Sorry, I don't understand: what would be wrong with what, exactly?

bug#38818: Dired: mention deleting buffers, not just windows

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, pieter-l@vanoostrum.org, michael_heerdegen@web.de,
> 	38818@debbugs.gnu.org
> Date: Sun, 05 Jan 2020 17:19:44 -0500
> 
>   > Sounds like RMS's personal CJK-mangling mail system. But he
>   > doesn't have time to fix it.
> 
> That code is part of Rmail.  I don't think it has changed,
> but it seems other systems now react strangely to it, so it
> needs to be changed.

It's not just Rmail, it's something in your personal setup as well.
Because I use Rmail as well, and have no such problems.  I'm guessing
it's some locale-dependent or coding-system-dependent customizations,
and perhaps also the way you fetch your email from gnu.org.

bug#38818: jidanni's mail headers not perfect?!

[Andreas Schwab]

On Jan 05 2020, Eli Zaretskii wrote:

>> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
>> Cc: pieter-l@vanoostrum.org,  rms@gnu.org,  michael_heerdegen@web.de,  38818@debbugs.gnu.org, larsi@gnus.org
>> Date: Mon, 06 Jan 2020 03:09:33 +0800
>> 
>> EZ> it claims to be text/plain and doesn't state any charset, but comes with a non-ASCII name.
>> 
>> Naw....
>> 
>> From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson <jidanni@jidanni.org>
>>       ^^^^^^^^^^^
>
> Why do you think this arrives intact to people's MUA?

Why do you think this does not arrive intact to people's MUA?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#38818: jidanni's mail headers not perfect?!

[Eli Zaretskii]

On January 6, 2020 10:30:55 AM GMT+02:00, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Jan 05 2020, Eli Zaretskii wrote:
> 
> >> From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson <jidanni@jidanni.org>
> >>       ^^^^^^^^^^^
> >
> > Why do you think this arrives intact to people's MUA?
> 
> Why do you think this does not arrive intact to people's MUA?

Because some methods of fetching email auto-convert qp-encoded and base64 encoded parts.

I don't know how exactly RMS fetches his, but it could happen for him.

bug#38818: jidanni's mail headers not perfect?!

[Andreas Schwab]

On Jan 06 2020, Eli Zaretskii wrote:

> On January 6, 2020 10:30:55 AM GMT+02:00, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> On Jan 05 2020, Eli Zaretskii wrote:
>> 
>> >> From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson <jidanni@jidanni.org>
>> >>       ^^^^^^^^^^^
>> >
>> > Why do you think this arrives intact to people's MUA?
>> 
>> Why do you think this does not arrive intact to people's MUA?
>
> Because some methods of fetching email auto-convert qp-encoded and base64 encoded parts.

But that isn't the fault of the raw mail contents.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#38818: jidanni's mail headers not perfect?!

[Pieter van Oostrum]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Pieter van Oostrum <pieter-l@vanoostrum.org>
>> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>>   rms@gnu.org,
>>   michael_heerdegen@web.de,  38818@debbugs.gnu.org,  larsi@gnus.org
>> Date: Sun, 05 Jan 2020 21:48:54 +0100
>> 
>> >> EZ> it claims to be text/plain and doesn't state any charset, but comes with a non-ASCII name.
>> >> 
>> >> Naw....
>> >> 
>> >> From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson <jidanni@jidanni.org>
>> >>       ^^^^^^^^^^^
>> >
>> > Why do you think this arrives intact to people's MUA?
>> 
>> What would be wrong with that? It seems to me that it conforms to RFC 2047.
>
> Sorry, I don't understand: what would be wrong with what, exactly?

OK, then I probably didn't understand you.
You asked about =?utf-8?B?56mN5Li55bC8?=
"Why do you think this arrives intact to people's MUA?"

So I thought you meant there is something wrong with that part. Apparently you did not mean that. So what did you mean? Dan seems to want that part (some CJK characters) to show up in the email, and it does for me. And that is how it should be.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

bug#38818: jidanni's mail headers not perfect?!

[Eli Zaretskii]

On January 6, 2020 11:23:13 AM GMT+02:00, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Jan 06 2020, Eli Zaretskii wrote:
> 
> > On January 6, 2020 10:30:55 AM GMT+02:00, Andreas Schwab
> <schwab@linux-m68k.org> wrote:
> >> On Jan 05 2020, Eli Zaretskii wrote:
> >> 
> >> >> From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson
> <jidanni@jidanni.org>
> >> >>       ^^^^^^^^^^^
> >> >
> >> > Why do you think this arrives intact to people's MUA?
> >> 
> >> Why do you think this does not arrive intact to people's MUA?
> >
> > Because some methods of fetching email auto-convert qp-encoded and
> base64 encoded parts.
> 
> But that isn't the fault of the raw mail contents.


This isn't about assigning blame, this is about finding where that mojibake comes from and what triggers it, and hopefully figuring out how to avoid or fix that.

bug#38818: jidanni's mail headers not perfect?!

[Eli Zaretskii]

On January 6, 2020 11:56:18 AM GMT+02:00, Pieter van Oostrum <pieter-l@vanoostrum.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> OK, then I probably didn't understand you.
> You asked about =?utf-8?B?56mN5Li55bC8?=
> "Why do you think this arrives intact to people's MUA?"
> 
> So I thought you meant there is something wrong with that part.
> Apparently you did not mean that. So what did you mean? Dan seems to
> want that part (some CJK characters) to show up in the email, and it
> does for me. And that is how it should be.

I'm saying that if the original mail had some suitable MIME charset in its headers, the problem would be less likely to happen.  Because email messages that rely on implicit encoding specifications are more likely to hit subtle problems.

And btw, no one can rely on having the exact same encoded name in response email, MUA and MTA are free to change the representation at will, as long as the content is transferred without losses.

bug#38818: jidanni's mail headers not perfect?!

[Andreas Schwab]

On Jan 06 2020, Eli Zaretskii wrote:

> This isn't about assigning blame,

The please don't make is sound like that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#38818: jidanni's mail headers not perfect?!

[Andreas Schwab]

On Jan 06 2020, Eli Zaretskii wrote:

> I'm saying that if the original mail had some suitable MIME charset in
> its headers, the problem would be less likely to happen.

The MIME charset is there: =?UTF-8?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#38818: Dired: mention deleting buffers, not just windows

[Richard Stallman]

[[[ 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. ]]]

  > It's not just Rmail, it's something in your personal setup as well.
  > Because I use Rmail as well, and have no such problems.  I'm guessing
  > it's some locale-dependent or coding-system-dependent customizations,
  > and perhaps also the way you fetch your email from gnu.org.

I fetch the mail by copying the inbox file verbatim, so I doubt it can
be that.

I debugged this some, and found that rfc2047-decode-encoded-words
is decoding header fields such as =?iso-8859-1?Q?B=C3=A9raud?=
incorrectly, using a peculiar choice of coding system, windows-1252.
That seems to come from mm-charset-to-coding-system.

Does anyone see how that could happen?

-- 
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)

Re: Bad RFC 2047 decoding in Rmail

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: michael_heerdegen@web.de, pieter-l@vanoostrum.org,
> 	jidanni@jidanni.org, 38818@debbugs.gnu.org
> Date: Mon, 06 Jan 2020 18:08:36 -0500
> 
> I debugged this some, and found that rfc2047-decode-encoded-words
> is decoding header fields such as =?iso-8859-1?Q?B=C3=A9raud?=
> incorrectly, using a peculiar choice of coding system, windows-1252.
> That seems to come from mm-charset-to-coding-system.
> 
> Does anyone see how that could happen?

It has to be something at least a bit specific to your environment or
customizations, because I use Rmail in the exact same way, and these
problems never happen to me, including when replying to jidanni.

Can you try this in "emacs -Q"?  It would help if you did that with
the email message where the problem happened, which is this:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38818#80

You can download that message in mbox format from this URL:

  https://debbugs.gnu.org/cgi/bugreport.cgi?msg=80;bug=38818;mbox=yes

If you respond to this message, and the problem happens in "emacs -Q"
as well, then please either step through rfc2047-decode-encoded-words
and tell where does it make the bad decoding decision, or tell me you
values of locale-coding-system and buffer-file-coding-system, and I
will try to reproduce on my system.

If the problem doesn't happen in "emacs -Q", then some of your
customizations directly or indirectly cause
rfc2047-decode-encoded-words to fail, and so please try to find out
which of the customizations do that.

Re: Bad RFC 2047 decoding in Rmail

[Stefan Monnier]

>> I debugged this some, and found that rfc2047-decode-encoded-words
>> is decoding header fields such as =?iso-8859-1?Q?B=C3=A9raud?=
>> incorrectly, using a peculiar choice of coding system, windows-1252.

`windows-1252` is a superset of `iso-8859-1` (it assigns chars to a few
more bytes which `iso-8859-1` leaves unused), so it can only generate
"incorrect" output if `iso-8859-1` would have generated incorrect output
as well.


        Stefan

Re: Bad RFC 2047 decoding in Rmail

[Richard Stallman]

[[[ 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. ]]]

  > `windows-1252` is a superset of `iso-8859-1` (it assigns chars to a few
  > more bytes which `iso-8859-1` leaves unused), so it can only generate
  > "incorrect" output if `iso-8859-1` would have generated incorrect output
  > as well.

I thought I partially understood the problem, but it seems I did not get
any real understanding.


-- 
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)

bug#38818: Dired: mention deleting buffers, not just windows

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 01 Jan 2020 18:18:44 -0500
> Cc: michael_heerdegen@web.de, jidanni@jidanni.org, 38818@debbugs.gnu.org
> 
> How about this addition?
> 
> diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi
> index 7354eb1..b52871e 100644
> --- a/doc/lispref/modes.texi
> +++ b/doc/lispref/modes.texi

Thanks, I installed it.

Re: improvement in functions.texi

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 05 Jan 2020 17:21:41 -0500
> Cc: michael_heerdegen@web.de, pieter-l@vanoostrum.org, jidanni@jidanni.org
> 
> I propose this improvement in functions.texi.  The biggest change
> is moving the description of define-inline into the node Inline Functions
> where it semantically fits better.  But this also adds a cross
> reference in Defining Functions to information about undefining.

Thanks, installed.

bug#38818: Dired: mention deleting buffers, not just windows

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I debugged this some, and found that rfc2047-decode-encoded-words
> is decoding header fields such as =?iso-8859-1?Q?B=C3=A9raud?=
> incorrectly, using a peculiar choice of coding system, windows-1252.
> That seems to come from mm-charset-to-coding-system.
>
> Does anyone see how that could happen?

I don't.  Do you have a test case?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38818: Dired: mention deleting buffers, not just windows

[Lars Ingebrigtsen]

Reading this thread, there doesn't seem like there's anything much to
fix here.  The user can redefine `q' in the buffers they want, or use
quit-window-hook to do something, or use `C-x k'.

(There were other issues touched upon (like defun in hooks), but they've
been clarified.)

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#38818: Dired: mention deleting buffers, not just windows

[積丹尼 Dan Jacobson]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
LI> Richard Stallman <rms@gnu.org> writes:

>> I debugged this some, and found that rfc2047-decode-encoded-words
>> is decoding header fields such as =?iso-8859-1?Q?B=C3=A9raud?=
>> incorrectly, using a peculiar choice of coding system, windows-1252.
>> That seems to come from mm-charset-to-coding-system.
>> 
>> Does anyone see how that could happen?

LI> I don't.  Do you have a test case?

I thought the test case was my header as on the From: in the header of
this message that I am sending now.

bug#38818: Dired: mention deleting buffers, not just windows

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> I thought the test case was my header as on the From: in the header of
> this message that I am sending now.

No, your From header is perfect the way it is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no