From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) Date: Mon, 29 Aug 2016 21:15:52 -0400 Message-ID: References: <20160731121642.GB2205@acm.fritz.box> <83a8gxq288.fsf@gnu.org> <87h9ag3j8c.fsf@russet.org.uk> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472547423 7799 195.159.176.226 (30 Aug 2016 08:57:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 08:57:03 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 10:56:59 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1beeql-0001Ji-Og for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 10:56:55 +0200 Original-Received: from localhost ([::1]:47859 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beeqm-0007rD-NE for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 04:56:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beelT-0003F8-Sy for emacs-devel@gnu.org; Tue, 30 Aug 2016 04:51:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beelM-0000p9-Km for emacs-devel@gnu.org; Tue, 30 Aug 2016 04:51:26 -0400 Original-Received: from [195.159.176.226] (port=34733 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beelM-0000oP-EZ for emacs-devel@gnu.org; Tue, 30 Aug 2016 04:51:20 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1beXbo-0005Lk-8W for emacs-devel@gnu.org; Tue, 30 Aug 2016 03:13:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 78 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:JcGBywVuihG5vkhamysH4LYnaXM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206922 Archived-At: > (or > ;; previously this was not skewed if no region, but actually, > ;; if there is no region we need to copy everything, we can > ;; also do by declaring skew -- this is important for the > ;; multi-lentic situation > (not (or start stop length-before)) > ;; skews only occur in insertions which result in a positive > ;; length-before. This also picks up no-insertion changes > (and (< 0 length-before) > ;; = start stop means we have a deletion because > ;; there is no range after. Deletions seem to be > ;; safe. > (not (= start stop)))) I don't understand what this is doing. It seems to be looking for indirect clues rather than checking directly for the properties on which the code relies. Why not do something like: (defun lentic--b-c-f (start end) (setq-local lentic--b-c-pos (cons start end)) ...) (defun lentic--a-c-f (start end length) (if (prog1 (not (and (eq start (car lentic--b-c-pos)) (eq (+ start length) (cdr lentic--b-c-pos)))) (setq lentic--b-c-pos nil)) ;; This a-c-f is not properly paired with the previous b-c-f. ;; Proper pairing )) If the performance issue is serious enough, you can of course try to "do it right" with something like: (defun lentic--b-c-f (start end) (setq-local lentic--b-c-data (cons start (buffer-substring start end))) ...) (defun lentic--a-c-f (start end length) ;; Get the before-change content of start..end. (let ((old-text (substring (cdr lentic--b-c-data) (- start (car lentic--b-c-data)) (- end length (car lentic--b-c-data))))) ;; Update lentic--b-c-data for possible subsequent other a-c-f calls. (setcdr lentic--b-c-data (concat (substring (cdr lentic--b-c-data) 0 (- start (car lentic--b-c-data))) (buffer-substring start end) (substring (cdr lentic--b-c-data) (- end length (car lentic--b-c-data))))) )) But it can admittedly be cumbersome since the old-text is now in a string rather than being inside the buffer. > 1) being able to know when b-c-f and a-c-f are not paired or consistent > would be useful Does the above lentic--b-c-pos give the needed info? > 2) decreasing the number of times these occurs would be useful, even if > it cannot be removed entirely. Note that in the subst-char-in-region you could "make it pairup" yourself by hand: if you have (< (+ start length) (cdr lentic--b-c-pos)), then you can just (let ((diff (- (cdr lentic--b-c-pos) (+ start length)))) (cl-incf length diff) (cl-incf end diff)) such that (eq (+ start length) (cdr lentic--b-c-pos)). Stefan