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

[Stefan Monnier]

Hi Wilson,

Did (or will) you install a patch along the lines fleshed out in
this thread?
If you prefer I can do it on the Emacs side instead, but I'd rather you
do it, since you're in a better position to make sure it actually works.


        Stefan


>>>>> "Stefan" == Stefan Monnier <address@hidden> writes:

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