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

[Eli Zaretskii <eliz@gnu.org>]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 12 Oct 2017 13:31:49 +0000
> Cc: self@gkayaalp.com, eggert@cs.ucla.edu, 28792@debbugs.gnu.org
> 
>  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.