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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

`verilog-delete-auto' is an interactive function, so we do want to
handle that case as well.

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

Indeed, that would be to right thing to do, I think.

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

You mean we could remove verilog-save-no-change-functions from it?
If you say so, that's fine by me.

> Also why do you suggest a defvar working would be an "accident"?
> These defvars only needs to exist when compiling.

*eval*uating (defvar foo) has no effect, other than to declare that var
to be dynamically scoped *in that scope*.  E.g.

   (defun bar ()
     (defvar foo)
     ...)

make `foo' be dynamically scoped in that scope.  So

   (eval-when-compile
     (defvar foo)
     ...)

Would most logically make `foo' be dynamically scoped within the
eval-when-compile but not outside of it.

The only reason why it works is an implementation accident:
eval-when-compile (when run from the byte-compiler) first compiles its
body, and that has the side-effect that it ends up declaring `foo' also
outside of the eval-when-compile.  It also has a few other side-effect,
and like this one, some of them are halfway between bugs and features.

>> (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?

Because it avoids forcing a recomputation of the mode-line.

> The documentation suggests this may be suspicious.

But in the present case, restore-buffer-modified-p would indeed
restore the buffer-modified-p state, thus there's no need to recompute
the mode-line.

This was introduced specifically for this kind of use.  See for example
the definition of with-silent-modifications.


        Stefan