From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitrii Korobeinikov Newsgroups: gmane.emacs.devel Subject: Re: Request for pointers and advice: displaying several buffers inside a single window Date: Sat, 11 Apr 2020 01:09:08 +0600 Message-ID: References: <83a73swwd7.fsf@gnu.org> <87wo6nxsjz.fsf@localhost> 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="48121"; mail-complaints-to="usenet@ciao.gmane.io" Cc: adam@alphapapa.net, Yuan Fu , Eli Zaretskii , emacs-devel To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 10 21:10:16 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 1jMz2e-000COk-BR for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Apr 2020 21:10:16 +0200 Original-Received: from localhost ([::1]:38014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMz2d-0007wF-8A for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Apr 2020 15:10:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59945) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMz20-0007VF-V5 for emacs-devel@gnu.org; Fri, 10 Apr 2020 15:09:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMz1z-0008Mg-P8 for emacs-devel@gnu.org; Fri, 10 Apr 2020 15:09:36 -0400 Original-Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]:51963) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jMz1v-0008IW-AI; Fri, 10 Apr 2020 15:09:31 -0400 Original-Received: by mail-wm1-x343.google.com with SMTP id x4so3414971wmj.1; Fri, 10 Apr 2020 12:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5cg8PKXXEeWN3+gC+G82G8rkbJ1dZ6tT0YYjltoRYxA=; b=myi+BF7Yv76ImI0JQ2JIdRTatEwXBGf3NfrFDSPQni0vqR0W4svdZYZna1s2MJ8fT8 IUvD+/yma7OMI6YlTe1r2/ZPD/P3Us7oRmZlExVAGfUvuu8uqWulS4pjJi2LILhLenCB Fuuj1KbMcnNk5Hua4GM+1MjQV0vBGZroLdK3CuEYZmdU9BIJubbUh4jlufQQwkvQn9rY 2q6hrCyVdTz8MgsTnORv7ZE7xSbmHeIBBF+/9MTL3dxt4oRIbgLFZKZkOxnUy9199Ijy OkjDoLOiKbkjMHyq1eUdQy+cYWr+eq9rX6cbzDi8kbRje4jeVw38mV3fmZIcTJ5w8FpQ fvTw== 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=5cg8PKXXEeWN3+gC+G82G8rkbJ1dZ6tT0YYjltoRYxA=; b=P/H2xkCF4CGzHS7JC6sl2QQNFPphTg9EzAwEdevFG5KZwKrb3QEH6OHy+8q4poNJH8 tpP/sj4G9zDiDRji5I60BeaUhIPM3hhzi5VAi1Dpd8YfB3L40JM48AqYwJDsgl5RT85M fZCjzah5Qny6FOpq+2JTrGI7x6wxNenITmkxqN7FrvPruNptdJ30Eiakqs/V5Sl8kdGU 8wQXm23Iw/f7VqdbnXUqOilwJjbkRjlG7xlR6Sjgdo8O+rFnJdOjtJZu+EUSBJEOvD/6 M74NZQmIDUxAbR1aNVsa4K6jYG5VcVpQODSrcRWg5mpwYSf5LSV7wCXMduG7Qut0vE60 yf0A== X-Gm-Message-State: AGi0PuZ0sSMVyP9iDp+Gj/CTlgLiH6jDr1OdkgcmrIAhNdc+3cw/ZKgg NFyhWG6nOWbln5BRFJDgmUH2OuAduVEdndvtD84= X-Google-Smtp-Source: APiQypJvyU6GD2XmUXyn5XQARtfRUijaD69GuM1U7vZj4feqYfYfC2xxkZAwqR3fI6uZg3Pm7s0MbV+h33icbVmwk/w= X-Received: by 2002:a1c:e187:: with SMTP id y129mr6875161wmg.133.1586545760297; Fri, 10 Apr 2020 12:09:20 -0700 (PDT) In-Reply-To: <87wo6nxsjz.fsf@localhost> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::343 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:246794 Archived-At: > Following mode plus atomic windows seems doable. But it wouldn=E2=80=99t = be > transparent, AFAIK follow-mode needs to add special handlers for > things like isearch and query-replace. OTOH, it would be much more > difficult to implement in xdisp.c. I wonder if there is an > intermediate layer that=E2=80=99s higher level than redisplay (in lisp, o= r at > least not in redisplay) but still more or less transparent. I have come to the conclusion that extending the underlying data structure for the storage is unavoidable and, really, the simplest + most efficient method to achieve transclusion / islands / seamless mode regions / buffer lenses / whatever, and to avoid having to deal with a whole lotta bugs, corner cases and synchronization trickery. Emacs uses gap buffer for storing text (a c array with some semantics, basically). What I have in mind is to keep it that way, but to have a list of references to other buffers along with their intended positions. >From what I saw, there's not a unified core interface on top of that c array. So, would need to modify each place that makes a use of it. (for a couple of examples, see text_outside_line_unchanged_p in xdisp.c, looking_at_1 in search.c) I tried to eyeball the effected landscape by looking at where GPT (position of the gap) is referenced. There are 287 occurences of GPT in the src directory, most of them are in buffer.c, buffer.h, insdel.c. The distribution is: coding.c(24), syntax.c(10), changelog(17), xdisp(8), insdel(131), buffer(35), editfns/fns/w32xfns(11), search(7), marker(6), xml(1), charset(3), composite(3), decompress(1), pdumper(1), process(1), character(3), json(1), fileio(11), indent(3), sysdep(2). The good news is: I believe xdisp.c wouldn't have to be modified all that much if the regions are enforced to start on different lines. This whole ordeal could easily take a few months. I, unfortunately, am unlikely to find the time to do it this year. PS A possibly useful outcome of this is the possibility to mitigate extremely long gap motions by breaking up a big buffer into several smaller ones. =D0=BF=D1=82, 10 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 21:38, Ihor Radche= nko : > > > Following mode plus atomic windows seems doable. But it wouldn=E2=80=99= t be > > transparent, AFAIK follow-mode needs to add special handlers for > > things like isearch and query-replace. OTOH, it would be much more > > difficult to implement in xdisp.c. I wonder if there is an > > intermediate layer that=E2=80=99s higher level than redisplay (in lisp,= or at > > least not in redisplay) but still more or less transparent. > > What about extending the idea of indirect buffers? In indirect buffers, > the buffer strings are associated with the same memory address storing > the text (if I understand correctly). Similar thing (theoretically) can > be done for individual segments of text. Indeed, there will still be a > question on how the fontification is done, if the overlays should be > shared, and how the key bindings should behave on such segments, but the > basic functionality of automatically sharing text segments between > buffers may be a good framework to start considering more complicated > cases. > > Best, > Ihor > > Yuan Fu writes: > > > Following mode plus atomic windows seems doable. But it wouldn=E2=80=99= t be transparent, AFAIK follow-mode needs to add special handlers for thing= s like isearch and query-replace. OTOH, it would be much more difficult to = implement in xdisp.c. I wonder if there is an intermediate layer that=E2=80= =99s higher level than redisplay (in lisp, or at least not in redisplay) bu= t still more or less transparent. > > > > Yuan > > -- > Ihor Radchenko, > PhD, > Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) > State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong= University, Xi'an, China > Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg