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

[Wilson Snyder]

I have this on a branch awaiting testing on older Emacsen (21 etc).  I'll get 
that done and applied into Emacs trunk.

-Wilson


Stefan Monnier <address@hidden> writes:

>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