From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging Date: Tue, 24 Aug 2021 19:41:18 +0200 Message-ID: <98917a3e-e465-6cfb-ffe6-d977673bf185@gmx.at> References: <1776CE98469A44C484752764DD29E2DE@us.oracle.com> <878s0srzup.fsf@gnus.org> <25c7bc14-fab3-5411-5526-24ad0de6ed85@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4599"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "13336@debbugs.gnu.org" <13336@debbugs.gnu.org> To: Drew Adams , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 24 19:42:22 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mIaRK-0000zP-Jk for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Aug 2021 19:42:22 +0200 Original-Received: from localhost ([::1]:45558 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIaRJ-0006cb-Jg for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Aug 2021 13:42:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIaR0-0006cS-R0 for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 13:42:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33586) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mIaR0-0005gK-36 for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 13:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mIaR0-0003rq-0Z for bug-gnu-emacs@gnu.org; Tue, 24 Aug 2021 13:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Aug 2021 17:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13336 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 13336-submit@debbugs.gnu.org id=B13336.162982689314830 (code B ref 13336); Tue, 24 Aug 2021 17:42:01 +0000 Original-Received: (at 13336) by debbugs.gnu.org; 24 Aug 2021 17:41:33 +0000 Original-Received: from localhost ([127.0.0.1]:45132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIaQW-0003r8-NW for submit@debbugs.gnu.org; Tue, 24 Aug 2021 13:41:32 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:37925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIaQV-0003qs-P2 for 13336@debbugs.gnu.org; Tue, 24 Aug 2021 13:41:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1629826881; bh=cqLPI1ALnT4mVLh8OcAtgI0cY8Wyw97qKKv7wQKfZb8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=l4mmbgMFEsa5k4AVcWue1gdgyvE2O/CaLiL2drOYdeAq/lO9wT7OIWud5P7zHgb/T Ijb/D4lTTQEvEpu7QoGJjanTyO+Fi9GHdO7JAzATfYKgJRflA9UcWweCAZViJUYtHp X0deyVKw0IemIGotpaNbp/Y7iQsHHuIIYe3w2b6s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.186]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N1fn0-1n2wn30Ayu-0123oZ; Tue, 24 Aug 2021 19:41:21 +0200 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:RpXbd/rM8xNgOEAh1LJSGxnKYwLtVMHhWdxvODXdZjUn20ZzF6j +gBVeDMuqAxArUGS0EQ9Ht1k9P3FlrQi62IWJxGNjASxSK26Ugkijatqn7ewBl5i1o5Z8Ag /aYH/BqfJxNzhIcSEq/hvcz6dckoUMNgSgAlIzzjraGQsDZ4uWwTdVRTOkxmlclFNgw68MH J5PMfvwcKtjSIfUxybnDA== X-UI-Out-Filterresults: notjunk:1;V03:K0:BWuNbsQn+5Q=:mMDmuyOV/4FT/M8KhUC5lM Q860E7x1fOTCOXdj9qKd76J8dIPjrqasMtBtxpe3mmIu4oc2wW5Z4pavmMNRT+vc1giuEn2l3 qn4LKckDx3DS21Q39zHBo/JRWtAjtOK/sfUqcC4ZBCrLdiYnW6meRMCwhYMe97rveq6fD+8+8 6pPnj4bdJZtXq87ocglP8qrhplU2lSWhxeQAwhy9NH8d5tAgnL5ofQaj+1F8ohO9HDSItUGdl uzZ3F7lV6dZf9V7m6IqqlAvibQ1s1sJcAbI8SVrKhQTyN4ONocvmzBhGfYrwGRPCLNMEXiDlX mER21owsw14Cta66jzCEGsFzDTWqPrj2v+CFxDzFocFW9IxazV3M+k32WoYBD25ppSo3hZpvI vUZEVWLXHXXZOQv6SknpOuW5vYRzy3s6wXAVoK8R2VKdO+m+bhu+RTKO/AZJcjhOVGce5DQAE A3C8oi3eFlQ9q/TYLzOIr/YZaYcofVYIQIs1JIqGcoo8XWdAheM3jwLRBmRsWvmqBjv1b883a THaLt2U9ZBN1IYpddKtWRTHwEGl/zQnifbqA268vsSt+4DoLBoXHYy85FVrTRZ9DuHB95m6b9 9r3RuH008UVfMnGeHZ5Sj+LTMXh0tSv1aPLmLNgO41ym9Z4xjzBmgZDj41Bnv1VV2ZXX8USCZ vcl7UQ2aftW8CLgpVMm4lx18vO7GANspnZUyVuwyANQf5gBDgwgKln1TvubOYVTLoNBggyopG DcVWiyHwD6PHj6ZexZY8x9cZEpYGbVxg9/1gJZREmaZv0M9j64DwbY1oM0JQqKuxjfD+v6rE X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:212561 Archived-At: > I did this: > > (when (if (fboundp 'display-graphic-p) > (display-graphic-p) > window-system) > (defconst special-display-regexps '("[ ]?[*][^*]+[*]")) If you insist on using the obsolete `special-display-regexps', then why on earth don't you use a buffer name with it and why on earth don't you use the FRAME-PARAMETERS idiom? > (when (> emacs-major-version 25) > (defun backtrace-no-other-frame (frame) > (when (equal (frame-parameter frame 'name) > "*Backtrace*") > (set-frame-parameter frame 'no-other-frame t))) > (add-hook 'after-make-frame-functions > 'backtrace-no-other-frame))) > > Debugging a bit shows that frame parameter `name' for > the *Backtrace* frame is indeed "*Backtrace*", Not at the time `after-make-frame-functions' gets called (unless you specified a name for it). > but > parameter `no-other-frame' is nil (doesn't get set to > `t'). What's more, it looks like (?) function > `backtrace-no-other-frame' doesn't even get invoked. > > What should I be doing instead? I don't explicitly > create frame *Backtrace* myself. I presumably need > to somehow have its `no-other-frame' frame parameter > set to `t' whenever it's created. If you insist on using `after-make-frame-functions', the following should work. (defconst special-display-regexps '("[ ]?[*][^*]+[*]")) (defun backtrace-no-other-frame (frame) (when (equal (buffer-name (window-buffer (frame-selected-window frame))) "*Backtrace*") (set-frame-parameter frame 'no-other-frame t))) (add-hook 'after-make-frame-functions 'backtrace-no-other-frame) > Beyond finding a solution for myself: I guess you too > consider that this should not be fixed generally, i.e., > that frame *Backtrace* should be allowed to be another > frame's `next-frame'. If so, I'm curious as to why. I see no general rule here. When debugging window management problems, a separate frame comes in handy. OTOH when debugging frame management problems, a window on an existing frame might be preferable. martin