From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: buffer-modified-tick and text properties Date: Sat, 20 Apr 2024 08:47:42 -0400 Message-ID: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5E625D5A-036B-462D-9576-5ED56E8FF5D7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27178"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 20 14:48:46 2024 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 1ryA98-0006yN-KP for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Apr 2024 14:48:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ryA8Q-0007XX-5S; Sat, 20 Apr 2024 08:48:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ryA8O-0007XG-6f for emacs-devel@gnu.org; Sat, 20 Apr 2024 08:48:01 -0400 Original-Received: from mail-io1-xd2f.google.com ([2607:f8b0:4864:20::d2f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ryA8M-0006Uw-7N for emacs-devel@gnu.org; Sat, 20 Apr 2024 08:47:59 -0400 Original-Received: by mail-io1-xd2f.google.com with SMTP id ca18e2360f4ac-7d5db134badso119733239f.2 for ; Sat, 20 Apr 2024 05:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713617275; x=1714222075; darn=gnu.org; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=6PJY+IbNAwDHP9tpmWPVsDvcPRxbISMy+XwxVd7jTaw=; b=JmBysGYb9Iau05zFvy3Is8AjcOje1IWkPb5VKwdoopO67PlmzuLSycX2DfcK+0X/Oq r6t+iicRDbu1kYZ1W5T5n7NXDaUkgpmuuJVHWKEbs49nLTCWrHlbe7LxXRjcS8udkAdi 2DeASgqzAA9eM9JPYOeLuNWyf6rzf5zXIol7PGGtWSrh2kZsAwAsT1dskF33SFXWnm3y MXL5BIIWg7iAI/ZmPq3cF6ZLZAYok1tANsFWqY0k0Q4zPm18D7bPpvil72w3ceNOu9KY wktpfFXdWAZ2i/VbJ2e+DnTa9uLUXI2vyz2X7iG4Ly8bWxstv3NYIPTJ2mF+3hLWjULF mIPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713617275; x=1714222075; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6PJY+IbNAwDHP9tpmWPVsDvcPRxbISMy+XwxVd7jTaw=; b=mFBM6HndmCkOP4XVcCSlP6Ge9S+lPx2o8J9Ry8LQT8ED2WQLP6Lrdsv9xV87x44Rq6 oJzT4/a9UnhBBGjiOQfQsdFMv/E08tLR/LJGszFezZh7Zdvffb2qJy4LROJhRjJzdcd1 w28WW6M898aguRFEUnzezAT+1M6i6hY5Q4gQV+CsUenpQTirPCaiJLx/sF8GQ85boGOU VnQz0NuBwepkRg4U622D2XbejB1CTaWgGYnJX0vNAxjQNk0xzmnCDQhs7gyP8kY5KfpB aPLbar+i3UVqQ97/zbSbk1gBuSl6BeXopVdA7ZyRofeukv25BfgXOZe2rr+yLzr5OTGK AKPQ== X-Gm-Message-State: AOJu0Yyjp9ZJUYffi2nTsvx3t04QMC3YGkDHwEavCC2Gfp2KPV9ZeijU QDNi1F1d8dRiajVHhfE+Y2Yz08PulfgeZ1fJc4lzTTNy1pgscFYUaalGUw== X-Google-Smtp-Source: AGHT+IGJNPcv9PoqJn0ljr0NaBcJfrHf9cz4vv3HWq2z344I8I+MzKHQvbmUwTIJEZdYV1TTD7m/fw== X-Received: by 2002:a05:6602:3291:b0:7d5:eae7:6996 with SMTP id d17-20020a056602329100b007d5eae76996mr5812960ioz.18.1713617274905; Sat, 20 Apr 2024 05:47:54 -0700 (PDT) Original-Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id jc18-20020a056638891200b004828de28211sm1613684jab.115.2024.04.20.05.47.53 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Apr 2024 05:47:53 -0700 (PDT) X-Mailer: Apple Mail (2.3774.500.171.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::d2f; envelope-from=jdtsmith@gmail.com; helo=mail-io1-xd2f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317875 Archived-At: --Apple-Mail=_5E625D5A-036B-462D-9576-5ED56E8FF5D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've read plenty of older threads discussing why text property changes = mark buffers as modified, recommending people use=20 (with-silent-modifications (code-which-modifies-text-properties))=20 in most cases. This prevents buffer-modified-p from flipping, but it = surprised me that this does not prevent changes to the = buffer-modified-tick: >>>>>>>>>>>>>>>>>>>>>>>> ;; Testing buffer-tick with text props (let ((msg '())) (set-buffer-modified-p nil) (push (format "Before: BMT: %d BMP: %s" (buffer-modified-tick) (buffer-modified-p)) msg) (with-silent-modifications (put-text-property 1 2 'display "T")) (push (format "After: BMT: %d BMP: %s" (buffer-modified-tick) (buffer-modified-p)) msg) (insert "\n;;" (string-join (nreverse msg) "\n;;"))) ;;Before: BMT: 5380 BMP: nil ;;After: BMT: 5381 BMP: nil <<<<<<<<<<<<<<<<<<<<<<<<< I had hoped to compare a saved and current buffer-modified-tick in a = post-command-hook, to tell me whether the command that lead to it had = modified the buffer text, but this is not a reliable way to do so when = text properties are being changed as a result of non-edit commands (like = motion). Plenty of modes compare the buffer tick against a saved value to infer = whether the buffer text has been modified since the last update. That = logic will be defeated if other modes make text property changes. Is = there a way to inhibit changes in the buffer-tick when you are just = changing simple text properties?= --Apple-Mail=_5E625D5A-036B-462D-9576-5ED56E8FF5D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I've read = plenty of older threads discussing why text property changes mark = buffers as modified, recommending people = use 

(with-silent-modifications = (code-which-modifies-text-properties)) 

in most cases.  This prevents buffer-modified-p from = flipping, but it surprised me that this does not prevent changes = to the buffer-modified-tick:

>>>>>>>>>>>>>>>>= ;>>>>>>>>
;; Testing buffer-tick = with text props

(let ((msg = '()))
  (set-buffer-modified-p nil)
  = (push (format
"Before: BMT: %d BMP: = %s"
= (buffer-modified-tick)
= (buffer-modified-p))
msg)
  = (with-silent-modifications
    (put-text-property 1 = 2 'display "T"))
  (push (format
"After: = BMT: %d BMP: %s"
= (buffer-modified-tick)
= (buffer-modified-p))
msg)
  (insert = "\n;;" (string-join (nreverse msg) "\n;;")))
;;Before: BMT: = 5380 BMP: nil
;;After: BMT: 5381 BMP: = nil
<<<<<<<<<<<<<&l= t;<<<<<<<<<<<

I had hoped to compare a saved and current buffer-modified-tick in = a post-command-hook, to tell me whether the command that lead to it had = modified the buffer text, but this is not a reliable way to do so when = text properties are being changed as a result of non-edit commands (like = motion).

Plenty of modes compare the buffer tick = against a saved value to infer whether the buffer text has been modified = since the last update.  That logic will be defeated if other modes = make text property changes.  Is there a way to inhibit changes in = the buffer-tick when you are just changing simple text = properties?
= --Apple-Mail=_5E625D5A-036B-462D-9576-5ED56E8FF5D7--