10:05 p.m.
Hi,
this might be a small and simple problem --- but (to be honest) it
took me almost a year to figure it out:
The problem
-----------
If you use uniquify, you can allow it to rename the buffer names after
a buffer has been killed:
(setq uniquify-after-kill-buffer-p t)
For example, if you had the buffers: <foo|bar1> and <foo|bar2>, and
now you killed <foo|bar2>, uniquify will automatically rename
<foo|bar1> to <foo>.
However, if you do this, info will be broken. This is because AFTER A
WHILE the *info* buffer is renamed to the name of the currently
visited info-file. A new call of F1-i then messes up everything, the
history is broken, links are broken, etc.
The problem is that uniquify renames ALL buffers after any buffer has
been killed, including the *info* buffer (it usually renames it to the
name of the info file).
The solution
------------
... is simple. One can exclude the info buffer from being renamed by
setting:
(setq uniquify-ignore-buffers-re "^\\*info\\*$")
I found this problem hard to track because it shows up only after a
while (when I killed some buffer) --- I always suspected my info-dir
settings to be somehow erroneous. Therefore, I would like to suggest
to make this setting the default for uniquify-ignore-buffers-re
(instead of nil):
======================================================================
--- uniquify.orig Mon Oct 1 22:51:41 2001
+++ uniquify.el Mon Oct 1 22:52:16 2001
＠＠ -127,7 +127,7 ＠＠
:type 'boolean
:group 'uniquify)
-(defcustom uniquify-ignore-buffers-re nil
+(defcustom uniquify-ignore-buffers-re "^\\*info\\*$"
"*Regular expression matching buffer names that should not be uniquified.
For instance, set this to \"^draft-[0-9]+$\" to avoid having uniquify rename
draft buffers even if `uniquify-after-kill-buffer-p' is non-nil and the
======================================================================
???
Cheers
Volker
--
___________________________________________________________
Volker Franz
Max-Planck-Institut fuer biologische Kybernetik
Spemannstr. 38
72076 Tuebingen
Tel : ++49 (0)7071/601-606
Fax : ++49 (0)7071/601-616
mailto:volker.franz＠tuebingen.mpg.de
http://www.kyb.tuebingen.mpg.de/bu
___________________________________________________________
10:16 p.m.
On Mon, 1 Oct 2001, Volker Franz uttered the following:
this might be a small and simple problem --- but (to be honest) it
took me almost a year to figure it out:
Well done; I haven't managed to figure it out at all.
If you use uniquify, you can allow it to rename the buffer names
after
a buffer has been killed:
(setq uniquify-after-kill-buffer-p t)
For example, if you had the buffers: <foo|bar1> and <foo|bar2>, and
now you killed <foo|bar2>, uniquify will automatically rename
<foo|bar1> to <foo>.
However, if you do this, info will be broken. This is because AFTER A
WHILE the *info* buffer is renamed to the name of the currently
visited info-file. A new call of F1-i then messes up everything, the
history is broken, links are broken, etc.
The problem is that uniquify renames ALL buffers after any buffer has
been killed, including the *info* buffer (it usually renames it to the
name of the info file).
Good god, is *that* it? No wonder I never managed to debug it :(
The solution
------------
... is simple. One can exclude the info buffer from being renamed by
setting:
(setq uniquify-ignore-buffers-re "^\\*info\\*$")
I found this problem hard to track because it shows up only after a
Likewise. I'm amazed you managed it, actually.
while (when I killed some buffer) --- I always suspected my info-dir
settings to be somehow erroneous. Therefore, I would like to suggest
to make this setting the default for uniquify-ignore-buffers-re
(instead of nil):
======================================================================
--- uniquify.orig Mon Oct 1 22:51:41 2001
+++ uniquify.el Mon Oct 1 22:52:16 2001
＠＠ -127,7 +127,7 ＠＠
:type 'boolean
:group 'uniquify)
-(defcustom uniquify-ignore-buffers-re nil
+(defcustom uniquify-ignore-buffers-re "^\\*info\\*$"
"*Regular expression matching buffer names that should not be uniquified.
For instance, set this to \"^draft-[0-9]+$\" to avoid having uniquify rename
draft buffers even if `uniquify-after-kill-buffer-p' is non-nil and the
======================================================================
This is still not ideal, because the real criterion is `bucffers whose
mode is Info-mode'; this will still break people who rename their Info
buffers themselves.
In the interests of insane generality, and to make it easier to add new
exclusion classes to uniquify, might I suggest something like the
following (disclaimer: not heavily tested but it seems to stop the
problem here)...
(btw, is there a better customization type for hooks than `lisp'? I
tried to write one and gave up, but then I'm a customize newbie.)
2001-10-05 Nix <nix(a)esperi.demon.co.uk>
* uniquify.el (uniquify-ignore-buffers-query-functions): New hook,
called to determine buffers not to uniquify.
(uniquify-rationalize-file-buffer-names): Use it...
(uniquify-ignore-buffers-re): ... reimplement in terms of it.
New function.
(uniquify-ignore-buffers-mode-re): New variable and function.
--- edit-utils/uniquify.el~ Fri Oct 5 21:00:42 2001
+++ edit-utils/uniquify.el Fri Oct 5 22:10:06 2001
＠＠ -130,6 +130,20 ＠＠
:type '(choice (const :tag "Uniquify all buffers" nil) regexp)
:group 'uniquify)
+(defcustom uniquify-ignore-buffers-mode-re "^Info-mode$"
+ "*Regexp matching names of major modes of buffers that should not be uniquified.
+For instance, set this to \"^\\\\(Info\\\\)\\\\|\\\\(message\\\\)-mode$\" to
avoid
+having uniquify rename Info and mail message buffers."
+ :type '(choice (const :tag "Uniquify all buffers" nil) regexp)
+ :group 'uniquify)
+
+(defcustom uniquify-ignore-buffers-query-functions '(uniquify-ignore-buffers-re
+ uniquify-ignore-buffers-mode-re)
+ "*Functions to call to determine if a buffer name should not be uniquified.
+The functions are called with one argument, the buffer. If any function returns
+t, the buffer name is not uniquified."
+ :group 'uniquify)
+
(defcustom uniquify-min-dir-content 0
"*Minimum number of directory name components included in buffer name."
:type 'integer
＠＠ -202,10 +216,9 ＠＠
(uniquify-buffer-file-name buffer)))
(rawname (and bfn (uniquify-file-name-nondirectory bfn)))
(deserving (and rawname
- (not (and uniquify-ignore-buffers-re
- (string-match
- uniquify-ignore-buffers-re
- (buffer-name buffer))))
+ (not (run-hook-with-args-until-success
+ 'uniquify-ignore-buffers-query-functions
+ buffer))
(or (not newbuffile)
(equal rawname
(uniquify-file-name-nondirectory
＠＠ -440,6 +453,24 ＠＠
(remove-hook 'post-command-hook
'delayed-uniquify-rationalize-file-buffer-names))
+(defun uniquify-ignore-buffers-re (buffer)
+ "Returns t if the BUFFER's name matches `uniquify-ignore-buffers-re'.
+Meant to be called from the `uniquify-ignore-buffers-query-functions'."
+ (and uniquify-ignore-buffers-re
+ (string-match
+ uniquify-ignore-buffers-re
+ (buffer-name buffer))))
+
+(defun uniquify-ignore-buffers-mode-re (buffer)
+ "Returns t if the BUFFER's major mode matches
`uniquify-ignore-buffers-mode-re'.
+Meant to be called from the `uniquify-ignore-buffers-query-functions'."
+ (and uniquify-ignore-buffers-mode-re
+ (string-match
+ uniquify-ignore-buffers-mode-re
+ (symbol-name (with-current-buffer buffer
+ major-mode)))))
+
+
(add-hook 'kill-buffer-hook 'delay-uniquify-rationalize-file-buffer-names)
;;; uniquify.el ends here
--
`Upsetting this BOFH was a BAD MOVE.' --- Chris Newport
7:53 p.m.
I am glad you like the suggestion!
>>>> "n" == nix <nix(a)esperi.demon.co.uk>
writes:
n> This is still not ideal, because the real criterion is
n> `buffers whose mode is Info-mode'; this will still break
n> people who rename their Info buffers themselves.
You are right. I included your patch to my uniquify.el and it works
for me so far.
One more idea (for generality): One could restrict uniquify to
change only buffers for which the basename corresponds to the
visited file. Example:
buffer-base-name file-name change-allowed
-----------------------------------------------------------
*info* new-users-guide.info-1 no
*info* dir no
foo ~/bar1/foo yes
foo ~/bar2/foo yes
I think this would solve the problem without having to explicitly
specify which modes (or files) should be excluded... But I do not know
how much coding effort this would be (and unfortunately will have no
time to check during the next weeks :-(
Volker
--
2:37 a.m.
From: Volker Franz <volker.franz(a)tuebingen.mpg.de>
Date: Wed, 10 Oct 2001 20:53:37 +0200
I am glad you like the suggestion!
>>>> "n" == nix <nix(a)esperi.demon.co.uk>
writes:
n> This is still not ideal, because the real criterion is
n> `buffers whose mode is Info-mode'; this will still break
n> people who rename their Info buffers themselves.
One more idea (for generality): One could restrict uniquify to
change only buffers for which the basename corresponds to the
visited file. Example:
buffer-base-name file-name change-allowed
-----------------------------------------------------------
*info* new-users-guide.info-1 no
*info* dir no
foo ~/bar1/foo yes
foo ~/bar2/foo yes
I think this would solve the problem without having to explicitly
specify which modes (or files) should be excluded... But I do not know
how much coding effort this would be (and unfortunately will have no
time to check during the next weeks :-(
A slightly different idea is to integrate things like info, hyper
apropos, mail, etc with uniquify. Eg, if I am using uniquify then
different packages like info/hyper apropos/mail should create
uniquified names - eg info<vm>, reply<xemacs-beta>, apropos<uniquify>
I can never remember the naming scheme for the different buffers like
info and apropos - does it start with a space, a *? was that H or h?
-jeff
9:12 a.m.
>>>> "JM" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
JM> A slightly different idea is to
integrate things like info,
JM> hyper apropos, mail, etc with uniquify. Eg, if I am using
JM> uniquify then different packages like info/hyper apropos/mail
JM> should create uniquified names - eg info<vm>,
JM> reply<xemacs-beta>, apropos<uniquify>
To my understanding renaming the *info* buffer would not work with the
standard info.el package as it is right now. In this package the
buffer is called by its name, and the name is hardcoded. It might,
however, be easy to change. (I just checked, the buffer name occurs
only in 8 places:
583: (if (get-buffer "*info*")
584: (switch-to-buffer "*info*")
659: (switch-to-buffer "*info*")
747: (if (not (eq (current-buffer) (get-buffer "*info*")))
1385: (set-buffer (get-buffer "*info*"))
2315: (pop-to-buffer "*info*"))
2362: (pop-to-buffer "*info*"))))
2385: (pop-to-buffer "*info*"))
Volker
--
3:53 p.m.
Hi,
quite a while ago, we discussed an incompatibility of Info and uniquify:
http://list-archive.xemacs.org/xemacs-beta/200110/msg00013.html
Now, (after being away for 6 weeks of traveling :-), I would like
bring this up again. My suggestion is, to use Nix's solution --- it
seems to me as being the most general:
http://list-archive.xemacs.org/xemacs-beta/200110/msg00064.html
I have only a tiny, little suggestion for the customization of the
uniquify-ignore-buffers-query-functions:
>>>> "n" == nix <nix(a)esperi.demon.co.uk>
writes:
n> (btw, is there a better customization type for hooks than
n> `lisp'? I tried to write one and gave up, but then I'm a
n> customize newbie.)
For me, the following works:
----------------------------------------------------------------------
(defcustom uniquify-ignore-buffers-query-functions '(uniquify-ignore-buffers-re
uniquify-ignore-buffers-mode-re)
"*Functions to call to determine if a buffer name should not be uniquified.
The functions are called with one argument, the buffer. If any function returns
t, the buffer name is not uniquified."
:type '(repeat (symbol :format "%v"))
:group 'uniquify)
----------------------------------------------------------------------
--- or do I miss something here?
How should we proceed? Should I (or Nix) submit a patch to
xemacs.patches?
Best
Volker
--
12:16 a.m.
On Tue, 18 Dec 2001, Volker Franz moaned:
Now, (after being away for 6 weeks of traveling :-), I would like
bring this up again. My suggestion is, to use Nix's solution --- it
seems to me as being the most general:
http://list-archive.xemacs.org/xemacs-beta/200110/msg00064.html
It still works here :)
I have only a tiny, little suggestion for the customization of the
uniquify-ignore-buffers-query-functions:
I am a custom luser who still sticks to defvar; I rely upon others to
get defcustom working right.
----------------------------------------------------------------------
(defcustom uniquify-ignore-buffers-query-functions '(uniquify-ignore-buffers-re
uniquify-ignore-buffers-mode-re)
"*Functions to call to determine if a buffer name should not be uniquified.
The functions are called with one argument, the buffer. If any function returns
t, the buffer name is not uniquified."
:type '(repeat (symbol :format "%v"))
:group 'uniquify)
----------------------------------------------------------------------
Ooo. You probably want to use `function', not `symbol' here, maybe?
(Untested, based on a quick read of the widget info...)
--- or do I miss something here?
How should we proceed? Should I (or Nix) submit a patch to
xemacs.patches?
I'd be happy to.
--
`Mmm... Maybe I just like strong women that can hurt me?'
--- Vadik, on female throat-cutting doctors
3:04 p.m.
Hi Nix,
Ooo. You probably want to use `function', not `symbol' here,
maybe?
(Untested, based on a quick read of the widget info...)
You are right. I checked it --- and it works (with `function'
instead of `symbol').
> How should we proceed? Should I (or Nix) submit a patch to
> xemacs.patches?
I'd be happy to.
Cool!!!
Volker
12:09 p.m.
Hi Nix,
Ooo. You probably want to use `function', not `symbol'
here, maybe?
(Untested, based on a quick read of the widget info...)
You are right. I checked it --- and it works (with `function'
instead of `symbol').
> How should we proceed? Should I (or Nix) submit a patch to
> xemacs.patches?
I'd be happy to.
Cool!!!
Volker
--
11:15 p.m.
On 19 Dec 2001, nix(a)esperi.demon.co.uk stipulated:
> How should we proceed? Should I (or Nix) submit a patch to
> xemacs.patches?
I'd be happy to.
Done (with your change, and some word-wrapping fixes.)
--
`Mmm... Maybe I just like strong women that can hurt me?'
--- Vadik, on female throat-cutting doctors
8710
days inactive
8796
days old
9 comments
3 participants
participants (3)
-
Jeff Mincy -
Nix -
Volker Franz