Silencing noise (was: Re: Async package.el)

Silencing noise (was: Re: Async package.el)

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

2015-04-12 4:53 GMT+01:00 Stefan Monnier >> Maybe only print to the
compilation buffer, or only message when the
>> command was called interactively.
>
> Changing the behavior based on whether the call is interactive
> sounds like a good solution.
>
>
>         Stefan

Ok, I've pushed some general changes that should make the Package Menu a
lot more silent when operating in the background. Let me know if any are
not appropriate.

   - The byte-compiler will now avoid messaging if all is going well,
   unless one of its entry commands was called interactively.
   - autoloads.el wasn't changed. But, in order to silence it, package.el
   let-binds `noninteractive' around the call to update-directory-autoloads.

However, not everything was easy. In particular

   - Some messages happened very far from package.el. For instance, when we
   call customize-save-variable, that calls another function, which calls
   save-buffer. That will then chain through several other functions, with a
   few calls to message scattered around. The only sane way I found of
   silencing these messages was to introduce a global variable:
   `save-silently'. (Should this be documented anywhere?)
   The current behavior is to send (message nil) after every message, so
   that it is still printed to the messages buffer without showing up in the
   minibuffer. That can be changed, if desired, to prevent the message
   completely.
   - When saving buffers, there are some calls to write-region that are
   completely unsilenceable (because of a limitation of write-region's
   horribly overloaded VISIT argument). In these cases, I still managed to
   hide the message by doing (message nil) immediately afterwards, but there's
   no way to completely prevent them without changing write-region itself.

Cheers,
Artur

[-- Attachment #2: Type: text/html, Size: 1994 bytes --]

Re: Silencing noise

[Stefan Monnier]

On a related note, I think it would make sense to add a "message
redirection" variable, so that you can easily cause messages to be
redirected from the minibuffer elsewhere with a let-binding.


        Stefan

Re: Silencing noise

[Alexis]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> On a related note, I think it would make sense to add a "message 
> redirection" variable, so that you can easily cause messages to 
> be redirected from the minibuffer elsewhere with a let-binding.

+1. Yes please!


Alexis.

Re: Silencing noise

[raman]

Long-term it would be nice if message could be aware of the frame/thread
from where it was launched --- thinking forward to
concutrrent/multi-threaded emacs, it would be ideal if messages
displayed  from a thread running in a frame was limited to that frame. 

Food for thought: Should we in that world have a single *Messages*
buffer where all messages land up -- or a per-frame *Messages* buffer
with an additional Global-Messages buffer  that shows up everywhere --
that message queue could then  be sued to display truly urgent alerts
etc.


-- 

Re: Silencing noise

[Eli Zaretskii]

> From: raman <raman@google.com>
> Date: Mon, 13 Apr 2015 08:16:39 -0700
> Cc: emacs-devel@gnu.org
> 
> Long-term it would be nice if message could be aware of the frame/thread
> from where it was launched --- thinking forward to
> concutrrent/multi-threaded emacs, it would be ideal if messages
> displayed  from a thread running in a frame was limited to that frame. 

You are IMO making too many hidden assumptions about those, as yet
non-existing, future features, for example that there can be such a
thing as a "thread running on a frame".

To me, the most important objection to limiting a message to some
frame is that by the time the message is displayed that frame might no
longer be current/visible, and might not even exist.

> Food for thought: Should we in that world have a single *Messages*
> buffer where all messages land up -- or a per-frame *Messages* buffer
> with an additional Global-Messages buffer  that shows up everywhere --
> that message queue could then  be sued to display truly urgent alerts
> etc.

I'd like to see the concurrency branch revived and actively developed
to maturity, before I develop appetite for that kind of food.

Re: Silencing noise

[Stefan Monnier]

> I'd like to see the concurrency branch revived and actively developed
> to maturity,

Oh, yes,


        Stefan

Re: Silencing noise

[Stephen J. Turnbull]

raman writes:

 > thinking forward to concutrrent/multi-threaded emacs, it would be
 > ideal if messages displayed from a thread running in a frame was
 > limited to that frame.

Does that actually make sense?  The point of threads is shared state,
a thread might very well be accessing multiple buffers/frames.

 > Food for thought: Should we in that world have a single *Messages*
 > buffer where all messages land up -- or a per-frame *Messages*
 > buffer with an additional Global-Messages buffer that shows up
 > everywhere -- that message queue could then be sued to display
 > truly urgent alerts etc.

That's an interesting idea.

Re: Silencing noise

[T.V Raman]

Correct -- re a thread might be accessing multiple buffers / frames --
I was thinking more along the  lines of 

1. Messages displayed to the user should come from threads handling
the UI -- and roughly equated each thread of control to a user-visible
Frame (admittedly a very coarse granularity of threading but better
than the present)

and in that world,
2. Suggested that some app the user launches from a frame e.g. get
news, update packages etc should not cause UI changes such as
flickering messages in other frames where one i happily editting. 

Stephen J. Turnbull writes:
 > raman writes:
 > 
 >  > thinking forward to concutrrent/multi-threaded emacs, it would be
 >  > ideal if messages displayed from a thread running in a frame was
 >  > limited to that frame.
 > 
 > Does that actually make sense?  The point of threads is shared state,
 > a thread might very well be accessing multiple buffers/frames.
 > 
 >  > Food for thought: Should we in that world have a single *Messages*
 >  > buffer where all messages land up -- or a per-frame *Messages*
 >  > buffer with an additional Global-Messages buffer that shows up
 >  > everywhere -- that message queue could then be sued to display
 >  > truly urgent alerts etc.
 > 
 > That's an interesting idea.

-- 

-- 

Re: Silencing noise

[Eli Zaretskii]

> From: raman@google.com (T.V Raman)
> Date: Mon, 13 Apr 2015 09:37:07 -0700
> Cc: emacs-devel@gnu.org, flexibeast@gmail.com, raman@google.com
> 
> 1. Messages displayed to the user should come from threads handling
> the UI

The UI in Emacs is not handled by any Lisp code, so there cannot be
threads handling the UI without deep changes in the basic architecture
of Emacs.

Re: Silencing noise

[Achim Gratz]

Stefan Monnier writes:
> On a related note, I think it would make sense to add a "message
> redirection" variable, so that you can easily cause messages to be
> redirected from the minibuffer elsewhere with a let-binding.

My initial reaction is "yes, please!", but with a different hat on I'd
call that an attack vector.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada