[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Get rid of verilog-no-change-functions
From: |
Wilson Snyder |
Subject: |
Re: Get rid of verilog-no-change-functions |
Date: |
Tue, 15 Sep 2015 19:51:03 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
>>> As mentioned, here I'd have to understand why we need to prevent
>>> *-change-functions from running. After all, this is used in places
>>> where we make very significant changes to the buffer and where font-lock
>>> (for instance) would want to know about it.
>
>> The child functions perform hundreds of thousands of minor
>> changes, then call the hooks on everything. Doing it this
>> way makes an update maybe 10 seconds versus (as it once did)
>> many minutes - which was almost unusable. At the end of
>> everything fontification is correct.
>
>Combining all the *-change-functions calls makes a lot of sense (that's
>why we have combine-after-change-calls, for example). But I don't see
>where you "then call the hooks on everything".
>
>I see the verilog-save-font-mods which re-font-locks the buffer
>afterwards, but since it disables font-lock at the beginning it means
>that verilog-save-no-change-functions is not needed to prevent
>font-lock hooks.
>
>And of course, disabling/enabling font-lock-mode doesn't take care of
>other users of *-change-functions.
Your patches make sense, and there's no appreciable performance loss.
>Also, I see that verilog-save-no-change-functions is wrapped inside
>verilog-save-font-mods in verilog-auto, but not in verilog-delete-auto.
The common use of delete-auto is under verilog-auto itself,
so if we added it to delete-auto we'd be calling the hooks
at both auto's exiting of verilog-delete-auto and at the
exit of verilog-auto itself.
We'd then be better off pulling the guts out of
verilog-delete-auto (without
verilog-save-no-change-functions) and call those guts from
verilog-auto and verilog-delete-auto.
But anyhow I've never heard complaints of
verilog-delete-auto being slow as it makes an
order-of-magnitude fewer changes, so doesn't seem worth the
work.
>> - (unless (boundp 'inhibit-point-motion-hooks)
>> - (defvar inhibit-point-motion-hooks nil))
>> - (unless (boundp 'deactivate-mark)
>> - (defvar deactivate-mark nil))
>> + (defvar inhibit-modification-hooks)
>> + (defvar inhibit-point-motion-hooks)
>> + (defvar deactivate-mark)
>
>Those defvars should not be with an eval-when-compile (they happen to
>also work if they are, currently, but that's a mere accident).
These defvars only apply to XEmacs. I considered doing it
this way a feature, as if e.g. GNU removed one of those
variables in the future the warnings would return. Likewise
if someone sends me a bug report showing the warnings on GNU
I want to know that those variables aren't in their version.
Also why do you suggest a defvar working would be an
"accident"? These defvars only needs to exist when
compiling.
> (progn ,@body)
> (and (not modified)
> (buffer-modified-p)
>- (set-buffer-modified-p nil)))))
>+ (if (fboundp 'restore-buffer-modified-p)
>+ (restore-buffer-modified-p nil)
>+ (set-buffer-modified-p nil))))))
Can you explain why restore-buffer-modified-p is preferred?
The documentation suggests this may be suspicious.
Like `set-buffer-modified-p', with a difference
concerning redisplay. It is not ensured that mode lines
will be updated to show the modified state of the current
buffer. Use with care.