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 16:01:02 +0600 Message-ID: References: <83a73swwd7.fsf@gnu.org> <87wo6nxsjz.fsf@localhost> <83369amqdi.fsf@gnu.org> <83wo6ml97m.fsf@gnu.org> 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="67614"; mail-complaints-to="usenet@ciao.gmane.io" Cc: adam@alphapapa.net, Yuan Fu , Ihor Radchenko , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 11 12:01:53 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 1jNCxU-000HTj-9h for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 12:01:52 +0200 Original-Received: from localhost ([::1]:50400 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNCxT-0007mA-BF for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 06:01:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41584) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNCwx-0007Le-3B for emacs-devel@gnu.org; Sat, 11 Apr 2020 06:01:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNCwv-00074H-TX for emacs-devel@gnu.org; Sat, 11 Apr 2020 06:01:19 -0400 Original-Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:39587) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jNCwu-00073c-4D; Sat, 11 Apr 2020 06:01:16 -0400 Original-Received: by mail-wm1-x344.google.com with SMTP id y24so4997741wma.4; Sat, 11 Apr 2020 03:01:16 -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=7aAl/qSB8GTanTpLjGNFR/XFDztnAMCC7ijzZxIFElE=; b=Vs3eXRvNgUD4jtgkamtXrO7ddPyqsfKU+//UJaz1KMkM8qsRssz3V86YGXtA/jIBh5 k2/d6MNPVc42im31hMw8ZYcnf9koTan3AII0PD0GIbsXL/m54A6jMJVvl36/9evD5aaN Pti4ofrIbhVaPrPDFWdaaIJ+7X/woXaf4YIAso3WfrKCzj7aOcSXbtu+HXUbbKj1azMe RaE/i/rqdCNr/VVZeuaofGAYNXe+u1tRzdsfnBDs5AZyvKGSNQRzS8TXZHxi7l+W18iA getjkmLbuICZw9JaRcOljWPb8LYy+w7UuJJWBcwr7s7luvanjhjcgqDxAfQgyBDVbXtt VnCw== 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=7aAl/qSB8GTanTpLjGNFR/XFDztnAMCC7ijzZxIFElE=; b=OIAIB3Tmiy+z69nkPoUYsGdKqoELtRFG1MnAxPvSkdNL+a2Vy2OJyaRBNeKkbUvflt Yjdb4iywAO6EQr1jJi99lRsu8Xv40bKlgn2i6+38EvPRaKY+vuDMOHHsC1EypnO0dhf7 TCOXXsNpQUxoR5gR2wPRUI6S4ErFpH3XCSrG+o54nzamvqhIdfI703OeF5wUdDK9gucq cNjo+ANCQrP9gf6AQXIRwPFCKkKlFCZMgSV4e9cBb7hMXxqUrun0lMe9Qeeio974n4fK sVJJg7XNydPncVLEnxPPWzrnezUJf/9vdrCAPCV0OLmUVTVG0TGrMBGFdM2B24jA2rA6 MAFQ== X-Gm-Message-State: AGi0PuaM8tq0JcI8vD0vHV1Xi3G9yFN5PCS1TZbnxYxiMNAp/2PcZuWs 0czxVsD9yQtdd+QCU0grNQjqZQQ4PVilpG6VTCdGuTrNv60= X-Google-Smtp-Source: APiQypLdR8tKcqH/U6l+8ok/ASPCX+7LocSgRyFecD593LHQZW3aD0NpYFDTdImbG/embH+QoiGsSn0+KXSKiDhovZU= X-Received: by 2002:a1c:9a87:: with SMTP id c129mr8732284wme.149.1586599274355; Sat, 11 Apr 2020 03:01:14 -0700 (PDT) In-Reply-To: <83wo6ml97m.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::344 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:246829 Archived-At: > Why does it matter how many times BYTE_POS_ADDR is used? If you > change the implementation of BYTE_POS_ADDR, the replacement is a > mechanical job, no matter if there are 8 places or 800 to make the > change. True, but BYTE_POS_ADDR turns out to be a bad example and not a good estimator of the needed changes at all, since it's a part of the interface. I only now looked and saw it was a function and not a field. But, for instance, GPT is, because extra logic needs to be written to accomodate multiple GPTs (one for the buffer, and one for each of the referenced buffers recursively). To give an example, search.c has this lines: > p1 =3D BEGV_ADDR; > s1 =3D GPT_BYTE - BEGV_BYTE; > p2 =3D GAP_END_ADDR; > s2 =3D ZV_BYTE - GPT_BYTE; This would need to turn into an array of n boundaries, instead of 2. And re_match_2 would need to become a re_match_n. Next, indent.c L362: > else if (PT <=3D GPT || BEGV > GPT) But there isn't just one GPT now, so, expect changes around this place as w= ell. I didn't look at the code very thoroughly, but I am pretty sure other places aren't too different. Besides GPT, obviously, boundaries of the referenced buffers now have to be accounted for, with their contents. A supposedly ordinary loop job, but still. All of these changes are conceptually simple, but do involve a bunch of legwork. There are some exceptions of course. Like "where to insert a character at the boundary", mentioned above. One natural solution for this, by the way, could be to simply look at the previous position of the point, i.e. if the boundary was approached from the right, insert to the rightmost buffer. =D1=81=D0=B1, 11 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 14:26, Eli Zaretsk= ii : > > > From: Dmitrii Korobeinikov > > Date: Sat, 11 Apr 2020 13:56:07 +0600 > > Cc: Ihor Radchenko , Yuan Fu , a= dam@alphapapa.net, > > emacs-devel > > > > By "unified core interface", I meant something like an OOP-style > > public interface done in a way so the users don't have to know about > > the implementation and underlying data structures > > You will find that in buffer.h. Modify those interfaces, and you are > done. > > > > > The good news is: I believe xdisp.c wouldn't have to be modified al= l > > > > that much if the regions are enforced to start on different lines. > > > > > > How so? The display code accesses the buffer text directly, using > > > BYTE_POS_ADDR. > > > > I didn't say it wouldn't have to be touched at all : ) xdisp.c has > > only 8 occurences of BYTE_POS_ADDR, that doesn't appear too bad. > > Why does it matter how many times BYTE_POS_ADDR is used? If you > change the implementation of BYTE_POS_ADDR, the replacement is a > mechanical job, no matter if there are 8 places or 800 to make the > change.