From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Carlos Pita Newsgroups: gmane.emacs.bugs Subject: bug#37826: Very annoying autoraise client/server behavior with -t option Date: Sun, 27 Oct 2019 14:19:51 -0300 Message-ID: References: <83tv84540m.fsf@gnu.org> <83v9si2y9u.fsf@gnu.org> <83a79u2oih.fsf@gnu.org> <83y2xe12ut.fsf@gnu.org> <83r23610oc.fsf@gnu.org> <83ftjfvkov.fsf@gnu.org> <83imobtjnc.fsf@gnu.org> <834kzuu5ir.fsf@gnu.org> <83zhhmsp39.fsf@gnu.org> <83mudmryrj.fsf@gnu.org> <83imoarvri.fsf@gnu.org> <83h83uru8e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="65937"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Juanma Barranquero , 37826@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 27 18:21:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iOmE7-000GzR-Mu for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 18:21:15 +0100 Original-Received: from localhost ([::1]:46080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOmE5-0002ay-TX for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 13:21:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56403) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOmDv-0002Vr-P9 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 13:21:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOmDu-000074-JC for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 13:21:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34668) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iOmDu-00006u-E4 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 13:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iOmDu-0005iM-6d for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 13:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2019 17:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37826 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 37826-submit@debbugs.gnu.org id=B37826.157219681121867 (code B ref 37826); Sun, 27 Oct 2019 17:21:02 +0000 Original-Received: (at 37826) by debbugs.gnu.org; 27 Oct 2019 17:20:11 +0000 Original-Received: from localhost ([127.0.0.1]:43489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOmD4-0005gc-O4 for submit@debbugs.gnu.org; Sun, 27 Oct 2019 13:20:10 -0400 Original-Received: from mail-yw1-f49.google.com ([209.85.161.49]:33778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOmD2-0005gM-JX for 37826@debbugs.gnu.org; Sun, 27 Oct 2019 13:20:08 -0400 Original-Received: by mail-yw1-f49.google.com with SMTP id w140so3015276ywd.0 for <37826@debbugs.gnu.org>; Sun, 27 Oct 2019 10:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SpLXL6gfWzt5hFLLQbpeyI38OIaL6omaTgNhWTbhZmw=; b=cuPhGWk9zoH4qcPDJimFEpEf1txP3TawiL2t+EeYIIBlUAmM2sB/zr+Xb3zYSOn8qC uZOIBsVAa/5x4dvfmMwwV34fhrMv75rExs3YX0/Kh0q0UnNKxnkUNGfqCyr7mWyN7fH9 EWfCAbqhYmAhrKCGda5UqIxv7sxMWEdLmyZqiyYQdbS860zzXddo6vqohYz28ZolQuDn cuvjj5fQbS4agmmar0oZIcnzjdo8QtytCsze9hfMZF2n8KnZmD1gg9Us2dcCytxfuH0b Q5f8CvZDSy+zFFzoHjFhJQwGdfZXk5BKrewJdi5G4hMiFMQ92rIae4CdagJqwDxJJXtc aj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SpLXL6gfWzt5hFLLQbpeyI38OIaL6omaTgNhWTbhZmw=; b=cbVqrfLk7T+/u/V4NDyyq26giip+4UBMOIEz2LJhuGmYgeyjjlC4eGoBPOVAdzJf+w f8ZNh7psc2tlp8B1618AO3YIqClSY0U9p+3A2Xoa/3e2TF7/qCVZwB3zDjS1+PmoaBuK wKMK9ipondWbhwna4eaqxr84oITQeAhzbGp68W8rHGwsD5v5JYv9cNDIFtRKbx5YDlVe vOnYsNf90zgWPGGi68RbWzr/FYjsJgGhfqPIozx3HJmEqeibfhBS73APZonlUQh2BD77 CLtZjZQjS1En9THF4u1TtVuoqVeE9VYBy+D5O4u6+l0B72PXlrGL2FHIXogPhW+lQQQ9 K/Kg== X-Gm-Message-State: APjAAAXle6Rm2le0NivD9akH28+n2Faa5YWBwkUA7R59AzOwlFI27zG4 7SqiDMbScizE6BjYe6BCAO1AbiORdyncTKJYkpQ= X-Google-Smtp-Source: APXvYqyf8nUc0i7QJvgbiRODvd5J9X95wjzP8aoCnvZnAdls3N+vKdP4B+APzjiAb3rpv5noZLUjshdOk9GVqJjhKhM= X-Received: by 2002:a81:9a16:: with SMTP id r22mr9687762ywg.277.1572196802874; Sun, 27 Oct 2019 10:20:02 -0700 (PDT) In-Reply-To: <83h83uru8e.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170263 Archived-At: > We want a solution that avoids raising the wrong frame for some > unimportant messages, but still does raise some frame for displaying > important messages, such as errors. If that doesn't happen in some > scenario, then we cannot use this idea. Temporarily redirecting the output of message was a solution that fitted that description: * Questions are still asked. * Errors still raise some frame with a message. And then, at the end, you get a dump of all temporarily silenced messages in the right frame. You dislike the instrumenting/monkey-patching approach, be it by advicing or by directly accessing the function slot of the symbol. I'm not sure why, message is a function with a simple and well defined interface that I'm honouring except for its side effect, and everything is carefully done inside an unwind-protect clause. But, in any case, we could add some global flag or something that message could check in order to change its output destination. That wouldn't be an instrumentation. But I find that considerably more complex and it affects the overall behavior of message instead of just mocking it for a while.