From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Request for pointers and advice: displaying several buffers inside a single window Date: Sat, 11 Apr 2020 16:35:58 +0800 Message-ID: <87blnyxvv5.fsf@localhost> References: <83a73swwd7.fsf@gnu.org> <87wo6nxsjz.fsf@localhost> <83d08fmgul.fsf@gnu.org> <87tv1rxmgc.fsf@localhost> <83a73jmcyo.fsf@gnu.org> <87pncfxk4m.fsf@localhost> <837dynm9yb.fsf@gnu.org> <87h7xrxhh5.fsf@localhost> <831roumq6n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="125812"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dim1212k@gmail.com, adam@alphapapa.net, casouri@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 11 10:40:25 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 1jNBgf-000WdA-4w for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 10:40:25 +0200 Original-Received: from localhost ([::1]:49926 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNBge-0005nm-6o for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 04:40:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36010) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNBg4-0005Ie-3S for emacs-devel@gnu.org; Sat, 11 Apr 2020 04:39:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNBg1-0002C2-Sp for emacs-devel@gnu.org; Sat, 11 Apr 2020 04:39:47 -0400 Original-Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]:36990) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jNBfz-00026r-UV; Sat, 11 Apr 2020 04:39:44 -0400 Original-Received: by mail-pj1-x1035.google.com with SMTP id z9so1614925pjd.2; Sat, 11 Apr 2020 01:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=aQ3Zi367Tj9AONSNmIoOg22ywca8RopVQGWRc1jBAyU=; b=OSSVCX4uH3fEI1D5jGrRkrRYwl9ewooe2t3f7N11E+ly72hHIoD1BKOyOt7wE9O0Lr YrVRXyoRoDBUre6dqF0cGoDfpNA2gmMUCWUSycpRjObIpZknb1hbOLU4m7vzDHA4GZOC caILkmuzo5dL7lA/UWunQoCxm/HkhcGSGnLE+A59X304a7B544FNSoYC8STuYDRGFfqr auXvYhq10hfdRCeIIhz8ThlatOk8PI5dIqS2FeJr77zp6GslRV8mziqNfyLuG1VgQtAY a3hYYODjYZOKF4aauWApmdOsK6nWpKAHPZ/fstF2LdYhwITmCzd//bV8fxEDkp6gPYVf LfTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=aQ3Zi367Tj9AONSNmIoOg22ywca8RopVQGWRc1jBAyU=; b=d0idOZUceqD+zMHmabl+6y77j/OuH4Yz7svP4Xb2OwddU++DwOie1ju6n9G3GRxsDj oQq8MoB2LunB6HCz1kPF7M6UebI9DMApdeaDP6bX36qCPZShC4ZFd+idBSXPljybN6NV L/eRoPToyPaCfOd6Q+tEdhqq3xVdSPafsTNTsRIBFnpNrPIL08b5TrI6p5uIis+t+ZSv YKnlEfBO1Mt2rfuinXZYmRkkXc23eSK/u1oLMFOFztEC30gx71qWHBNLfHx7/Cm9mIh/ l3FiNR4P1NelsWT40NpO7834FSJPEMJZ6mUK4IZEuHn/mWRpNLhJd3EjV+a/B/OuyxKx IyDA== X-Gm-Message-State: AGi0PuahwCvTv3Iao07CaGnwz11YM7STvgu6Gav/CGgC4c47gQ6ydsCH VdLwRAnHHuHKco7H2Gpy+MgVno6Zit23Hg== X-Google-Smtp-Source: APiQypIcd+v+Uf7VvVu5+jPPNYntd5KeS9dXiObzV2okYk+25b0WpvdZJbiI8c2HuoOPeMa4+mca+Q== X-Received: by 2002:a17:90b:246:: with SMTP id fz6mr615953pjb.138.1586594381564; Sat, 11 Apr 2020 01:39:41 -0700 (PDT) Original-Received: from localhost ([101.99.64.65]) by smtp.gmail.com with ESMTPSA id k189sm3267332pgc.24.2020.04.11.01.39.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Apr 2020 01:39:41 -0700 (PDT) In-Reply-To: <831roumq6n.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::1035 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:246827 Archived-At: > That's not the definition I'd use. The gap is a way of making text > insertion less expensive. If you insert characters one by one, each > insertion needs to move the characters after the insertion point, > which is expensive. Having the gap allows us to perform this movement > only after relatively large amounts of text were inserted; for smaller > insertions we just make the gap smaller. Do you mean that the gap is specially allocated memory space associated with buffer point where you can insert characters without a need to shift the tail of the char array containing buffer string? > My question was how you handle insertion in a segment? Move the gap > to the segment, or have a separate gap for each segment? A segment could mean two thing as I imagine: (1) pointer to original char array associated with current buffer. you can think about it as about narrowed buffer for current buffer implementation; (2) a pair of markers in different buffer. The second type of segment may refer to a char array in different buffer (just like case (1), but the char array from different buffer). Alternatively, it may refer to several other segments (if other buffer contains several segments between the markers). The last case can be reduced to a list of char arrays in different buffers. If we think about insertion, the point may be within a single segment or just between two segments. If it is within a single segment, we can identify (maybe recursively) what is the basic char array corresponding to the point. The gap will be that gap associated with that char array. In the other case, when the point is in between two segments, it narrows down to point position between two char arrays. One of this arrays (and the associated gap) will be selected depending on some criteria (maybe, something similar to what we have for overlays/sticky text properties). I hope that my explanation is clear enough. Eli Zaretskii writes: >> From: Ihor Radchenko >> Cc: casouri@gmail.com, dim1212k@gmail.com, adam@alphapapa.net, >> emacs-devel@gnu.org >> Date: Sat, 11 Apr 2020 03:34:30 +0800 >> >> > And what do you suggest to do with the gap? >> >> This is where the buffer text is stored internally right? > > That's not the definition I'd use. The gap is a way of making text > insertion less expensive. If you insert characters one by one, each > insertion needs to move the characters after the insertion point, > which is expensive. Having the gap allows us to perform this movement > only after relatively large amounts of text were inserted; for smaller > insertions we just make the gap smaller. > >> I think a >> "segment" may as well refer to a substring from the gap. In the simplest >> case the list of "segments" would contain a single element referring to >> the whole gap. Then, if one adds another "segment", the list will hold 3 >> elements: ( >> ). > > My question was how you handle insertion in a segment? Move the gap > to the segment, or have a separate gap for each segment? -- 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