Ignacio Casso writes:
>>> + (setq buffer-undo-list
>>> + (seq-drop-while 'identity buffer-undo-list)))
>>
>> This looks fragile and can be disasterous when buffer-undo-list is
>> large.
>
> I agree that it is very fragile, but could you explain why is it also
>
>> - (delete-and-extract-region (point) (point-max)))
>> + (undo-boundary)
>
>> + (setq buffer-undo-list
>> + (seq-drop-while 'identity buffer-undo-list)))
>
> This looks fragile and can be disasterous when buffer-undo-list is
> large.
Ignacio Casso writes:
> I've written a patch proposal. It deals with buffer-modified-p and undo
> history, but not the other two points you mention. I have tested it and
> it works, but I had never dealt before with `buffer-undo-list' so maybe
> there are some cases that I have not considered
> buffer-modified-p is not the only parameter affected by juggling around
> the local variables. There will be undo history,
> buffer-chars-modified-tick, before/after-change-hooks triggered by
> `org-preserve-local-variables', etc.
>
> However, I do not see any obvious way how your proposed
Ignacio Casso writes:
> What would you think about a change like the following in the definition of
> `org-preserve-local-variables' to solve the issue?
>
> + (let ((modified-before-p) (buffer-modified-p))
> ;; current code that deletes local variables
> + (unless modified-before-p
Hello,
Copying a subtree with `org-copy-subtree' in an org file with local
variables marks the buffer as modified. This is because
`org-copy-subtree' calls `org-preserve-local-variables', which deletes
local variables, executes some body, and then inserts them again, which
results in a modified
