Re: problem with uniquify.el and kill-buffer-hook

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

> Recently I've noticed that the `uniquify' package has stopped working
> correctly, in particular, the feature controlled by the
> `uniquify-after-kill-buffer-p' variable doesn't work; here's the doc:
> 
>    uniquify-after-kill-buffer-p's value is t
> 
>    If non-nil, rerationalize buffer names after a buffer has been killed.
>    This can be dangerous if Emacs Lisp code is keeping track of buffers
>    by their names (rather than keeping pointers to the buffers
>    themselves).
> 
> I looked at the code a bit, and I think I found the problem:
> 
> This feature works by adding an appropriate local hook to
> `kill-buffer-hook' in all the affected buffers.
> 
> However, this is done _before_ the buffer's mode is set (in the new
> buffer that caused uniqify to be triggered); since most mode functions
> call `kill-all-local-variables', this trashes the `kill-buffer-hook'.

Duh!

> Also, any ideas why this just stopped working recently?  I didn't see
> any _obvious_ things in the ChangeLogs, but maybe I just missed it.

It's due to:

2002-09-27  Stefan Monnier  <monnier@cs.yale.edu>

	* uniquify.el (uniquify-rationalize-file-buffer-names):
	Add to kill-buffer-hook for buffers with conflict.
	(rename-buffer): Check kill-buffer-hook to see if there was a conflict.
	(uniquify-delay-rationalize-file-buffer-names): Remove useless check.
	(kill-buffer-hook): Don't change globally.

I guess it should just be reverted.  Please do it (unless you can come
up with a fix, of course).  I don't have easy access to the CVS right now.

This patch did not fix any real bug anyway.

> Another thing (whew!), is that uniquify.el uses `defadvice' (on
> `rename-buffer', and `create-file-buffer') and I wonder if it should be
> changed to just have those functions invoke it directly.

That's a long standing issue indeed.


	Stefan