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: Mon, 21 Oct 2019 10:37:34 -0300 Message-ID: References: <83tv84540m.fsf@gnu.org> <83v9si2y9u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000002c93505956bca4e" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="188682"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37826@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 21 15:39:59 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 1iMXuf-000mfG-8t for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Oct 2019 15:39:57 +0200 Original-Received: from localhost ([::1]:42042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iMXue-0005T8-38 for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Oct 2019 09:39:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40701) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iMXsr-00037s-BJ for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2019 09:38:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iMXsq-0007NM-8x for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2019 09:38:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47160) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iMXsq-0007NE-6E for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2019 09:38:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iMXso-00064p-AB for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2019 09:38:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Oct 2019 13:38: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.157166507423346 (code B ref 37826); Mon, 21 Oct 2019 13:38:02 +0000 Original-Received: (at 37826) by debbugs.gnu.org; 21 Oct 2019 13:37:54 +0000 Original-Received: from localhost ([127.0.0.1]:55981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iMXsg-00064U-H1 for submit@debbugs.gnu.org; Mon, 21 Oct 2019 09:37:54 -0400 Original-Received: from mail-yw1-f43.google.com ([209.85.161.43]:35792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iMXse-00064G-Ht for 37826@debbugs.gnu.org; Mon, 21 Oct 2019 09:37:52 -0400 Original-Received: by mail-yw1-f43.google.com with SMTP id r134so4903092ywg.2 for <37826@debbugs.gnu.org>; Mon, 21 Oct 2019 06:37:52 -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=+kI09sk8+pN8OLi/LCpWiOpx6hRPGQdhdPhre4MWkMk=; b=AvAUzvGzRLQs7I7/+1/UHfY+di+x9yavaxOLF1CX5Gk8YXv4lIKMxqwSFWeRzONZC1 4M/sNod6z1RuRvmC18Evl5/oi3A1WDNwgM5zF2PJdEYupCWd0so80KWTzgD1G90LhNNM ctznqkYXa17eb4p6KN/+tPsUYzT5LCpi+QGZ8cC+Jgnca9vQl4gmMvdAoHYQkG7tbMRH OuVnMZpXqnwkNAFpgFs+f3IutJ/Lv5oCXBqrdzWMne2t83eAT6mJ9SQxQF15he/SNaGO N/gIpd6dvwt8TzqKnt7wi/EwkpmVTT+Z71a9pRh0wQbyLADZg9Lyl/JvUKCp7nScUni+ 5/wQ== 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=+kI09sk8+pN8OLi/LCpWiOpx6hRPGQdhdPhre4MWkMk=; b=rngcRYus52u/1DyHh4osorvwoQz1HupjpeHDEihoe0g4T8l061m20J9CYKnwkvuCEb 1ZqZJuGyS5rPvzAI+GihXfkWlCaQNgkr5nLUGUezyNltlYFLerJBmFx6YBKxJlSuvR1S Lmpr+nXND4nCGs6ezf5iBfU1cJYf6S1c4R6vyX+M2gCqe3D1aCBQjbEy41nVdhfd7Ytq QSgygJZLXpy+L5GnMZIGCODR9tQrZvPlm9i+iu3YFdBROfpmDJd0WkNYHrGEx812xS9N UMP3IFoljgNXF6F2OtOIVsxzvTS27w0T6t0t8JEHJtSdRwXF6j5I6xlTPjgPFHnUtonC O4Dw== X-Gm-Message-State: APjAAAUU5MRxRG2htMO9UBHi21jBC96gdgT0fg4BmbStRxYDVtm3ieqs Er2b7dSSBU3bRapK3N3Dmbr1Xl67YUptx7XBW1U= X-Google-Smtp-Source: APXvYqwZjTMGj2gJQUikTkheakDKLQJTIsCUXHJMW2QKOwIYSkGgNXtrnUSbzXoJWA8WNlrFGA/dL5kDt4bjhT14Zgs= X-Received: by 2002:a81:ab42:: with SMTP id d2mr16469817ywk.64.1571665066770; Mon, 21 Oct 2019 06:37:46 -0700 (PDT) In-Reply-To: <83v9si2y9u.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:169910 Archived-At: --00000000000002c93505956bca4e Content-Type: text/plain; charset="UTF-8" > > I don't think I agree with such narrowing of the scope, certainly not > as an unconditional default behavior. Ok, I was expecting that anyway :) Is it possible > to have a solution that only affects this particular use case? > > can we delay the message until the new frame is created? > The message "Indentation setup for shell type bash" is like, I don't know, debug level. If modules are that verbose, for me this means a case by case approach has no hope of success. And in this particular case I would just have suppressed the message and not merely delayed it, but then we would be having a new discussion, and another one, and another one... And how to know when to delay/ignore and when to show if there is no priority hint? Again, I would have to proceed on a case by case basis, matching message patterns or something like that. Maybe you're aware of this and could spare me some time (and I don't have access to emacs right now): why the buffer "flashing" is a non-issue for standalone emacs? I mean, it also has to show something at the very beginning, while still loading the initial buffer. Best regards -- Carlos --00000000000002c93505956bca4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think I agree with such narrowing of the scope, certainly= not
as an unconditional default behavior.=C2=A0

Ok, I was expecting that anyway :)<= /div>

=C2=A0Is it possible
to have a solution that only affects this particular use case?

> can we delay the message until t= he new frame is created?

The message=C2=A0"Indentation setup for= shell type bash"=C2=A0 is like, I don't know, debug level. If mod= ules are that verbose, for me this means a case by case approach has no hop= e of success. And in this particular case I would just have suppressed the = message and not merely delayed it, but then we would be having a new discus= sion, and another one, and another one... And how to know when to delay/ign= ore and when to show if there is no priority hint? Again, I would have to p= roceed on a case by case basis, matching message patterns or something like= that.

Maybe you're = aware of this and could spare me some time (and I don't have access to = emacs right now): why the buffer "flashing" is a non-issue for st= andalone emacs? I mean, it also has to show something at the very beginning= , while still loading the initial buffer.

=
Best regards
--
Carlos
--00000000000002c93505956bca4e--