From unknown Sun Jun 15 08:50:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64025: 28.2; when minibuffer active, all other X11 displays and ttys are hung Resent-From: Al Petrofsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Jun 2023 18:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 64025 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 64025@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.168659430611890 (code B ref -1); Mon, 12 Jun 2023 18:26:02 +0000 Received: (at submit) by debbugs.gnu.org; 12 Jun 2023 18:25:06 +0000 Received: from localhost ([127.0.0.1]:40494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8mDy-00035i-0K for submit@debbugs.gnu.org; Mon, 12 Jun 2023 14:25:06 -0400 Received: from lists.gnu.org ([209.51.188.17]:58144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8mDv-00035W-Gl for submit@debbugs.gnu.org; Mon, 12 Jun 2023 14:25:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8mDv-0002vL-7K for bug-gnu-emacs@gnu.org; Mon, 12 Jun 2023 14:25:03 -0400 Received: from mail-pj1-f45.google.com ([209.85.216.45]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q8mDt-0008Cf-82 for bug-gnu-emacs@gnu.org; Mon, 12 Jun 2023 14:25:02 -0400 Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-25bd8d52f24so342345a91.0 for ; Mon, 12 Jun 2023 11:25:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686594299; x=1689186299; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1Da02Xz1q7dsvvSFphYpaCQpkjHU/mYAlEoC3fK5Zfo=; b=bPUC8A4sdgArq3d9LAVzqFtlDXsAZHtzkk5kstmQEJm6HHtJONcXPxKw7nCEV94aSj /npvomOal9PI7NnBM6W42WgE0VEB+b8BdWlbv+1qd+6mKTaROIISJo9ej2hdx0V94dlg gG74gf65Y0dX6F0aDe08QTiU5q2HqPpeSJ4YcgGKUNCFerx9DtLyv3S05RYnRR9lHBhW HAwWYipYULZKx5HHi9KfQEZsB0RUJCbs21cAZicW3B/oJTmpZ1o5hecV1O559T1EO7Eq 6Y1DH/qjnUqH1Vy6h5yNIYtdI3HEghBMMXqsGHqzVmSe0hnAJQVbZmgRWhrDnNixZ+6o lmpQ== X-Gm-Message-State: AC+VfDy+MvsUCXhZ3QzJwpksQKgzDOSvZgEFZkqXBHVmMZNhKgTEhjd3 JJdK/2uPtXZ2L0Xna4WMSWljpeSA6yN9D7FznpQKwma3W9A= X-Google-Smtp-Source: ACHHUZ6LsZxj0IW3ojW62rQndvGRilrjSOdXRiV4853UmhcF6wHEEnk4t2UgjxMHD2rtzvMUootcWLJJMPyr7c+x/1E= X-Received: by 2002:a17:90b:1b0c:b0:25b:e057:7526 with SMTP id nu12-20020a17090b1b0c00b0025be0577526mr4397170pjb.4.1686594299174; Mon, 12 Jun 2023 11:24:59 -0700 (PDT) MIME-Version: 1.0 From: Al Petrofsky Date: Mon, 12 Jun 2023 14:24:47 -0400 Message-ID: Content-Type: multipart/alternative; boundary="00000000000015241005fdf2d640" Received-SPF: pass client-ip=209.85.216.45; envelope-from=al.petrofsky@gmail.com; helo=mail-pj1-f45.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --00000000000015241005fdf2d640 Content-Type: text/plain; charset="UTF-8" If you have emacs connected to more than one "terminal" (X11 server or tty), you can walk back and forth between the terminals entering commands. But if you neglect to finish a command and leave the terminal while the minibuffer is active, then when you get to the other terminal room, emacs is completely unresponsive. emacs -Q --daemon=test [on tty1:] emacsclient -t --socket-name=test [on tty2:] emacsclient -t --socket-name=test [on tty1:] M-x [on tty2:] C-g C-g C-] C-g ... [nothing happens] This seems to be the case regardless of whether the terminals are graphical or ttys, and regardless of whether created by emacsclient or make-frame-on-display. This can be seen as a feature request more than a bug report, but it's at least a documentation bug that the Multiple Displays info node makes no mention of the limitation. Ideally, when the minibuffer is active on one terminal and a keystroke is received on another, the miniwindow would move to or be duplicated on the other terminal. At a minimum, it should be possible to get emacs to abort to top-level by typing some combination of C-g or C-] at any terminal. A related situation that doesn't involve the minibuffer is: [on tty1:] (while t t) C-x C-e [on tty2:] C-g C-g C-] C-g ... [nothing happens] Some way of reliably aborting to top-level from any terminal would mostly fix both problems. --00000000000015241005fdf2d640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you have emacs connected to more than one "termina= l" (X11 server or
tty), you can walk back and forth between the ter= minals entering
commands.=C2=A0 But if you neglect to finish a command a= nd leave the
terminal while the minibuffer is active, then when you get = to the
other terminal room, emacs is completely unresponsive.

=C2= =A0 =C2=A0emacs -Q --daemon=3Dtest
=C2=A0 =C2=A0[on tty1:] emacsclient -= t --socket-name=3Dtest
=C2=A0 =C2=A0[on tty2:] emacsclient -t --socket-n= ame=3Dtest
=C2=A0 =C2=A0[on tty1:] M-x
=C2=A0 =C2=A0[on tty2:] C-g C-= g C-] C-g ... [nothing happens]

This seems to be the case regardless= of whether the terminals are
graphical or ttys, and regardless of wheth= er created by emacsclient or
make-frame-on-display.

This can be s= een as a feature request more than a bug report, but it's
at least a= documentation bug that the Multiple Displays info node
makes no mention= of the limitation.

Ideally, when the minibuffer is active on one te= rminal and a keystroke
is received on another, the miniwindow would move= to or be duplicated
on the other terminal.=C2=A0 At a minimum, it shoul= d be possible to get
emacs to abort to top-level by typing some combinat= ion of C-g or C-]
at any terminal.

A related situation that doesn= 't involve the minibuffer is:

=C2=A0 =C2=A0[on tty1:] (while t t= ) C-x C-e
=C2=A0 =C2=A0[on tty2:] C-g C-g C-] C-g ... [nothing happens]<= br>
Some way of reliably aborting to top-level from any terminal wouldmostly fix both problems.
--00000000000015241005fdf2d640-- From unknown Sun Jun 15 08:50:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64025: 28.2; when minibuffer active, all other X11 displays and ttys are hung Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Jun 2023 00:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64025 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Al Petrofsky Cc: Dan Nicolaescu , Richard Stallman , 64025@debbugs.gnu.org Received: via spool by 64025-submit@debbugs.gnu.org id=B64025.168661650324174 (code B ref 64025); Tue, 13 Jun 2023 00:36:02 +0000 Received: (at 64025) by debbugs.gnu.org; 13 Jun 2023 00:35:03 +0000 Received: from localhost ([127.0.0.1]:40979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8rzy-0006Hf-9v for submit@debbugs.gnu.org; Mon, 12 Jun 2023 20:35:02 -0400 Received: from sonic306-22.consmr.mail.ne1.yahoo.com ([66.163.189.84]:38893) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8rzv-0006HE-5v for 64025@debbugs.gnu.org; Mon, 12 Jun 2023 20:35:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1686616493; bh=vDwYhcrASis5HASSYsROV9wz6V0/SVnkjqHZsZHezkA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=ptrw4bvuVh8RXihHfHEKXHmdLwSD4TQYoRhsfBQUkCdT9qnsb4tZqIuNfaanCitJ6n7ZXOPl+kU6w7Fd9aaU2HCCUiaUgt0q1CbzAFq2gNKLIoJQrds+ZGEJNnzTRpEpTa8qlWRfSpfQKwRa2NbdUq+RZHAQ5+UKfjUtT3e/Op2oLY4XxO4puVemjPkS4ZOrmnExQZ4NDyCbpFfC/oZTSWGu/kSQHW+FCM7zERiIJDpyQCcSFwBQMxMerLTkEUrBzHlrPtKQKSs3DsCIaz9gYldLhr3GeJLM3R0S0/9LPoWO6BgvAQWf+TIVTzZsPW1K2O5K2sLWYXigsPpt2Vs9dg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1686616493; bh=nH5F9iMQ0UwpQMhHeeW00QSEsFzo+In1fAuUZp5QHKq=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=hMBJHFDMq1IxjOZTZ94WCgNpV9CAbVMaRrX0YejKzHaepYILXAB/kFdRDvw4nnW+EXWa5xs6zA672hvFBqCj2B1F7N0eb5kAlpcewo1rlo3wAs8iHoXhVTjG+NR09NF+oP04ihxtMjQ++tXpDgM/TDtrwSsIO0TQhPIoIv0J9M5TuM8yzMOI6RF+CDMpSg87m+4kWj67WOicoxPLyIHllKrcDBthTPdmxEAqjvNguABrYwPS6vVboSopUouSQo+bI9WMn29kLAF5eionsSZ03qMLkK5psDql3lixJKA4G/Dcy800SJ2UTxZ4+xYr2hre0XDzKjdXidnpX5xDRunxWw== X-YMail-OSG: wpPN5ZUVM1mq3.uQgazQuxeHE74D.x6LGwoCVAV4NNGvhbbckhTJvFFguBcFGZh 9hLulVwhnZmtUO7oTf4FJ9Q8Wt.h_ob8Xa4ceWTDcLbyWY_4_opSpsPnNyw1RzItaVkSVUBU.p2z MKqCxJcTd2l8lTRkguELfTqe_Q1DEDap.TzJ4E_yPa3crmWcd1uKjqiOYOegD5_2nCDwKw1eg4qv 0a6LlxdCxjV22VyD.KmRJsjQPTFKEaCy_PZRCasoG6GLDzPMNJ13o4luLzEPW4p5j_b.7SKkjo2U INlH8aAwSWntQArXGxOujAfknbxmIqFIR3bbJHH8msJkTqZ06ZsTLDAQPsiizoj7xJMf7G8KAaVN AEdJ6qdHt7QFXoFabXkrBe6_tYZKa0x6nlLcLx3ZdXQrQAw409jlV20Blu7hgU_IN5d2D7H3UBDF lLLBKYCEJCNYijjZ1059t1erIvC1Ae.Bu_6d2_OXl3mQxQmAMiN2GL.RbvucOVJhcn1RBBbxnONK 0.nPoAi9rt.Y_f_TL7J.WIxMd4PxvyR1BmoAQtBA7f2Z.3T1HV6pgpu2HXQjQ6jJyAFXv5xueUxd KAsEdtVwlAI7IQ.lhzh76AlfjcvmW_AfMLcUYOTenkuo0tyz2fipUjHW.yytiGij.NfTtyA.CNaW _gkvXaFqD84ortamXZfk.o.TkbUyMlqlfr2rVZg9Y289jJPAxHEXQW.Hp_dBsHxdl1Ob.gsqIdIC mwqZ6GPwvPre6yBx4xmvYKACT0sKyYy_5FWcyCe6lXd9d8nIe5Tn90MCLD3wt70y0wD1NfPg3LBB 5AwymA09KeD3SgefC5zUpwKDB3ZtdXTnbOcjqVwCU9BvbJfb.dFCeL4eadrsA0OfQpjsFaENRFup ueeQuXcOtr1iAyk2YhGCD.t0U7Qpu4rwtenP_uynfnTmlEu6MPztcZY5sta7AJ2ag801foJDPZYT T3JP8Zg.BuU3GWpK_RGhHQzg_5y44iyIVSKqSfmcM_Otkr1c9TvF8U2dSvV.FqarfKGJuvdvB7Kt O0qkuRN4SK3._e2fbqcw4tqFQzmqVsVEG.zemuE2XFU6Y1VH7JprAq4EsrTUnbKVW6vvsyEZUDz3 WFNwE9RroVAKde3ojclqN3aQU1vWc7qfgGu59esBpYgBDILx1G1KNsKQnKPGD2Xikt_.ez4K2D.c H07IIVdhhva7nWX0gnNFn2WbsEkViMweuw8bJGlO4Osd6w3L7IMsz.oaLHS_9XcX3QsfV27Piugv _VKwguDyFEGpVS3pdwn3MS0oRYYrawePRbLavvdC1yE7H9JdhuL2uKcTZ.EP_6JyHj.hXHLEzwSF 7hevNyISfxG2IGKvjWAjsKwE4zSDbe83WbIqNlWukfnFqXK9GflyFOzWeWBoLHCnXT2sc1AOwhdt XNDBrh8_wHUwP5w0TVun53zO3KCeP8ZD7vk3VW3YPSIxBxn_Z24sk8f6UIpPua3eqDNU7DA3.W4Y ripMldnhoW2QHp1lqbCVIeae.DeZlLii.rpRTuz2DWZLEbxXjNQ8M_zW3wYMa1Qka5u9cHvzY709 Tx2oF.Q18bOTCgH5dquWJIm7LbJIkQp4CWC8L5JMzOEjafi8fTB1WAMB2.Yb2.sqjDQogjjdxwre x_qINTB1l6vtjOqRk7ctofRHeZ63Bp.mkco9hvoym8qc989B3x3osFHn5QNoJnDZ7Uzs._pewmih QDwIFBxuFELMxXRe2dZ8AJosFOqlNpfPgkbSGwgITcI68Imf968qugBCasJfSw_jZgTcWmmEGZfN vNsQLy.t0gMZScGGe0A6wbiKUZjFdnDJOXGG.dn9jEkRU6q5qnsuWykyjCG0ACnEvBt954EibBWv W0nkHFvTtZM.EURhPmsdHWiyJrobZ5RTWtCY8mv70aUvdkMDhcbL54BinXNfEvu8Qz0EpTwrtgGa TC.HG5lhzX28DWWQbKmVZEnCn5qpnFRzivzeUNKnEiOMEFzKBkLyE_dhfiN_vGXO3UxGBZA12Nzj .uz0woYf5nrAdYMGw.._M33TZs9meblt3z34.x9OwRARIJLnw85vJuNRknjGVjeYfWlZV7ionY6P biRSlmtM.UQs9jeUl.HRr42iI2kXqSgqBip3fv2f7HbGKqcHXBHXBMaLLfNXM9dVhb.ykyhk543D Zf5d1EZ_0dme3Ua5rlasEILpN0hFn0ldSBGvi5USsASDmp.GMwkQ_VKvdHvKMyAq396EkHKXvpf_ KQdWY_16qx.kn7H0x6BDBmBlPQWU7Q.0YQrogpY0T3v6GR5jpNVWi.hTWHJ8- X-Sonic-MF: X-Sonic-ID: 5371ac24-9cf7-4f66-a571-b0be20568206 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Tue, 13 Jun 2023 00:34:53 +0000 Received: by hermes--production-sg3-748897c457-gjhr4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 91dc73fe51e5a513f16c199331c59cbf; Tue, 13 Jun 2023 00:34:51 +0000 (UTC) From: Po Lu In-Reply-To: (Al Petrofsky's message of "Mon, 12 Jun 2023 14:24:47 -0400") References: Date: Tue, 13 Jun 2023 08:34:45 +0800 Message-ID: <87v8fsgpy2.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21516 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2825 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Al Petrofsky writes: > If you have emacs connected to more than one "terminal" (X11 server or > tty), you can walk back and forth between the terminals entering > commands. But if you neglect to finish a command and leave the > terminal while the minibuffer is active, then when you get to the > other terminal room, emacs is completely unresponsive. > > emacs -Q --daemon=test > [on tty1:] emacsclient -t --socket-name=test > [on tty2:] emacsclient -t --socket-name=test > [on tty1:] M-x > [on tty2:] C-g C-g C-] C-g ... [nothing happens] > > This seems to be the case regardless of whether the terminals are > graphical or ttys, and regardless of whether created by emacsclient or > make-frame-on-display. > > This can be seen as a feature request more than a bug report, but it's > at least a documentation bug that the Multiple Displays info node > makes no mention of the limitation. > > Ideally, when the minibuffer is active on one terminal and a keystroke > is received on another, the miniwindow would move to or be duplicated > on the other terminal. At a minimum, it should be possible to get > emacs to abort to top-level by typing some combination of C-g or C-] > at any terminal. > > A related situation that doesn't involve the minibuffer is: > > [on tty1:] (while t t) C-x C-e > [on tty2:] C-g C-g C-] C-g ... [nothing happens] > > Some way of reliably aborting to top-level from any terminal would > mostly fix both problems. This is a known problem of the multi-tty code. ** The single-keyboard mode of MULTI_KBOARD is extremely confusing sometimes; Emacs does not respond to stimuli from other keyboards. At least a beep or a message would be important, if the single-mode is still required to prevent interference. (Reported by Dan Nicolaescu.) Update: selecting a region with the mouse enables single_kboard under X. This is very confusing. Update: After discussions with Richard Stallman, this will be resolved by having locked displays warn the user to wait, and introducing a complex protocol to remotely bail out of single-kboard mode by pressing C-g. Update: Warning the user is not trivial to implement, as Emacs has only one echo area, shared by all frames. Ideally the warning should not be displayed on the display that is locking the others. Perhaps the high probability of user confusion caused by single_kboard mode deserves a special case in the display code. Alternatively, it might be good enough to signal single_kboard mode by changing the modelines or some other frame-local display element on the locked out displays. Update: In fact struct kboard does have an echo_string slot. Dan, Richard, whatever became of this ``complex protocol to remotely exit single-kboard mode''?