bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives


From: Eli Zaretskii
Subject: bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives error
Date: Thu, 12 Oct 2017 16:44:53 +0300

> From: Kaushal Modi <address@hidden>
> Date: Thu, 12 Oct 2017 13:31:49 +0000
> Cc: address@hidden, address@hidden, address@hidden
> 
>  FWIW, I see no problem with the error message, we produce such error
>  messages in quite a few other places in fileio.c.  The capitalization
>  seems okay, too.
> 
> OK, but it seems non-standard compared to error messages from Elisp land.

When the error comes from a primitive, and quotes a system error
message, it always looks like this.  E.g., try evaluating this:

  (insert-file-contents "no-such-file")

> Shouldn't
> 
> (file-error Non-regular file Is a directory /home/kmodi/.emacs.d/foo)
> 
> look like:
> 
> file-error: Non-regular file: /home/kmodi/.emacs.d/foo is a directory

No, we put the file last because there could be a list of additional
objects to print.

> - Why those parentheses?

It depends on how did you get the error and where did you pick it up
from: echo area, *Messages*, *scratch*, something else?

> - Why are "N" and "I" capitalized in-between that "sentence".. error messages 
> are usually sentences without
> ending in period, right?

The "error message" in this case is concocted from several parts, each
one has its own capitalization.  We used to lower-case some of that,
but doing sop has its own problems, because the system error messages
can be localized.

> - Above instead looks like a list printed with 3 elements.

That's because it is.

> Also, the error is not-informative.. the user is trying to trash foo/ and 
> knows that foo/ is a directory.. so how
> would
> 
> (file-error Non-regular file Is a directory /home/kmodi/.emacs.d/foo) 
> 
> help?

It tells you that /home/kmodi/.emacs.d/foo is a directory, not a
regular file.

I'm not saying that the message couldn't be improved, but doing so is
only possible in move-file-to-trash, not in primitives below it.

>  As for lack of backtrace, that's because the error comes from a C
>  primitive.
> 
> For the lack of better understanding, isn't it possible to set the "severity" 
> of certain messages to be of Error
> status (or something like that), so that a backtrace automatically analogous 
> to what I get on my
> above-mentioned debug-on-message setting?

What you see _is_ an error already.

Once again, I think this issue should be resolved so as not to fail
file deletion, but let's not muddy the waters by unrelated aspects,
such as the error message formatting, which works as designed here.
the real problem is elsewhere.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]