From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Silencing noise (was: Re: Async package.el) Date: Sun, 12 Apr 2015 16:20:42 +0100 Message-ID: Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e012291a267889d0513888ade X-Trace: ger.gmane.org 1428852061 25232 80.91.229.3 (12 Apr 2015 15:21:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Apr 2015 15:21:01 +0000 (UTC) Cc: raman , emacs-devel , Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 12 17:21:00 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YhJgw-0003C5-UJ for ged-emacs-devel@m.gmane.org; Sun, 12 Apr 2015 17:20:59 +0200 Original-Received: from localhost ([::1]:45578 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhJgv-0007LN-RC for ged-emacs-devel@m.gmane.org; Sun, 12 Apr 2015 11:20:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhJgi-0007HT-Ed for emacs-devel@gnu.org; Sun, 12 Apr 2015 11:20:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhJgh-000664-B0 for emacs-devel@gnu.org; Sun, 12 Apr 2015 11:20:44 -0400 Original-Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:35841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhJgg-00065u-U4 for emacs-devel@gnu.org; Sun, 12 Apr 2015 11:20:43 -0400 Original-Received: by lbbqq2 with SMTP id qq2so42595659lbb.3 for ; Sun, 12 Apr 2015 08:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:message-id:subject:from:to:cc :content-type; bh=qYGC1AbK8/ZIjmbzuHEnTbnRxXnnQ7jb0bvP8dmhhHI=; b=FvHt1W7rEfrndNFEumeQsk/RaWQdUwG32mWE3zpydJm0jjzxiqVBC8b6hzZJ4ZWao4 CNn/jcpHQbIkf2KnLhRMjkzrLvxeRn1nfosCHSTnlIBj4CiYgryF0g/Yq5EeUruaFtPO 66wDNhg22QZUCGj5Ggxi6SXgvHyaSH/gGsS7Mv2SKVQSvgtvoeDWO8f9kuXLbvt1ST4q WzrOFJ9aM1X41mCMhPtsxEdZlf4jvJC5QuuCo3PcEUN68ncUUL/JXSsLR9APOIgkhtvA vlLkKv5JDEwta76Sp52inTEywMIAISDYkMmmN3uaHa2E5D03OGSpyVQyWOHYuJKyVcXB 6yDw== X-Received: by 10.152.2.105 with SMTP id 9mr7811471lat.16.1428852042072; Sun, 12 Apr 2015 08:20:42 -0700 (PDT) Original-Received: by 10.25.150.131 with HTTP; Sun, 12 Apr 2015 08:20:42 -0700 (PDT) X-Google-Sender-Auth: _0icraP-tJpjQYyt1iR088v9eCM X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185342 Archived-At: --089e012291a267889d0513888ade Content-Type: text/plain; charset=UTF-8 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 --089e012291a267889d0513888ade Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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.
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

Ok, I've pushed some general changes that should make the Packag= e Menu a lot more silent when operating in the background. Let me know if a= ny 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.e= l let-binds `noninteractive' around the call to update-directory-autolo= ads.

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 c= alls to message scattered around. The only sane way I found of silencing th= ese messages was to introduce a global variable: `save-silently'. (Shou= ld 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 minibu= ffer. That can be changed, if desired, to prevent the message completely. <= /li>
  • When saving buffers, there are some calls to write-region that are comp= letely unsilenceable (because of a limitation of write-region's horribl= y overloaded VISIT argument). In these cases, I still managed to hide the = message by doing (message nil) immediately afterwards, but there's no w= ay to completely prevent them without changing write-region itself.

Cheers,
Artur

--089e012291a267889d0513888ade--