From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Exposing buffer text modifications to Lisp Date: Wed, 22 Jun 2022 19:13:42 +0300 Message-ID: <83v8ssisll.fsf@gnu.org> References: <2c2746e5f2558a87e8eab6f0914264a020173a9d.camel@pm.me> <27630AA3-8026-4E24-8852-ACCD9325B99D@gmail.com> <0E9E702B-B07C-4794-8498-29B9320E14CC@gmail.com> <871qvorqvv.fsf@localhost> <83tu8jq2vl.fsf@gnu.org> <87sfo37etn.fsf@localhost> <834k0jplcm.fsf@gnu.org> <878rpuwm9w.fsf@localhost> <83mteao3oj.fsf@gnu.org> <87edzmv3i0.fsf@localhost> <83k09eo1p5.fsf@gnu.org> <878rpuv17q.fsf@localhost> <83fsk2nyrm.fsf@gnu.org> <878rpr4kd4.fsf@localhost> <8335fzms6q.fsf@gnu.org> <87h74cya4u.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40418"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@gmail.com, casouri@gmail.com, emacs-devel@gnu.org To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 22 18:14:44 2022 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 1o4307-000AJt-UB for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Jun 2022 18:14:44 +0200 Original-Received: from localhost ([::1]:37538 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4306-0000rT-TQ for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Jun 2022 12:14:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o42zI-0000AQ-Is for emacs-devel@gnu.org; Wed, 22 Jun 2022 12:13:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45872) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o42zH-00066N-Kc; Wed, 22 Jun 2022 12:13:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=3sKRjO+YHgkuUscictwIfcq9Wv4vQOU0wgLHxoAoS7U=; b=Xm5VS3gtRC6yLZ8UxH59 3gettAk9s5szrAJbFG4vsvQV5HkUL+HkMsCfKNe4m4MdobBbEkoJCdArYEv9S88YhzrFMZ1ByT48D obWa1PpG2QVFcHBGU/lPYtPxrkU7yr+8P3V93s4sc420LQjr5lFkiAfmnVtKFGj82497eeAmM8y3v /8r35z6y5iGCUtj/Y/qSVYPvqKTL3G4w8sLyQpqn9no4nV3NEERHMcqD2XllC9ORpnZcgSb7SqZXT 8/uARRNigY7DJUUuDAhq/VZAzR3OCoGdcaN0jpgw/BaoxEG2O6bxwR12afISP7x9kIs5YjFmQZRsC JTTL8whqU8+MQQ==; Original-Received: from [87.69.77.57] (port=4307 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o42zH-0000Js-3w; Wed, 22 Jun 2022 12:13:51 -0400 In-Reply-To: <87h74cya4u.fsf@tcd.ie> (contovob@tcd.ie) 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" Xref: news.gmane.io gmane.emacs.devel:291514 Archived-At: > From: "Basil L. Contovounesios" > Cc: Ihor Radchenko , casouri@gmail.com, > emacs-devel@gnu.org > Date: Wed, 22 Jun 2022 18:45:53 +0300 > > Would any of Gnulib's generic container types[0] be appropriate in this > case, and if so, fair game for using in Emacs' sources? > > [0]: (info "(gnulib) Container data types") > https://gnu.org/s/gnulib/manual/html_node/Container-data-types.html Could be. But I think we need more research before we decide. Someone™ should study the usage patterns of the markers for character-to-byte translation, and see which operations should be the fastest and which could be slower. Armed with that information, we could then select the best data structure for the job. Btw, do we have recipes for measuring the effects of changing the data structures used for markers? If we do have such recipes, did someone try to compare the performance in plain-ASCII Org buffers (where the conversion is trivial and shouldn't even access the markers) and non-ASCII buffers? Inserting a single non-ASCII character somewhere in an otherwise plain-ASCII buffer should show the effect of many markers on the likes of CHAR_TO_BYTE.