From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?6Lev5a6i?= Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] Brief v5.90: neighboring window merge on deletion Date: Sun, 24 Mar 2024 13:13:31 +0800 Message-ID: References: <86il1cvp7o.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4218"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers , martin rudalics To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 24 06:15:07 2024 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 1roGCJ-0000u5-3C for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Mar 2024 06:15:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1roGBV-0007Ht-Vq; Sun, 24 Mar 2024 01:14:18 -0400 Original-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 1roGBQ-0007HX-Np for emacs-devel@gnu.org; Sun, 24 Mar 2024 01:14:13 -0400 Original-Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1roGBO-0004tX-Ft for emacs-devel@gnu.org; Sun, 24 Mar 2024 01:14:12 -0400 Original-Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a468004667aso459713566b.2 for ; Sat, 23 Mar 2024 22:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711257248; x=1711862048; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UT3Vs5YeZGr3LqTsQo2tYqD7B0qo03fcJVN+MSWnuGw=; b=CfWWc/wUPTZBy6G+adNFxGGMwvEgYBWtmgay6HyjFJKLbdx6WeTtfVpoJSnRwxnECG qD/ng2QtR/o4IgOV9phqPgZqB4asjORIZENzFLyXoiStAq/z/CW0gt9cdvyV/SvfByVT ed3Vbi8CyMWvEbs5tdagTwjernY+Ko2CSrF5AvoDAKJuH6DFN9QjiOq1AQ4TpBGMwZhB ZZjq13GsihBoS+zK+nbgUZmwOemJ/0tua/l/ZmO7xJpHYf1JRcsMsSEJXc02hklJ1XVa T6BwblG7YHxEdVMRlAw1uzxqxWlixuBFoJm83BdRNPFnsnHb3eNVxnWhizr6+pETIjY5 1+nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711257248; x=1711862048; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UT3Vs5YeZGr3LqTsQo2tYqD7B0qo03fcJVN+MSWnuGw=; b=gK5afGiKxOhwFT0JQo+s3pSb+gb39AF7Dxb3IkQQHypZ2mQzYS0X7+4KxVIVWH9gVm p37prw9tieT9NEMAgUqX1qhr4u3Xtn/biAXVrGzl2wmCvV++ui111NxVsSXGO4W+TopQ rnh/7K7subVyJTKaqY5O1jzbnzc5Q6mRNurAKiTGbJgk5uUNd89oOwZrg/xHNjMZonpk M7CTMhQVDUCOyM3adZciUzPKTG/HXJtvXQZ2L4+C8mjsKNJK0tFZAhjmgtT0DmqkPnYq zyEsPUfRIUQlIFxYXiX48tfC57HyYazF6xr2zDbrVXA3GcywSogjOL1KulFmscEDD80y K+jA== X-Gm-Message-State: AOJu0YxKPxqqFCyX2XQ39UKEAx7Nyq2aEE6iUnisDV8mTA+OCTVkiMcu f+2QRKYNdnY0CNvEKGXXx515fYVoLQ5xd8J70BuCJk8vJX91i2yQ9sgEhNG+A49wrdlmK546Jun Xrik8f245HGoow9p7mT33PuJH1WE= X-Google-Smtp-Source: AGHT+IH1wvAUue77+kbN64OsxxAfupf1t5MN57ZwCbXdXBHEG6y+HjF9eBo1ZUsNvCLLeibD5vLHbzBQt2zsrpqZYv0= X-Received: by 2002:a17:906:2a85:b0:a47:28a6:3429 with SMTP id l5-20020a1709062a8500b00a4728a63429mr2478837eje.62.1711257248031; Sat, 23 Mar 2024 22:14:08 -0700 (PDT) In-Reply-To: <86il1cvp7o.fsf@mail.linkov.net> Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=luke.yx.lee@gmail.com; helo=mail-ej1-x62f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317257 Archived-At: > Please explain how this differs from the value 'pos' > of 'delete-window-choose-selected'. I will try, not sure if I can explain it well with pure texts. You will need fixed-fonts configuration to see my ASCII graphs below. This paragraph explains how the MS-DOS Brief behaves, feel free to skip if you already know. In Brief, the ` ' key command can `delete and merge' the target window into your current selected window, as long as the target window is aligned (of the same width or height with your current selected window. Well, I put a tolerance value of 1 character so that the target window and your selected window need only to be `almost' the same width or height, instead of `exact match' requirement of the original legacy MS-DOS Brief). The target window is chosen from your current cursor point of your selected window, to the direction your key points to. So if you press ` ', it will try to `delete and merge' the right-side neighboring window into your current selected window, not just deleting the right side window and letting Emacs decide how to show the other affected windows. Now we come to the difference between how Emacs' original `deletion' behaves and the Brief `delete and merge' behavior. Sometimes they are identical. If you use Emacs to divide your single window frame into four parts by first vertically split the window via `C-x 3' and then followed by two `C-x 2' in each of the just split window, you will get a window layout like: _____ |_S|T_| |__|__| Say if we would like to delete the target upper-right window where I marked as `T', in Emacs you need to select it and `C-x 0'. Then the window layout will become: _____ |_S| | |__|__| because we split the frame vertically first so the `T' window is bound to the right half side of the frame, regardless of the setting of the variable `delete-window-choose-selected'. `S' and `T' are of different (internal) parent windows so they are not mergeable. Now if we use Brief ` ' command from the `S' (`S'elected) window to delete the `T' (`T'arget) window, it will reconstruct the windows by deleting all the windows keeping only `S', then re-split the frame by first split horizontally the window, then reconstruct the bottom two windows achieving the desired layout: _____ |_S___| |__|__| This reconstruction happens instantaneously so it's almost not noticeable to users unless on slow terminals. Sometimes in X windows the affected window boundary might shift a little if the original layout is complicated or is 1-character in width/height difference between `S' and `T' (my default 1-character tolerance setting). This also explains why the following `circular' layout is not possible as we can't find a split line either vertically or horizontally. ______ |____| | | |__|_| |_|____| Hope this is clarified. On Sun, Mar 24, 2024 at 2:34=E2=80=AFAM Juri Linkov wrote= : > > > In case you are interested. I've just released the Brief editor mode > > v5.90 targeting the feature `merge neighboring window on deletion'. > > This functionality merges two aligned adjacent windows regardless of ho= w > > Emacs currently splits the frame. It meaning that even if two aligned > > neighboring windows in the same frame belong to different parent > > (internal) windows, they can almost always be merged by reconstructing > > the window tree properly. > > Please explain how this differs from the value 'pos' > of 'delete-window-choose-selected'. > > > This is probably not a big deal but for me this task had been postponed > > for over 20 years due to not finding time to implement them until > > recently. It took me sometime early this year to figure out an > > efficient algorithm. It reconstructs window subtree reorganizing > > vertical/horizontal spliter lines to achieve the desired window layout. > > However, due to the restriction on how Emacs split windows there are > > still layouts that can't be displayed by Emacs. A typical such window > > layout is: > > ______ > > |____| | > > | |__|_| > > |_|____| > > > > Any such structure within any sub-window of a frame cannot be displayed= , > > as far as I know (let me know if any of you know a simple way to do so)= . > > But for regular daily use we don't really need this kind of window > > layout so it won't be supported unless a simple approach is found. > > > > Notice that the atomic window is not yet properly handled and is > > on-going, if you find any other window attribute not taken care of > > properly, please be sure to let me know. --=20 Best regards, Luke Lee