all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#38818: Dired: mention deleting buffers, not just windows
@ 2019-12-30 16:09 積丹尼 Dan Jacobson
  2019-12-30 17:53 ` martin rudalics
                   ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2019-12-30 16:09 UTC (permalink / raw)
  To: 38818

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"





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2019-12-30 16:09 bug#38818: Dired: mention deleting buffers, not just windows 積丹尼 Dan Jacobson
@ 2019-12-30 17:53 ` martin rudalics
  2019-12-30 18:11   ` 積丹尼 Dan Jacobson
  2019-12-31 17:33 ` Michael Heerdegen
  2020-01-22 12:51 ` Lars Ingebrigtsen
  2 siblings, 1 reply; 64+ messages in thread
From: martin rudalics @ 2019-12-30 17:53 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson, 38818

 > 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






^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2019-12-30 17:53 ` martin rudalics
@ 2019-12-30 18:11   ` 積丹尼 Dan Jacobson
  2019-12-31  7:59     ` martin rudalics
  0 siblings, 1 reply; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2019-12-30 18:11 UTC (permalink / raw)
  To: martin rudalics; +Cc: 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2019-12-30 18:11   ` 積丹尼 Dan Jacobson
@ 2019-12-31  7:59     ` martin rudalics
  0 siblings, 0 replies; 64+ messages in thread
From: martin rudalics @ 2019-12-31  7:59 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 38818

 > 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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2019-12-30 16:09 bug#38818: Dired: mention deleting buffers, not just windows 積丹尼 Dan Jacobson
  2019-12-30 17:53 ` martin rudalics
@ 2019-12-31 17:33 ` Michael Heerdegen
  2020-01-01  2:14   ` 積丹尼 Dan Jacobson
  2020-01-22 12:51 ` Lars Ingebrigtsen
  2 siblings, 1 reply; 64+ messages in thread
From: Michael Heerdegen @ 2019-12-31 17:33 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 38818

Hi Dan,

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

Michael.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2019-12-31 17:33 ` Michael Heerdegen
@ 2020-01-01  2:14   ` 積丹尼 Dan Jacobson
  2020-01-01  2:47     ` Michael Heerdegen
  0 siblings, 1 reply; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-01  2:14 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 38818

>>>>> "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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  2:14   ` 積丹尼 Dan Jacobson
@ 2020-01-01  2:47     ` Michael Heerdegen
  2020-01-01  3:07       ` 積丹尼 Dan Jacobson
  2020-01-01  6:47       ` Drew Adams
  0 siblings, 2 replies; 64+ messages in thread
From: Michael Heerdegen @ 2020-01-01  2:47 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 38818

積丹尼 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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  2:47     ` Michael Heerdegen
@ 2020-01-01  3:07       ` 積丹尼 Dan Jacobson
  2020-01-01  3:45         ` Michael Heerdegen
  2020-01-01  6:47       ` Drew Adams
  1 sibling, 1 reply; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-01  3:07 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 38818

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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  3:07       ` 積丹尼 Dan Jacobson
@ 2020-01-01  3:45         ` Michael Heerdegen
  2020-01-01  3:59           ` 積丹尼 Dan Jacobson
  0 siblings, 1 reply; 64+ messages in thread
From: Michael Heerdegen @ 2020-01-01  3:45 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 38818

積丹尼 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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  3:45         ` Michael Heerdegen
@ 2020-01-01  3:59           ` 積丹尼 Dan Jacobson
  2020-01-01  4:53             ` Michael Heerdegen
  2020-01-04 13:26             ` Noam Postavsky
  0 siblings, 2 replies; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-01  3:59 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 38818

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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  3:59           ` 積丹尼 Dan Jacobson
@ 2020-01-01  4:53             ` Michael Heerdegen
  2020-01-01  5:11               ` 積丹尼 Dan Jacobson
  2020-01-01 16:46               ` Pieter van Oostrum
  2020-01-04 13:26             ` Noam Postavsky
  1 sibling, 2 replies; 64+ messages in thread
From: Michael Heerdegen @ 2020-01-01  4:53 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 38818

積丹尼 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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  4:53             ` Michael Heerdegen
@ 2020-01-01  5:11               ` 積丹尼 Dan Jacobson
  2020-01-01  5:31                 ` Michael Heerdegen
  2020-01-01 16:46               ` Pieter van Oostrum
  1 sibling, 1 reply; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-01  5:11 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 38818

>> (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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  5:11               ` 積丹尼 Dan Jacobson
@ 2020-01-01  5:31                 ` Michael Heerdegen
  2020-01-01  6:53                   ` Drew Adams
  0 siblings, 1 reply; 64+ messages in thread
From: Michael Heerdegen @ 2020-01-01  5:31 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 38818

積丹尼 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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  2:47     ` Michael Heerdegen
  2020-01-01  3:07       ` 積丹尼 Dan Jacobson
@ 2020-01-01  6:47       ` Drew Adams
  1 sibling, 0 replies; 64+ messages in thread
From: Drew Adams @ 2020-01-01  6:47 UTC (permalink / raw)
  To: Michael Heerdegen, 積丹尼 Dan Jacobson; +Cc: 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  5:31                 ` Michael Heerdegen
@ 2020-01-01  6:53                   ` Drew Adams
  2020-01-01 14:38                     ` Noam Postavsky
  2020-01-01 23:18                     ` Richard Stallman
  0 siblings, 2 replies; 64+ messages in thread
From: Drew Adams @ 2020-01-01  6:53 UTC (permalink / raw)
  To: Michael Heerdegen, 積丹尼 Dan Jacobson; +Cc: 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  6:53                   ` Drew Adams
@ 2020-01-01 14:38                     ` Noam Postavsky
  2020-01-01 23:18                     ` Richard Stallman
  1 sibling, 0 replies; 64+ messages in thread
From: Noam Postavsky @ 2020-01-01 14:38 UTC (permalink / raw)
  To: Drew Adams
  Cc: Michael Heerdegen, 積丹尼 Dan Jacobson, 38818

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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  4:53             ` Michael Heerdegen
  2020-01-01  5:11               ` 積丹尼 Dan Jacobson
@ 2020-01-01 16:46               ` Pieter van Oostrum
  2020-01-02  4:14                 ` Michael Heerdegen
  2020-01-03 15:10                 ` 積丹尼 Dan Jacobson
  1 sibling, 2 replies; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-01 16:46 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 積丹尼 Dan Jacobson, 38818

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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  6:53                   ` Drew Adams
  2020-01-01 14:38                     ` Noam Postavsky
@ 2020-01-01 23:18                     ` Richard Stallman
  2020-01-02  3:29                       ` Drew Adams
  2020-01-11  9:40                       ` Eli Zaretskii
  1 sibling, 2 replies; 64+ messages in thread
From: Richard Stallman @ 2020-01-01 23:18 UTC (permalink / raw)
  To: Drew Adams; +Cc: michael_heerdegen, jidanni, 38818

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







^ permalink raw reply related	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01 23:18                     ` Richard Stallman
@ 2020-01-02  3:29                       ` Drew Adams
  2020-01-02 21:59                         ` Richard Stallman
  2020-01-11  9:40                       ` Eli Zaretskii
  1 sibling, 1 reply; 64+ messages in thread
From: Drew Adams @ 2020-01-02  3:29 UTC (permalink / raw)
  To: rms; +Cc: michael_heerdegen, jidanni, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01 16:46               ` Pieter van Oostrum
@ 2020-01-02  4:14                 ` Michael Heerdegen
  2020-01-03 15:10                 ` 積丹尼 Dan Jacobson
  1 sibling, 0 replies; 64+ messages in thread
From: Michael Heerdegen @ 2020-01-02  4:14 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: 積丹尼 Dan Jacobson, 38818

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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-02  3:29                       ` Drew Adams
@ 2020-01-02 21:59                         ` Richard Stallman
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Stallman @ 2020-01-02 21:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: michael_heerdegen, jidanni, 38818

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







^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01 16:46               ` Pieter van Oostrum
  2020-01-02  4:14                 ` Michael Heerdegen
@ 2020-01-03 15:10                 ` 積丹尼 Dan Jacobson
  2020-01-03 23:18                   ` Pieter van Oostrum
  1 sibling, 1 reply; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-03 15:10 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: Michael Heerdegen, 38818

>>>>> "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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-03 15:10                 ` 積丹尼 Dan Jacobson
@ 2020-01-03 23:18                   ` Pieter van Oostrum
  2020-01-03 23:31                     ` 積丹尼 Dan Jacobson
  0 siblings, 1 reply; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-03 23:18 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: Michael Heerdegen, 38818

積丹尼 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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-03 23:18                   ` Pieter van Oostrum
@ 2020-01-03 23:31                     ` 積丹尼 Dan Jacobson
  2020-01-03 23:51                       ` Pieter van Oostrum
  2020-01-04  6:16                       ` bug#38818: Dired: mention deleting buffers, not just windows Michael Heerdegen
  0 siblings, 2 replies; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-03 23:31 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: Michael Heerdegen, 38818

>>>>> "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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-03 23:31                     ` 積丹尼 Dan Jacobson
@ 2020-01-03 23:51                       ` Pieter van Oostrum
  2020-01-04  0:13                         ` 積丹尼 Dan Jacobson
  2020-01-04  6:16                       ` bug#38818: Dired: mention deleting buffers, not just windows Michael Heerdegen
  1 sibling, 1 reply; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-03 23:51 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: Michael Heerdegen, 38818

積丹尼 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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-03 23:51                       ` Pieter van Oostrum
@ 2020-01-04  0:13                         ` 積丹尼 Dan Jacobson
  2020-01-04 13:58                           ` Pieter van Oostrum
  2020-01-04 23:48                           ` Richard Stallman
  0 siblings, 2 replies; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-04  0:13 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: Michael Heerdegen, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-03 23:31                     ` 積丹尼 Dan Jacobson
  2020-01-03 23:51                       ` Pieter van Oostrum
@ 2020-01-04  6:16                       ` Michael Heerdegen
  2020-01-04 13:57                         ` Pieter van Oostrum
  1 sibling, 1 reply; 64+ messages in thread
From: Michael Heerdegen @ 2020-01-04  6:16 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: Pieter van Oostrum, 38818

積丹尼 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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01  3:59           ` 積丹尼 Dan Jacobson
  2020-01-01  4:53             ` Michael Heerdegen
@ 2020-01-04 13:26             ` Noam Postavsky
  1 sibling, 0 replies; 64+ messages in thread
From: Noam Postavsky @ 2020-01-04 13:26 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: Michael Heerdegen, 38818

積丹尼 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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-04  6:16                       ` bug#38818: Dired: mention deleting buffers, not just windows Michael Heerdegen
@ 2020-01-04 13:57                         ` Pieter van Oostrum
  2020-01-05 18:20                           ` 積丹尼 Dan Jacobson
  0 siblings, 1 reply; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-04 13:57 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 積丹尼 Dan Jacobson, 38818

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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-04  0:13                         ` 積丹尼 Dan Jacobson
@ 2020-01-04 13:58                           ` Pieter van Oostrum
  2020-01-04 23:48                           ` Richard Stallman
  1 sibling, 0 replies; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-04 13:58 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: Michael Heerdegen, 38818

積丹尼 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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-04  0:13                         ` 積丹尼 Dan Jacobson
  2020-01-04 13:58                           ` Pieter van Oostrum
@ 2020-01-04 23:48                           ` Richard Stallman
  2020-01-05  7:39                             ` Pieter van Oostrum
                                               ` (2 more replies)
  1 sibling, 3 replies; 64+ messages in thread
From: Richard Stallman @ 2020-01-04 23:48 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson
  Cc: michael_heerdegen, pieter-l, 38818

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







^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-04 23:48                           ` Richard Stallman
@ 2020-01-05  7:39                             ` Pieter van Oostrum
  2020-01-05 22:18                               ` Richard Stallman
  2020-01-05  8:06                             ` Pieter van Oostrum
  2020-01-05 22:21                             ` improvement in functions.texi Richard Stallman
  2 siblings, 1 reply; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-05  7:39 UTC (permalink / raw)
  To: Richard Stallman; +Cc: michael_heerdegen, Dan Jacobson, 38818

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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-04 23:48                           ` Richard Stallman
  2020-01-05  7:39                             ` Pieter van Oostrum
@ 2020-01-05  8:06                             ` Pieter van Oostrum
  2020-01-05 15:31                               ` Eli Zaretskii
  2020-01-05 22:21                             ` improvement in functions.texi Richard Stallman
  2 siblings, 1 reply; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-05  8:06 UTC (permalink / raw)
  To: Richard Stallman; +Cc: michael_heerdegen, Dan Jacobson, 38818

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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-05  8:06                             ` Pieter van Oostrum
@ 2020-01-05 15:31                               ` Eli Zaretskii
  2020-01-05 18:19                                 ` 積丹尼 Dan Jacobson
  0 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-05 15:31 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: michael_heerdegen, jidanni, rms, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-05 15:31                               ` Eli Zaretskii
@ 2020-01-05 18:19                                 ` 積丹尼 Dan Jacobson
  2020-01-05 18:48                                   ` Eli Zaretskii
  2020-01-05 22:19                                   ` bug#38818: Dired: mention deleting buffers, not just windows Richard Stallman
  0 siblings, 2 replies; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-05 18:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, Pieter van Oostrum, rms, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-04 13:57                         ` Pieter van Oostrum
@ 2020-01-05 18:20                           ` 積丹尼 Dan Jacobson
  0 siblings, 0 replies; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-05 18:20 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: Michael Heerdegen, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-05 18:19                                 ` 積丹尼 Dan Jacobson
@ 2020-01-05 18:48                                   ` Eli Zaretskii
  2020-01-05 19:09                                     ` bug#38818: jidanni's mail headers not perfect?! 積丹尼 Dan Jacobson
  2020-01-05 22:19                                   ` bug#38818: Dired: mention deleting buffers, not just windows Richard Stallman
  1 sibling, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-05 18:48 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson
  Cc: michael_heerdegen, pieter-l, rms, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-05 18:48                                   ` Eli Zaretskii
@ 2020-01-05 19:09                                     ` 積丹尼 Dan Jacobson
  2020-01-05 19:33                                       ` Eli Zaretskii
  0 siblings, 1 reply; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-05 19:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, larsi, pieter-l, rms, 38818

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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-05 19:09                                     ` bug#38818: jidanni's mail headers not perfect?! 積丹尼 Dan Jacobson
@ 2020-01-05 19:33                                       ` Eli Zaretskii
  2020-01-05 20:48                                         ` Pieter van Oostrum
  2020-01-06  8:30                                         ` Andreas Schwab
  0 siblings, 2 replies; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-05 19:33 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson
  Cc: michael_heerdegen, larsi, pieter-l, rms, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-05 19:33                                       ` Eli Zaretskii
@ 2020-01-05 20:48                                         ` Pieter van Oostrum
  2020-01-06  3:26                                           ` Eli Zaretskii
  2020-01-06  8:30                                         ` Andreas Schwab
  1 sibling, 1 reply; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-05 20:48 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: michael_heerdegen, larsi, 積丹尼 Dan Jacobson,
	rms, 38818

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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-05  7:39                             ` Pieter van Oostrum
@ 2020-01-05 22:18                               ` Richard Stallman
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Stallman @ 2020-01-05 22:18 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: michael_heerdegen, jidanni, 38818

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







^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-05 18:19                                 ` 積丹尼 Dan Jacobson
  2020-01-05 18:48                                   ` Eli Zaretskii
@ 2020-01-05 22:19                                   ` Richard Stallman
  2020-01-05 23:30                                     ` 積丹尼 Dan Jacobson
  2020-01-06  3:32                                     ` Eli Zaretskii
  1 sibling, 2 replies; 64+ messages in thread
From: Richard Stallman @ 2020-01-05 22:19 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson
  Cc: michael_heerdegen, pieter-l, 38818

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







^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: improvement in functions.texi
  2020-01-04 23:48                           ` Richard Stallman
  2020-01-05  7:39                             ` Pieter van Oostrum
  2020-01-05  8:06                             ` Pieter van Oostrum
@ 2020-01-05 22:21                             ` Richard Stallman
  2020-01-11  9:49                               ` Eli Zaretskii
  2 siblings, 1 reply; 64+ messages in thread
From: Richard Stallman @ 2020-01-05 22:21 UTC (permalink / raw)
  To: emacs-devel; +Cc: michael_heerdegen, pieter-l, jidanni

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-05 22:19                                   ` bug#38818: Dired: mention deleting buffers, not just windows Richard Stallman
@ 2020-01-05 23:30                                     ` 積丹尼 Dan Jacobson
  2020-01-06  3:32                                     ` Eli Zaretskii
  1 sibling, 0 replies; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-05 23:30 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: michael_heerdegen, 38818

積丹尼 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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-05 20:48                                         ` Pieter van Oostrum
@ 2020-01-06  3:26                                           ` Eli Zaretskii
  2020-01-06  9:56                                             ` Pieter van Oostrum
  0 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-06  3:26 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: michael_heerdegen, larsi, jidanni, rms, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-05 22:19                                   ` bug#38818: Dired: mention deleting buffers, not just windows Richard Stallman
  2020-01-05 23:30                                     ` 積丹尼 Dan Jacobson
@ 2020-01-06  3:32                                     ` Eli Zaretskii
  2020-01-06 23:08                                       ` Richard Stallman
  1 sibling, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-06  3:32 UTC (permalink / raw)
  To: rms; +Cc: michael_heerdegen, pieter-l, jidanni, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-05 19:33                                       ` Eli Zaretskii
  2020-01-05 20:48                                         ` Pieter van Oostrum
@ 2020-01-06  8:30                                         ` Andreas Schwab
  2020-01-06  8:50                                           ` Eli Zaretskii
  1 sibling, 1 reply; 64+ messages in thread
From: Andreas Schwab @ 2020-01-06  8:30 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: pieter-l, rms, michael_heerdegen,
	積丹尼 Dan Jacobson, larsi, 38818

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."





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-06  8:30                                         ` Andreas Schwab
@ 2020-01-06  8:50                                           ` Eli Zaretskii
  2020-01-06  9:23                                             ` Andreas Schwab
  0 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-06  8:50 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: pieter-l, rms, michael_heerdegen,
	積丹尼 Dan Jacobson, larsi, 38818

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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-06  8:50                                           ` Eli Zaretskii
@ 2020-01-06  9:23                                             ` Andreas Schwab
  2020-01-06 10:02                                               ` Eli Zaretskii
  0 siblings, 1 reply; 64+ messages in thread
From: Andreas Schwab @ 2020-01-06  9:23 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: pieter-l, rms, michael_heerdegen,
	積丹尼 Dan Jacobson, larsi, 38818

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."





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-06  3:26                                           ` Eli Zaretskii
@ 2020-01-06  9:56                                             ` Pieter van Oostrum
  2020-01-06 10:09                                               ` Eli Zaretskii
  0 siblings, 1 reply; 64+ messages in thread
From: Pieter van Oostrum @ 2020-01-06  9:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, larsi, jidanni, rms, 38818

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]





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-06  9:23                                             ` Andreas Schwab
@ 2020-01-06 10:02                                               ` Eli Zaretskii
  2020-01-06 10:13                                                 ` Andreas Schwab
  0 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-06 10:02 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: pieter-l, rms, michael_heerdegen,
	積丹尼 Dan Jacobson, larsi, 38818

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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-06  9:56                                             ` Pieter van Oostrum
@ 2020-01-06 10:09                                               ` Eli Zaretskii
  2020-01-06 10:16                                                 ` Andreas Schwab
  0 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-06 10:09 UTC (permalink / raw)
  To: Pieter van Oostrum; +Cc: michael_heerdegen, larsi, jidanni, rms, 38818

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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-06 10:02                                               ` Eli Zaretskii
@ 2020-01-06 10:13                                                 ` Andreas Schwab
  0 siblings, 0 replies; 64+ messages in thread
From: Andreas Schwab @ 2020-01-06 10:13 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: pieter-l, rms, michael_heerdegen,
	積丹尼 Dan Jacobson, larsi, 38818

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."





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: jidanni's mail headers not perfect?!
  2020-01-06 10:09                                               ` Eli Zaretskii
@ 2020-01-06 10:16                                                 ` Andreas Schwab
  0 siblings, 0 replies; 64+ messages in thread
From: Andreas Schwab @ 2020-01-06 10:16 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Pieter van Oostrum, rms, michael_heerdegen, jidanni, larsi, 38818

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."





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-06  3:32                                     ` Eli Zaretskii
@ 2020-01-06 23:08                                       ` Richard Stallman
  2020-01-07 15:42                                         ` Bad RFC 2047 decoding in Rmail Eli Zaretskii
  2020-01-22 12:47                                         ` bug#38818: Dired: mention deleting buffers, not just windows Lars Ingebrigtsen
  0 siblings, 2 replies; 64+ messages in thread
From: Richard Stallman @ 2020-01-06 23:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, pieter-l, jidanni, 38818

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







^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: Bad RFC 2047 decoding in Rmail
  2020-01-06 23:08                                       ` Richard Stallman
@ 2020-01-07 15:42                                         ` Eli Zaretskii
  2020-01-07 17:35                                           ` Stefan Monnier
  2020-01-22 12:47                                         ` bug#38818: Dired: mention deleting buffers, not just windows Lars Ingebrigtsen
  1 sibling, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-07 15:42 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: Bad RFC 2047 decoding in Rmail
  2020-01-07 15:42                                         ` Bad RFC 2047 decoding in Rmail Eli Zaretskii
@ 2020-01-07 17:35                                           ` Stefan Monnier
  2020-01-07 23:49                                             ` Richard Stallman
  0 siblings, 1 reply; 64+ messages in thread
From: Stefan Monnier @ 2020-01-07 17:35 UTC (permalink / raw)
  To: rms; +Cc: Eli Zaretskii, emacs-devel

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




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: Bad RFC 2047 decoding in Rmail
  2020-01-07 17:35                                           ` Stefan Monnier
@ 2020-01-07 23:49                                             ` Richard Stallman
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Stallman @ 2020-01-07 23:49 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: eliz, 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. ]]]

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-01 23:18                     ` Richard Stallman
  2020-01-02  3:29                       ` Drew Adams
@ 2020-01-11  9:40                       ` Eli Zaretskii
  1 sibling, 0 replies; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-11  9:40 UTC (permalink / raw)
  To: rms; +Cc: michael_heerdegen, jidanni, 38818

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: improvement in functions.texi
  2020-01-05 22:21                             ` improvement in functions.texi Richard Stallman
@ 2020-01-11  9:49                               ` Eli Zaretskii
  0 siblings, 0 replies; 64+ messages in thread
From: Eli Zaretskii @ 2020-01-11  9:49 UTC (permalink / raw)
  To: rms; +Cc: michael_heerdegen, pieter-l, jidanni, emacs-devel

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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-06 23:08                                       ` Richard Stallman
  2020-01-07 15:42                                         ` Bad RFC 2047 decoding in Rmail Eli Zaretskii
@ 2020-01-22 12:47                                         ` Lars Ingebrigtsen
  2020-01-22 13:17                                           ` 積丹尼 Dan Jacobson
  1 sibling, 1 reply; 64+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-22 12:47 UTC (permalink / raw)
  To: Richard Stallman; +Cc: michael_heerdegen, pieter-l, 38818, jidanni

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





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2019-12-30 16:09 bug#38818: Dired: mention deleting buffers, not just windows 積丹尼 Dan Jacobson
  2019-12-30 17:53 ` martin rudalics
  2019-12-31 17:33 ` Michael Heerdegen
@ 2020-01-22 12:51 ` Lars Ingebrigtsen
  2 siblings, 0 replies; 64+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-22 12:51 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 38818

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






^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-22 12:47                                         ` bug#38818: Dired: mention deleting buffers, not just windows Lars Ingebrigtsen
@ 2020-01-22 13:17                                           ` 積丹尼 Dan Jacobson
  2020-01-22 13:19                                             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 64+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-01-22 13:17 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: michael_heerdegen, pieter-l, Richard Stallman, 38818

>>>>> "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.





^ permalink raw reply	[flat|nested] 64+ messages in thread

* bug#38818: Dired: mention deleting buffers, not just windows
  2020-01-22 13:17                                           ` 積丹尼 Dan Jacobson
@ 2020-01-22 13:19                                             ` Lars Ingebrigtsen
  0 siblings, 0 replies; 64+ messages in thread
From: Lars Ingebrigtsen @ 2020-01-22 13:19 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson
  Cc: michael_heerdegen, pieter-l, Richard Stallman, 38818

積丹尼 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





^ permalink raw reply	[flat|nested] 64+ messages in thread

end of thread, other threads:[~2020-01-22 13:19 UTC | newest]

Thread overview: 64+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-12-30 16:09 bug#38818: Dired: mention deleting buffers, not just windows 積丹尼 Dan Jacobson
2019-12-30 17:53 ` martin rudalics
2019-12-30 18:11   ` 積丹尼 Dan Jacobson
2019-12-31  7:59     ` martin rudalics
2019-12-31 17:33 ` Michael Heerdegen
2020-01-01  2:14   ` 積丹尼 Dan Jacobson
2020-01-01  2:47     ` Michael Heerdegen
2020-01-01  3:07       ` 積丹尼 Dan Jacobson
2020-01-01  3:45         ` Michael Heerdegen
2020-01-01  3:59           ` 積丹尼 Dan Jacobson
2020-01-01  4:53             ` Michael Heerdegen
2020-01-01  5:11               ` 積丹尼 Dan Jacobson
2020-01-01  5:31                 ` Michael Heerdegen
2020-01-01  6:53                   ` Drew Adams
2020-01-01 14:38                     ` Noam Postavsky
2020-01-01 23:18                     ` Richard Stallman
2020-01-02  3:29                       ` Drew Adams
2020-01-02 21:59                         ` Richard Stallman
2020-01-11  9:40                       ` Eli Zaretskii
2020-01-01 16:46               ` Pieter van Oostrum
2020-01-02  4:14                 ` Michael Heerdegen
2020-01-03 15:10                 ` 積丹尼 Dan Jacobson
2020-01-03 23:18                   ` Pieter van Oostrum
2020-01-03 23:31                     ` 積丹尼 Dan Jacobson
2020-01-03 23:51                       ` Pieter van Oostrum
2020-01-04  0:13                         ` 積丹尼 Dan Jacobson
2020-01-04 13:58                           ` Pieter van Oostrum
2020-01-04 23:48                           ` Richard Stallman
2020-01-05  7:39                             ` Pieter van Oostrum
2020-01-05 22:18                               ` Richard Stallman
2020-01-05  8:06                             ` Pieter van Oostrum
2020-01-05 15:31                               ` Eli Zaretskii
2020-01-05 18:19                                 ` 積丹尼 Dan Jacobson
2020-01-05 18:48                                   ` Eli Zaretskii
2020-01-05 19:09                                     ` bug#38818: jidanni's mail headers not perfect?! 積丹尼 Dan Jacobson
2020-01-05 19:33                                       ` Eli Zaretskii
2020-01-05 20:48                                         ` Pieter van Oostrum
2020-01-06  3:26                                           ` Eli Zaretskii
2020-01-06  9:56                                             ` Pieter van Oostrum
2020-01-06 10:09                                               ` Eli Zaretskii
2020-01-06 10:16                                                 ` Andreas Schwab
2020-01-06  8:30                                         ` Andreas Schwab
2020-01-06  8:50                                           ` Eli Zaretskii
2020-01-06  9:23                                             ` Andreas Schwab
2020-01-06 10:02                                               ` Eli Zaretskii
2020-01-06 10:13                                                 ` Andreas Schwab
2020-01-05 22:19                                   ` bug#38818: Dired: mention deleting buffers, not just windows Richard Stallman
2020-01-05 23:30                                     ` 積丹尼 Dan Jacobson
2020-01-06  3:32                                     ` Eli Zaretskii
2020-01-06 23:08                                       ` Richard Stallman
2020-01-07 15:42                                         ` Bad RFC 2047 decoding in Rmail Eli Zaretskii
2020-01-07 17:35                                           ` Stefan Monnier
2020-01-07 23:49                                             ` Richard Stallman
2020-01-22 12:47                                         ` bug#38818: Dired: mention deleting buffers, not just windows Lars Ingebrigtsen
2020-01-22 13:17                                           ` 積丹尼 Dan Jacobson
2020-01-22 13:19                                             ` Lars Ingebrigtsen
2020-01-05 22:21                             ` improvement in functions.texi Richard Stallman
2020-01-11  9:49                               ` Eli Zaretskii
2020-01-04  6:16                       ` bug#38818: Dired: mention deleting buffers, not just windows Michael Heerdegen
2020-01-04 13:57                         ` Pieter van Oostrum
2020-01-05 18:20                           ` 積丹尼 Dan Jacobson
2020-01-04 13:26             ` Noam Postavsky
2020-01-01  6:47       ` Drew Adams
2020-01-22 12:51 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.