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 15:17:16 -0500 Message-ID: References: <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" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="80327"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , emacs-devel , Eli Zaretskii , Stefan Monnier , Juri Linkov To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 25 21:18:52 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 1ivRtL-000KoS-5N for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jan 2020 21:18:51 +0100 Original-Received: from localhost ([::1]:57298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivRtK-00058l-3I for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jan 2020 15:18:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51996) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivRs4-0004Y9-Pu for emacs-devel@gnu.org; Sat, 25 Jan 2020 15:17:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ivRs3-00014D-PC for emacs-devel@gnu.org; Sat, 25 Jan 2020 15:17:32 -0500 Original-Received: from mail-lj1-f173.google.com ([209.85.208.173]:46146) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ivRs2-00011J-0Z; Sat, 25 Jan 2020 15:17:30 -0500 Original-Received: by mail-lj1-f173.google.com with SMTP id x14so4109728ljd.13; Sat, 25 Jan 2020 12:17:29 -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; bh=D8GRDEaEemWo9A98uZrSLE9jS28nxRMkC9mMiX7mwRk=; b=lB1lZgeQAsHvVJbxv1aUKr9PwD8Lub2A2ARgcenu9y/4QjVeLuYBy1p8dYRAeL/+lh RY3bRcSikJ1M7Xfm7HrQcRdi5mUtKf0n7PHLN9jtaOaaY6OwaPvq7cmowSLMZd/hrizH upFQhAq9h3HY1rP5WDlfW5vtBR8LOehDKdLd5/illPqQ+VUMV/yL5oURT5GA1CvtI3oF DUfvX6drFXJUCAUBPacKYKhvvPLitxV5Ge3WR/OxjJ//lUKuUCJBFnSNX8nl4dSwvzsO 3fBB3JXkiXkJN4HCaI/MZ+3Kgt5J0dqoJFV3avZBQApRgO2+2gTs+OWpSOXqcBiJaqKw Bg8A== X-Gm-Message-State: APjAAAVLrgX6uW2vpszJ7pXevQ89JSFzs0F/jRkxg7gVJ9iNrtPtvsIK Jxieao128Be7fHwo7kXd3H4I3XjZZ1y5HaN4ynY= X-Google-Smtp-Source: APXvYqzTkVg3cKEPnGsrC+uhQL5fDVlWKR40/wJmfgAb/cKpfIXOvE5H6jaMa0CLtK7b0rBhVFAUoQPtI3onlPyqvQU= X-Received: by 2002:a2e:89d4:: with SMTP id c20mr2186649ljk.228.1579983448612; Sat, 25 Jan 2020 12:17:28 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.208.173 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:244637 Archived-At: On Sat, Jan 25, 2020 at 12:14 PM martin rudalics wrote: > > - Whether a window can be split does not depend on whether it is > dedicated in some way or not. Dedicatedness affects exclusively > whether you can display another buffer in that window. Yes, I know that. My original point was that the semantics are not intuitive. A user writing some code to create an arrangement of windows and then marking them dedicated could easily think that those windows are thereafter stable, that they will never be split by display-buffer. What is not called out in any documentation that I have seen is that a dedicated window is still a candidate for splitting; that some other property must protect it if one's intent is for it never to be split. > A better alternative is to specify buffer display actions that do not > split windows or provide a suitable 'split-window-preferred-function'. I strongly disagree. I view having to interact with display-buffer as an ever fraught proposition. I understand the motivation for display-buffer's existence and the remarkable job that it does. But when creating an arrangement of stable windows I much prefer a declarative solution that clarifies my intent. > (3) making the window's frame unsplittable. I do not want to disable splitting altogether, only of certain windows. Thus an unsplittable frame solution is not practical > (2) making windows fixed-size Making a windows fixed-size seems - at best - a kludge. It provides no way to state my intent. Instead I achieve that intent - namely preventing certain windows from getting split - indirectly by specifying an unrelated property. The dissonance here is that I actually do _not_ want my windows (in this case gdb-mi's dedicated windows) to be fixed-size. I regularly resize those windows by dragging their borders. Would that continue to be possible once I make the windows fixed size? > (1) setting 'split-height-threshold' and 'split-width-threshold' > accordingly Using ridiculously large splitting thresholds does allow me to have stable windows that never get split while continuing to be resizeable via dragging. The unfortunate side-effect is that it prevents display-buffer from managing the large amount of screen space I have provided for displaying source buffers. An unsplittable window property sure seems appealing :-) The semantics are straight forward. And I find it hard to imagine that the implementation would be very difficult. I expect that the biggest efforts would be documentation, NEWS, etc. /john