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 12:04:37 -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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000571e1d0595e5b424" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="177257"; 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 16:05:11 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 1iOk6R-000k0O-0E for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 16:05:11 +0100 Original-Received: from localhost ([::1]:45600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOk6P-0007io-Rb for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 11:05:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36164) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOk6K-0007QZ-34 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 11:05:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOk6I-0005Fb-Td for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 11:05:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34561) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iOk6I-0005FO-R9 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 11:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iOk6I-00023i-H6 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 11:05: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 15:05: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.15721886987895 (code B ref 37826); Sun, 27 Oct 2019 15:05:02 +0000 Original-Received: (at 37826) by debbugs.gnu.org; 27 Oct 2019 15:04:58 +0000 Original-Received: from localhost ([127.0.0.1]:43382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOk6C-00023E-N5 for submit@debbugs.gnu.org; Sun, 27 Oct 2019 11:04:58 -0400 Original-Received: from mail-yb1-f172.google.com ([209.85.219.172]:41750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOk6B-000230-6N for 37826@debbugs.gnu.org; Sun, 27 Oct 2019 11:04:55 -0400 Original-Received: by mail-yb1-f172.google.com with SMTP id 206so3155615ybc.8 for <37826@debbugs.gnu.org>; Sun, 27 Oct 2019 08:04:55 -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=VQt9QR/xDrMC5C99NruSF4RRcXODyNY8coQwU5G+Bkg=; b=sNur4m8q74uJWPnyqhXyUrOVfFup+Wk72neFmJQWlNOl3mPzDRBfwY57KpBRAqZYJO Nt/PIYhNefTXw0Xzqy1V5jnyqiea11bj1xviTSUYlDhCHqVm/o5Bdw7zaI0QtZJTp01s E2Tj3WtYSiEHPOMaQg8I3A4pz5Db58pmCm/DC8KI4l4Y6EPxqZ4RxYmZU07NL1zLLrVX EyYyvUGqC1jSV5uhUEgqto6heaZzwhw00a4hvIbravhhyyLlzg/SzVbXJbraccAAdYQZ VDS58GQ4JGxeKK7BdZq2ohJJmD2bUrcExjjLujcLGLRDz7RbKLDXiQfK+s4dE8ilNcFX Ie5A== 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=VQt9QR/xDrMC5C99NruSF4RRcXODyNY8coQwU5G+Bkg=; b=dzp+GbRSANUNTKyCzlGdbkmbVlQ47UINWCfUNwyen5xoHS9z5rbRnQYOMVr2bsndSw jXngjxBsdQP1cJSCGeH6YpJ3cWDwii01o8TmUJV0LbmqeVPM1YYqprvwahILSdetS9kf 67LjuSx2A4v5Czqt84tiSa8V1kfwY+ElahndyoJBRB1M53QXVd/XfYD8Fx2oAWmvJoPc yUeJunjURSdxS42QkJf4AotfVb3f+OO2Ldyl73foTQ3TjKdvhYgUKIqbPbz2ZEKdiFoR JUk8ifB56pGPAgcHWsyAPqAqNn813YqTUeDpfUIbkuc6JRCU3k8m6Ww6TrQYmCWzDXWC xuuw== X-Gm-Message-State: APjAAAVOXxlpncD04xRQcJsvn4uIk9AHnjJ9JI/JGEwpBMCnJt+mvnxi OJI5VFNRJvWfGM4xXqLwP1lfkSv7/cJLtu+0gNY= X-Google-Smtp-Source: APXvYqzhXqa1xTEBsF9G97YY6ojPy8nxZyoJ5/J1CIUjmbpMi/n/SdCcxR6EnLWaa8dsggaXAAvxP9xeIOSCnEAO3KI= X-Received: by 2002:a25:42:: with SMTP id 63mr10901198yba.454.1572188689209; Sun, 27 Oct 2019 08:04:49 -0700 (PDT) In-Reply-To: <83zhhmsp39.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:170250 Archived-At: --000000000000571e1d0595e5b424 Content-Type: text/plain; charset="UTF-8" > > ). This change is similar to my first patch except that mine > > also covered the handful of hooks surrounding that part. > > Most importantly, it affected the question we ask there if the file is > gone. > I don't think so, my first patch set the (let* ((minibuffer-auto-raise (or server-raise-frame minibuffer-auto-raise)) environment specifically for those questions, instead of also affecting everything else. Now you keep the "raisy" environment for everything else, but disable it specifically for find-file-noselect. My approach was more risky in the sense that it could have masked more situations requiring intervention than yours, but the risk is still there, it's just a different type I vs type II error trade-off. > You mean, errors inside find-file-noselect? Maybe I'm missing > something, but I'd expect such an error to be displayed as usual. Can > you simulate an error there and see what happens? > I probably couldn't find a situation requiring intervention for the random examples I would pick now, I admit it would be a rare case, but there are tons of minor and major modes out there and some of them might ask some questions at startup. It comes to my mind that pdf-tools sometimes wants to recompile it's C part after an upgrade, but AFAICR this is done when the server starts and not when the file is visited, so the question is lost in the stdout of the daemon, which is an instance of a closely related issue. > > --000000000000571e1d0595e5b424 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
). This change is similar to my first patch except that mine
> also covered the handful of hooks surrounding that part.

Most importantly, it affected the question we ask there if the file is
gone.

I don't think so, my first patch set the
(let* ((minibuffer-auto-raise (or server-raise-fr= ame minibuffer-auto-raise))

environment specifically for those questions, instead of also affecting= everything else. Now you keep the "raisy" environment for everyt= hing else, but disable it specifically for find-file-noselect. My approach = was more risky in the sense that it could have masked more situations requi= ring intervention than yours, but the risk is still there, it's just a = different type I vs type II error trade-off.


You mean, errors inside find-file-noselect?=C2=A0 Maybe I'm missing
something, but I'd expect such an error to be displayed as usual.=C2=A0= Can
you simulate an error there and see what happens?

I probably couldn't fi= nd a situation requiring intervention for the random examples I would pick = now, I admit it would be a rare case, but there are tons of minor and major= modes out there and some of them might ask some questions at startup. It c= omes to my mind that pdf-tools sometimes wants to recompile it's C part= after an upgrade, but AFAICR this is done when the server starts and not w= hen the file is visited, so the question is lost in the stdout of the daemo= n, which is an instance of a closely related issue.
=

=
--000000000000571e1d0595e5b424--