From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Extend gdb to filter registers Date: Sat, 25 Jan 2020 09:56:11 -0500 Message-ID: References: <83v9pb314t.fsf@gnu.org> <838sm510d6.fsf@gnu.org> <83muakzoy5.fsf@gnu.org> <71042c9f-478b-47c8-f27e-1348e9f4536d@gmx.at> <83iml8zkbm.fsf@gnu.org> <6ad85759-7408-f177-38f6-45a72c2f5a9e@gmx.at> <83eevwzi79.fsf@gnu.org> <68ef651e-9319-b392-af1c-4564d5db9112@gmx.at> <831rrvzc81.fsf@gnu.org> <997C9AD2-D8DD-45DC-9195-28FEC907B2C4@gmail.com> <83muajxs04.fsf@gnu.org> <416593FF-C4BE-478F-B5AC-3379235146ED@gmail.com> <83lfq3xp66.fsf@gnu.org> <679953AF-F50A-4ABE-B836-150BA0F95DAE@gmail.com> <83h80rxlae.fsf@gnu.org> <8A5A507A-6036-4894-A8B1-749109EBE605@gmail.com> <83wo9mvwco.fsf@gnu.org> <2BEA3843-859E-481B-8561-35384438EF7F@gmail.com> <83lfpxs4sl.fsf@gnu.org> <162a03e4-2429-b7b7-0e9e-df0b433b8aea@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="69264"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Juri Linkov , Eli Zaretskii , Stefan Monnier , emacs-devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 25 15:58:04 2020 Return-path: Envelope-to: ged-emacs-devel@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 1ivMst-000Hx4-Kp for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jan 2020 15:58:03 +0100 Original-Received: from localhost ([::1]:54438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivMss-0007z8-OI for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jan 2020 09:58:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59565) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivMrQ-0007OB-TN for emacs-devel@gnu.org; Sat, 25 Jan 2020 09:56:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ivMrP-0002sN-Sf for emacs-devel@gnu.org; Sat, 25 Jan 2020 09:56:32 -0500 Original-Received: from mail-lf1-f44.google.com ([209.85.167.44]:35142) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ivMrI-0002eZ-HB; Sat, 25 Jan 2020 09:56:24 -0500 Original-Received: by mail-lf1-f44.google.com with SMTP id z18so3168573lfe.2; Sat, 25 Jan 2020 06:56:24 -0800 (PST) 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:content-transfer-encoding; bh=h2Bo+Y76eGL5NWGMWOa0ImpoXL6+LiwiCcrX5FfA9oA=; b=G8omnnOyXmm9G/V4PpzQWf56I++oDyQF9iDpikmsDiKbcxNQaBQyosLxzl3DqJyBRk OwcCv6oWzg1DR9duaiYxkdp9j4DSsXTw6cyIFaUPnm2eGx5joej2cWgeoVmiO6Zk7zy/ Jkzv13ciGiPa4FzHGD6uQW/l5L3vy+lvRu7mlxLDEx+ZWQ3gqiaqwfnA3nprk9SkADOU VB2TotllZqtlHUGyBy8dMrKtFftnpa5jtE8sww0fgCTLdnbkwo8Hbp3S0iG40b0MMpUH /6A2NeyJ8wR4qhiK6oJ7AL1MpZTrsgAWxq7EI126dOSSb9eTvkk9DBS4iE86IlDAWkko r3+A== X-Gm-Message-State: APjAAAWS6vd5SR4jPir3ev76rAX9tn/Do6oMZknuryD3rFqDGWz5AHCu jFobEVVgHoOSQlN2ANx0U3LYU7yoomKPqG2FHDs= X-Google-Smtp-Source: APXvYqwS0jqWC+ouqfuuy/aCpTxjUC0VCVcDol1h29riGkddsJUHTIvtI7VHuBiIzyQNqi7o9RwGnXvk8uKX6B20XcU= X-Received: by 2002:ac2:482c:: with SMTP id 12mr3887255lft.163.1579964183019; Sat, 25 Jan 2020 06:56:23 -0800 (PST) In-Reply-To: <162a03e4-2429-b7b7-0e9e-df0b433b8aea@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.167.44 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:244625 Archived-At: There seem to be three concept in play here: - dedicated windows - really dedicated windows - unsplittable frames gdb-mi creates dedicated windows which under some circumstances (see my most recent reply to Eli) still get split. Your quote from Stefan seems to be about really dedicated windows. My comment that you quoted was about the possibility of display-buffer splitting a window on an unsplittable frame. I admit to having no actual experience with such a configuration. I was merely referencing my understanding per info's Window Frame Parameters > Buffer Parameters node: =E2=80=98unsplittable=E2=80=99 If non-=E2=80=98nil=E2=80=99, this frame=E2=80=99s window is never split automatically. To reiterate my previous suggestion, I think that creating stable window configurations would be well served by adding a new unsplittable window property. /john On Sat, Jan 25, 2020 at 3:43 AM martin rudalics wrote: > > > That said I think that the current windowing model > > has a surprising semantic for dedicated, namely that > > a dedicated window is allowed to be split. Were > > there a way to make a window unsplittable (apart > > from creating it on an unsplittable frame) then > > gdb-setup-windows could use it. I believe that > > net effect would be all source displayed within the > > source area (though possibly in multiple windows). > > I once thought so as well but Stefan convinced me of the contrary, see > this comment in window.el. > > ;; Actually, even if the window is really dedicat= ed, > ;; the frame is still usable by splitting it. > ;; At least Emacs-22 allowed it, and it is desira= ble > ;; when displaying same-frame windows. > > Think of 'split-window' as of creating a new window somewhere near the > one of its argument. And note that you can always split a frame's root > window instead or make your dedicated window fixed size. > > martin --=20 John Yates 505 Tremont St, #803 Boston, MA 02116