Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Stefan Monnier]

>  ;; function for expanding abbrevs and dabbrevs
> -(defalias 'vhdl-expand-abbrev (make-hippie-expand-function
> -			       '(try-expand-dabbrev
> -				 try-expand-dabbrev-all-buffers
> -				 vhdl-try-expand-abbrev)))
> +(defun vhdl-expand-abbrev (arg))
> +(fset 'vhdl-expand-abbrev (make-hippie-expand-function
> +			   '(try-expand-dabbrev
> +			     try-expand-dabbrev-all-buffers
> +			     vhdl-try-expand-abbrev)))

Why??!?!


        Stefan

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Glenn Morris]

Stefan Monnier wrote:

>>  ;; function for expanding abbrevs and dabbrevs
>> -(defalias 'vhdl-expand-abbrev (make-hippie-expand-function
>> -			       '(try-expand-dabbrev
>> -				 try-expand-dabbrev-all-buffers
>> -				 vhdl-try-expand-abbrev)))
>> +(defun vhdl-expand-abbrev (arg))
>> +(fset 'vhdl-expand-abbrev (make-hippie-expand-function
>> +			   '(try-expand-dabbrev
>> +			     try-expand-dabbrev-all-buffers
>> +			     vhdl-try-expand-abbrev)))
>
> Why??!?!

Yes, that made no sense to me either.
I meant to think about it before committing, then forgot.
My random guess would be compat with old Emacs versions.

This is how the code used to be prior to Emacs trunk r108403.
There's no ChangeLog information associated with that commit.
Knowing why it was changed that time would have helped.

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Reto Zimmermann]

Quoting Glenn Morris <rgm@gnu.org>:

> Stefan Monnier wrote:
>
>>>  ;; function for expanding abbrevs and dabbrevs
>>> -(defalias 'vhdl-expand-abbrev (make-hippie-expand-function
>>> -			       '(try-expand-dabbrev
>>> -				 try-expand-dabbrev-all-buffers
>>> -				 vhdl-try-expand-abbrev)))
>>> +(defun vhdl-expand-abbrev (arg))
>>> +(fset 'vhdl-expand-abbrev (make-hippie-expand-function
>>> +			   '(try-expand-dabbrev
>>> +			     try-expand-dabbrev-all-buffers
>>> +			     vhdl-try-expand-abbrev)))
>>
>> Why??!?!
>
> Yes, that made no sense to me either.
> I meant to think about it before committing, then forgot.
> My random guess would be compat with old Emacs versions.
>
> This is how the code used to be prior to Emacs trunk r108403.
> There's no ChangeLog information associated with that commit.
> Knowing why it was changed that time would have helped.

In 2007 I changed my own copy of vhdl-mode to use defalias.  In 2012 I  
synced some differences from the GNU distribution to my own copy, so  
it went back to defun/fset (because that's what it was in the  
repository).  I didn't think much about it, so I don't think there was  
any other reason than just to be in sync with the GNU version.

There's other things that are probably still different in my own copy  
compared to the GNU version, that I did not sync because of  
compatibility reasons.  I meanwhile dropped compatibility with XEmacs,  
but I still want to prevent any changes that are not compatible with  
older Emacs versions in the copy that I distribute on my site.

Reto

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Stefan Monnier]

> In 2007 I changed my own copy of vhdl-mode to use defalias.  In 2012
> I  synced some differences from the GNU distribution to my own copy, so  it
> went back to defun/fset (because that's what it was in the  repository).
> I didn't think much about it, so I don't think there was  any other reason
> than just to be in sync with the GNU version.

So going back to defun+fset was an accident.  Thanks.

> There's other things that are probably still different in my own copy
> compared to the GNU version, that I did not sync because of  compatibility
> reasons.  I meanwhile dropped compatibility with XEmacs,  but I still want
> to prevent any changes that are not compatible with  older Emacs versions in
> the copy that I distribute on my site.

We generally prefer it if the code in Emacs is identical to the one you
distribute, even if it means keeping compatibility code around.

We do like to make use of newer features, but in 99% of the case that
can be done without breaking compatibility.  I tend to break that
compatibility when I install my own changes, but that's usually by
accident or at worst out of laziness (e.g. sometimes I know it breaks
compatibility but I suspect that this compatibility is not important any
more, so I deliberately break it and wait to see if someone yells).

IOW, feel free to send us patches that just fix backward compatibility
issues, and if you don't know how to combine the "new" and the "old"
code, we can probably help.


        Stefan

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Reto Zimmermann]

> We generally prefer it if the code in Emacs is identical to the one you
> distribute, even if it means keeping compatibility code around.

Okay.  With the minor changes I'm making in vhdl-mode nowadays I don't  
care that much about compatibility anymore either.

> IOW, feel free to send us patches that just fix backward compatibility
> issues, and if you don't know how to combine the "new" and the "old"
> code, we can probably help.

Alright.  I will check out the code you come up with and let you know  
the things I don't like.  In the past there were changes done in the  
Emacs version that I didn't like or didn't understand and therefore I  
didn't bother to keep my copy in sync.  I will try harder now!

BTW, I was a heavy user of the (now deprecated) assoc package and  
didn't find a suitable replacement.  So I just copied the relevant  
functions into vhdl-mode.  If you have a better solution, let me know.

Reto

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Glenn Morris]

Reto Zimmermann wrote:

> BTW, I was a heavy user of the (now deprecated) assoc package and
> didn't find a suitable replacement.  So I just copied the relevant
> functions into vhdl-mode.  If you have a better solution, let me know.

At the very least, you should rename your versions to vhdl-aget, etc.

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Reto Zimmermann]

>> BTW, I was a heavy user of the (now deprecated) assoc package and
>> didn't find a suitable replacement.  So I just copied the relevant
>> functions into vhdl-mode.  If you have a better solution, let me know.
>
> At the very least, you should rename your versions to vhdl-aget, etc.

You're right, will do that.

Reto

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Reto Zimmermann]

Here's the latest version 3.35.2 with some small recent changes and  
all copied functions from assoc.el renamed to vhdl-*.

ChangeLog:
2014-03-28  Reto Zimmermann  <reto@gnu.org>

	* vhdl-mode.el
	(vhdl-compile-init): Not initialize regexps for Emacs 22+.
	(vhdl-error-regexp-emacs-alist): Remove regexps from all compilers
	except `vhdl-compiler'.
	(vhdl-template-replace-header-keywords): Fix bug for "<title string>".
	(vhdl-aput, vhdl-adelete, vhdl-aget): Rename functions from assoc.el.


Reto

-----
Attachments (links will expire on 09/30/2014):

1. vhdl-mode.el.zip (141 KB) [application/zip]
Download link:  
http://webmail.retoweb.net/imp/attachment.php?id=5335ddcf-2d6c-41b5-a438-0bdc50bef09b&u=reto%40retoweb.net

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Stefan Monnier]

> BTW, I was a heavy user of the (now deprecated) assoc package and  didn't
> find a suitable replacement.

(aget alist key t) is just a convoluted way to do (cdr (assoc key alist))
(aget alist key) is probably equivalent to

   (let ((x (assoc key alist))) (if x (or (cdr x) key)))

tho it's a sufficiently strange behavior that I doubt you'll ever
need/want it.

`aput' is generally advantageously replaced by `push'.


        Stefan

Re: [Emacs-diffs] trunk r116878: Sync with upstream vhdl mode v3.35.1

[Reto Zimmermann]

> `aput' is generally advantageously replaced by `push'.

I need more of the special behavior of 'aput', like replacing the  
value if key already exists in the alist, thus making sure there are  
no duplicates of key.  But I'm sure it can be implemented more  
efficiently, especially since I don't need the key to be sorted to the  
head of the list.

Reto