Re: Get rid of verilog-no-change-functions

[Wilson Snyder]

>>> 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.