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: Sat, 19 Oct 2019 18:39:31 -0300 Message-ID: References: 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="157954"; mail-complaints-to="usenet@blaine.gmane.org" To: 37826@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 19 23:40:10 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 1iLwSH-000ezt-Rl for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Oct 2019 23:40:10 +0200 Original-Received: from localhost ([::1]:39016 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLwSG-0005cG-Jr for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Oct 2019 17:40:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56334) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLwSA-0005c8-V3 for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2019 17:40:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLwS9-0000uO-S4 for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2019 17:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44803) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iLwS9-0000uH-On for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2019 17:40:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iLwS9-0004CA-IJ for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2019 17:40:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2019 21:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37826 X-GNU-PR-Package: emacs Original-Received: via spool by 37826-submit@debbugs.gnu.org id=B37826.157152119016107 (code B ref 37826); Sat, 19 Oct 2019 21:40:01 +0000 Original-Received: (at 37826) by debbugs.gnu.org; 19 Oct 2019 21:39:50 +0000 Original-Received: from localhost ([127.0.0.1]:53624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iLwRy-0004Bi-EU for submit@debbugs.gnu.org; Sat, 19 Oct 2019 17:39:50 -0400 Original-Received: from mail-yb1-f171.google.com ([209.85.219.171]:40450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iLwRw-0004BU-7F for 37826@debbugs.gnu.org; Sat, 19 Oct 2019 17:39:49 -0400 Original-Received: by mail-yb1-f171.google.com with SMTP id s7so2927873ybq.7 for <37826@debbugs.gnu.org>; Sat, 19 Oct 2019 14:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LUvpro/GIstXizM5WFEWSFMM72xX22G5nv9KnmZIYvU=; b=Jsf1Y8rnL20uHkSaNIYY/JI5gvZimycxPhAkj64rInmPIlTKdBn2XQNaT4JZqQrEfc cg6zOHkyPidnxZpI0jeAOJsHIwwX3PcOMx+Nl1uh3XgYgq0WFnSol8ht92GFk3bHADMs w2jKSI0quv2MgMTiq9UgZ3IrVFdMINZj9I8C9sscBp3YGMxztuKpxR0VRhf2zbcDp/3C Rjyil0axAsRE1lb2ztGDKVd15s2DfXp2U7vr32FKo13o/RaMnyIjAY2+ClmlFWi5tnO4 IWeOjKBsLakwDmfxVSRcGjEPjVt2b64SPcBmh87Rwma3oFIUxP/tZHkm0bXtembLD6nA R+TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LUvpro/GIstXizM5WFEWSFMM72xX22G5nv9KnmZIYvU=; b=QR3yppuPliNTz5aYr6TGuxA0yTonxVZQbKpqpr7wIstVxL7FN7y/Gp7eTN5GTI2fEb TjoVBMfhnC4x4i/WqArPGA1LDemssdJjT5fbrNoS4bxZx7t1+yOEwfsj3dVrYhb/aeip zrk5f9Cma+o2xPJ1a60mNMkG7c+db38YibCEtdS9MXvu/cxatshd0E/98Fqi/t0fIrxu QYAHbprY7rC+hLWKOHvlwOe3SV1lNlGmeQx1hQ+Enqk0XEB0tHXUUtiBorJ3jEb4IATB af+g3rBinA8qrqNLx+1l5WuWRemkTLO28/s+5PbMbAfDdK6RUNEc0DYbzwqtbRHyTkhm LPzg== X-Gm-Message-State: APjAAAVyLqS3P5RqR8xC4v56bRGvRhUnpc3CZsre0CgbMGY7hwK915Cr +cGWUFK/AcwezGgU6W3baR0+ACtC2AaQ1enDsK5jw4eVkBg= X-Google-Smtp-Source: APXvYqxPSotTuICvXZGr6ry24oW/cFRco8BOeo4WDSp4dEDKi17CWwCQpDBIFBjjPF59FzW0cGMcDEbpa5A7RDSH6Ro= X-Received: by 2002:a25:e7cf:: with SMTP id e198mr9846991ybh.334.1571521182159; Sat, 19 Oct 2019 14:39:42 -0700 (PDT) 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:169759 Archived-At: I think I need some feedback in order to advance. I would like to do something like: ``` frame = create-frame-func() with-selected-frame frame: buffers = server-visit-files(files) ``` so that visiting messages show in the right frame. But this introduces circularity, since frame is currently obtained as: ``` buffers = server-visit-files(files) with-current-buffer car(buffers): frame = create-frame-func() ``` with the following rationale: ;; Set current buffer so that newly created tty frames ;; show the correct buffer initially. So, short of deeper modifications, I could just let the messages show in the wrong minibuffer and restrict the scope of auto-rise-minibuffer to buffer reverting/writing questions: ``` (cond ((file-exists-p filen) (when (not (verify-visited-file-modtime obuf)) (revert-buffer t nil))) (t (when (y-or-n-p (concat "File no longer exists: " filen ", write buffer to file? ")) (write-file filen)))) ``` Nevertheless, not only the messages will show in the wrong minibuffer but the questions will also be asked in the wrong place, although these questions should happen exceptionally. I believe one way or another there is some price to pay here: do we prefer for the frame to be created with the right buffer from the very beginning, at the expense of ill-placed messages and questions? Or do we prefer to show this stuff in the new frame minibuffer, while postponing the setting of its initial buffer until all files are visited, producing a frequent and unpleasant switching visual artifact (which AFAICR has been always the case, has this code changed recently in order to address that?) ? Of course, the first option is easier to implement since it's closer to what there already exists. Also, insofar we avoid the autoraise issue, the problem should be less noticeable than the "initial switch" effect.