[-- Attachment #1: Type: text/plain, Size: 215 bytes --] There is a standard face: error, which is red by default. Error messages in emacs should use it. It makes errors more conspicuous in the echo area and the Messages buffer, distinguishing them from regular messages. [-- Attachment #2: Type: text/html, Size: 272 bytes --]
ndame <ndame@protonmail.com> writes: > There is a standard face: error, which is red by default. > > Error messages in emacs should use it. It makes errors more conspicuous in > the echo area and the Messages buffer, distinguishing them from regular > messages. I think having Emacs using red for error message in the echo area etc would look pretty odd? Anybody got an opinion here? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi@gnus.org> writes:
> ndame <ndame@protonmail.com> writes:
>
>> There is a standard face: error, which is red by default.
>>
>> Error messages in emacs should use it. It makes errors more conspicuous in
>> the echo area and the Messages buffer, distinguishing them from regular
>> messages.
>
> I think having Emacs using red for error message in the echo area etc
> would look pretty odd? Anybody got an opinion here?
I agree, but in theory there could be a customisable face for this that
defaults to the current default.
But is it even possible to systematically tell whether a given message
corresponds to an error?
--
Basil
"Basil L. Contovounesios" <contovob@tcd.ie> writes: > I agree, but in theory there could be a customisable face for this that > defaults to the current default. That's true. > But is it even possible to systematically tell whether a given message > corresponds to an error? I imagined `error' (and `signal'?) putting a face on the return value from `format-message': (signal 'error (list (apply #'format-message args)))) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi@gnus.org> writes:
> ndame <ndame@protonmail.com> writes:
>
>> There is a standard face: error, which is red by default.
>>
>> Error messages in emacs should use it. It makes errors more conspicuous in
>> the echo area and the Messages buffer, distinguishing them from regular
>> messages.
>
> I think having Emacs using red for error message in the echo area etc
> would look pretty odd? Anybody got an opinion here?
It's hard to say without seeing it in practice.
I think having a face here would be interesting, even if it just looks
like the default face. That would open the door for experimentation in
third-party themes, and perhaps they will come up with some good ideas
that we will want to imitate.
(See also Bug#50785.)
Stefan Kangas <stefan@marxist.se> writes: > I think having a face here would be interesting, even if it just looks > like the default face. That would open the door for experimentation in > third-party themes, and perhaps they will come up with some good ideas > that we will want to imitate. Yes, that's a good point. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
> > I think having a face here would be interesting, even if it just
> > looks like the default face. That would open the door for
> > experimentation in third-party themes, and perhaps they will
> > come up with some good ideas that we will want to imitate.
>
> Yes, that's a good point.
I disagree. Globally imposing a single face here,
even if by default it is face `default', is quite
the wrong thing to do.
___
What should be done, I think:
Add a user option, defaulting to no change from
the traditional behavior, which causes error and
warning messages to preserve text properties on
the strings they use.
That lets code construct error messages using
any faces (or no faces) that it judges are
appropriate for a given context.
The option gives users control. By default
nothing is changed. The non-default option
value gives code control over the appearance.
___
I said the same thing long ago wrt minibuffer
prompting, and that was unfortunately ignored.
As a result we now have a blanket treatment:
a single face for all minibuffer prompts.
Emacs can easily, and should, do better. It
should provide more flexibility to code for
messaging.
___
I said the same thing long ago wrt completion
return values. This was partially implemented,
at least.
Code should be able to control the appearance
of text it uses when interacting with users.
And users should be able to override this or
(better) configure it.
Drew Adams <drew.adams@oracle.com> writes: > Add a user option, defaulting to no change from > the traditional behavior, which causes error and > warning messages to preserve text properties on > the strings they use. That's not what happens, see Bug#50785. > Code should be able to control the appearance > of text it uses when interacting with users. > And users should be able to override this or > (better) configure it. Having a face is exactly the way to give users control over what this looks like. Of course, the error face should not just remove any faces that are already there; that precludes making e.g. keybindings stand out with the `help-key-binding' face. So you would need to give the error-message face lower priority.
[-- Attachment #1: Type: text/plain, Size: 472 bytes --] > I think having Emacs using red for error message in the echo area etc would look pretty odd? Anybody got an opinion here? I don't think it looks odd, it just makes errors more conspicuous which is not a bad thing: (run-with-idle-timer 0 nil (lambda () (message (propertize "Error in post-command-hook (my-test-post-command): (args-out-of-range 0 1)" 'face 'error)))) But it can have its own face (error-message) to use by error and signal, so people can customize it. [-- Attachment #2: Type: text/html, Size: 801 bytes --]
Stefan Kangas <stefan@marxist.se> writes: > Of course, the error face should not just remove any faces that are > already there; that precludes making e.g. keybindings stand out with the > `help-key-binding' face. So you would need to give the error-message > face lower priority. I started poking at this a bit, and I realised that I've never actually seen an error message that has any kind of face. And that's because print_error_message uses princ on the strings we give error/signal, and princ discards all text properties. So there's nothing here to merge, really -- the strings, when they come out of Ferror_message_string, are property-less. I think. And users can already alter the look of the error message by just using command-error-function: (setq command-error-function (lambda (data _ _) (message "%s" (propertize (error-message-string data) 'face 'error)))) So I don't think there's anything much here to implement, really, unless we really want to start defaulting error messages to use a particular face. And I don't think we want that? So I'm adding some more pointers to command-error-function from relevant doc strings, because finding that variable wasn't trivial, and I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no