uniquify

uniquify

[Dennis Yurichev]

Hi.

I added this to my .emacs:
===================================================
(require 'uniquify)
(setq uniquify-buffer-name-style 'forward)
===================================================
But nothing happens, buffer names still has <n> at the end.

What/where should I check? 
I've got GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601).

-- 
-- http://yurichev.com

Re: uniquify

[Alex Kost]

Dennis Yurichev (2014-06-21 02:35 +0400) wrote:

> Hi.
>
> I added this to my .emacs:
> ===================================================
> (require 'uniquify)
> (setq uniquify-buffer-name-style 'forward)
> ===================================================
> But nothing happens, buffer names still has <n> at the end.
>
> What/where should I check?
> I've got GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601).

If you mean the buffers like "*shell*<2>" or "*info*<2>" then it should
be so.  "uniquify" deals only with the buffers that have the same name.
For example if you open 2 files "temp.el" from different directories,
than "uniquify" will uniquify them.

Re: uniquify

[Dennis Yurichev]

Alex Kost <alezost@gmail.com> writes:

>> I added this to my .emacs:
>> ===================================================
>> (require 'uniquify)
>> (setq uniquify-buffer-name-style 'forward)
>> ===================================================
>> But nothing happens, buffer names still has <n> at the end.
>>
>> What/where should I check?
>> I've got GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601).
>
> If you mean the buffers like "*shell*<2>" or "*info*<2>" then it should
> be so.  "uniquify" deals only with the buffers that have the same name.
> For example if you open 2 files "temp.el" from different directories,
> than "uniquify" will uniquify them.

No, I opened several files with the same name, but buffers are 
still <2>, <3>, etc...

-- 
-- http://yurichev.com

Re: uniquify

[Dennis Yurichev]

Alex Kost <alezost@gmail.com> writes:

>> I added this to my .emacs:
>> ===================================================
>> (require 'uniquify)
>> (setq uniquify-buffer-name-style 'forward)
>> ===================================================
>> But nothing happens, buffer names still has <n> at the end.
>>
>> What/where should I check?
>> I've got GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601).
>
> If you mean the buffers like "*shell*<2>" or "*info*<2>" then it should
> be so.  "uniquify" deals only with the buffers that have the same name.
> For example if you open 2 files "temp.el" from different directories,
> than "uniquify" will uniquify them.

Here is also screenshot I made:
http://yurichev.com/tmp3/emacs_problem.png

-- 
-- http://yurichev.com

Re: uniquify

[Dennis Yurichev]

Alex Kost <alezost@gmail.com> writes:

>> I added this to my .emacs:
>> ===================================================
>> (require 'uniquify)
>> (setq uniquify-buffer-name-style 'forward)
>> ===================================================
>> But nothing happens, buffer names still has <n> at the end.
>>
>> What/where should I check?
>> I've got GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601).
>
> If you mean the buffers like "*shell*<2>" or "*info*<2>" then it should
> be so.  "uniquify" deals only with the buffers that have the same name.
> For example if you open 2 files "temp.el" from different directories,
> than "uniquify" will uniquify them.

I found a problem.
Maybe that story will be useful for someone, so I'll post it here.
My Emacs saving buffer configuration into emacs.desktop file
automatically, so names like main.tex<2> and main.tex<3> were saved and
reloaded there each time at startup, and uniquify.el hasn't any chance to
name them properly.
My bad!

-- 
-- http://yurichev.com

uniquify

[Sean Sieger]

Huh.  I guess I would have thought that whether a buffer is a Dired one
or file one, uniquify would follow the rule that I have configured in
.emacs:  (setq uniquify-buffer-name-style 'forward).

I had inadvertantly visited a Dired buffer of the same name as the file
that I was on my way to visit, then visited the file, whose buffer name
had appended to it, `<2>'.

To sooth myself, I then visited two files of the same name in different
directories and the buffer names had the expected directory-difference
prepended to them.

Uh, my question is, does anyone else perceive this as a little clunky?
I could never perceive the <2>, <3> -thing as clarifying and was pleased
to get rid of it---or so I thought---with uniquify ... thanks.

Re: uniquify

[Sean Sieger]

    I had inadvertantly visited a Dired buffer of the same name as the file
    that I was on my way to visit, then visited the file, whose buffer name
    had appended to it, `<2>'.

I don't get it.  I'm tellin' ya, I saw a buffers named <name> and
<name><2> last night.  I can't reproduce it now.  Sorry for the noise.

Uniquify

[Stefan Monnier]

OK, I think i'm finally done with my uniquify hacking and there's
two things still left for me to do:

- Revert the patch that made Gnus' "(un)sent" buffers unmanaged.  The new
  code should handle those buffers correctly: either they'll be unmanaged
  anyway (if Gnus never calls either `create-file-buffer' on them or
  `rename-buffer' with a non-nil `unique' argument) or they'll be managed
  but uniquify will still preserve their name.  I.e. if the buffer-file-name
  is ~/foo/drafts/7 and the buffer-name was "*unsent bar*", uniquify
  will at worst use a buffer-name of the form "*unsent bar*|foo/drafts"

- Change the default of uniquify-after-kill-buffer-p to t (we could
  also change its name, but I don't care enough to do it myself).
  The docstring of uniquify-after-kill-buffer-p used to say that it's
  a dangerous feature because it can change buffer names behind packages'
  backs and that if packages remember their buffers by name (rather
  than directly by buffer) there can be trouble.
  I removed that text because the text applies to the whole of uniquify
  rather than just to uniquify-after-kill-buffer-p.  OTOH, it is true
  that uniquify-after-kill-buffer-p made the problem slightly worse because
  it caused all buffer-names to be reconsidered after a kill-buffer,
  including buffers which had never been uniquified before.  This has
  now been fixed, so I think we can safely change the default.


	Stefan


--- uniquify.el.~1.49.~	Fri May  9 09:17:05 2003
+++ uniquify.el	Fri May  9 09:19:34 2003
@@ -111,7 +111,7 @@
 		(const :tag "standard Emacs behavior (nil)" nil))
   :require 'uniquify)
 
-(defcustom uniquify-after-kill-buffer-p nil
+(defcustom uniquify-after-kill-buffer-p t
   "If non-nil, rerationalize buffer names after a buffer has been killed."
   :type 'boolean)
 
@@ -122,7 +122,7 @@
   :type 'boolean)
 
 ;; The default value matches certain Gnus buffers.
-(defcustom uniquify-ignore-buffers-re "^\\*\\(un\\)?sent "
+(defcustom uniquify-ignore-buffers-re nil
   "*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