bug#5529: `uniquify-buffer-name-style' doesn't exist

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Alan Mackenzie]

Hi, Emacs!

On the Emacs manual page "Uniquify" ("Making Buffer Names Unique"), it
says you can change the style of buffer names like foo.c<2> by
customising the variable `uniquify-buffer-name-style'.

This variable doesn't exist.  It didn't exist in Emacs 22 or Emacs 21
either.

My feeling is that it is the code rather than the manual which is at
fault.  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Lennart Borgman]

On Fri, Feb 5, 2010 at 4:18 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Emacs!
>
> On the Emacs manual page "Uniquify" ("Making Buffer Names Unique"), it
> says you can change the style of buffer names like foo.c<2> by
> customising the variable `uniquify-buffer-name-style'.
>
> This variable doesn't exist.  It didn't exist in Emacs 22 or Emacs 21
> either.
>
> My feeling is that it is the code rather than the manual which is at
> fault.  :-)


Something is wrong... ;-)

On line 95 in uniquify.el there is something looking pretty much like
that variable...

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Glenn Morris]

Alan Mackenzie wrote:

> says you can change the style of buffer names like foo.c<2> by
> customising the variable `uniquify-buffer-name-style'.

See http://debbugs.gnu.org/2853

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Alan Mackenzie]

Hi, Lennart,

On Fri, Feb 05, 2010 at 04:56:20PM +0100, Lennart Borgman wrote:
> On Fri, Feb 5, 2010 at 4:18 PM, Alan Mackenzie <acm@muc.de> wrote:

> > On the Emacs manual page "Uniquify" ("Making Buffer Names Unique"),
> > it says you can change the style of buffer names like foo.c<2> by
> > customising the variable `uniquify-buffer-name-style'.

> > This variable doesn't exist.  It didn't exist in Emacs 22 or Emacs
> > 21 either.

> > My feeling is that it is the code rather than the manual which is at
> > fault.  :-)


> Something is wrong... ;-)

> On line 95 in uniquify.el there is something looking pretty much like
> that variable...

Yes, thanks.  I found that variable by grepping all the sources.  To get
access to it, you've got to do M-: (require uniquify), which is surely
something a "mere" user shouldn't have to do.  There also seems to be
something about it in menu-bar.el, but I haven't quite figured out what.

It just seems very, very strange.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Lennart Borgman]

On Fri, Feb 5, 2010 at 7:17 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Lennart,


Hi Alan,


> On Fri, Feb 05, 2010 at 04:56:20PM +0100, Lennart Borgman wrote:
>> On Fri, Feb 5, 2010 at 4:18 PM, Alan Mackenzie <acm@muc.de> wrote:
>
>> > On the Emacs manual page "Uniquify" ("Making Buffer Names Unique"),
>> > it says you can change the style of buffer names like foo.c<2> by
>> > customising the variable `uniquify-buffer-name-style'.
>
>> > This variable doesn't exist.  It didn't exist in Emacs 22 or Emacs
>> > 21 either.
>
>> > My feeling is that it is the code rather than the manual which is at
>> > fault.  :-)
>
>
>> Something is wrong... ;-)
>
>> On line 95 in uniquify.el there is something looking pretty much like
>> that variable...
>
> Yes, thanks.  I found that variable by grepping all the sources.  To get
> access to it, you've got to do M-: (require uniquify), which is surely
> something a "mere" user shouldn't have to do.  There also seems to be
> something about it in menu-bar.el, but I haven't quite figured out what.
>
> It just seems very, very strange.


Yes, I know. We have been discussing this problem here:

  http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00504.html

It seems like it is up to me to continue with this. As I have said
before I would appreciate some help.

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Alan Mackenzie]

Hi, Glenn,

On Fri, Feb 05, 2010 at 12:06:13PM -0500, Glenn Morris wrote:
> Alan Mackenzie wrote:

> > says you can change the style of buffer names like foo.c<2> by
> > customising the variable `uniquify-buffer-name-style'.

> See http://debbugs.gnu.org/2853

Thanks for that!

Is there somewhere on the page which shows the bug's status (i.e.
open/fixed/....)?

There is definitely an inconsistency between the code and the manual at
the moment.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Stefan Monnier]

> It just seems very, very strange.

Welcome to Emacs,


        Stefan

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Alan Mackenzie]

Hi, Lennart,

On Fri, Feb 05, 2010 at 07:18:28PM +0100, Lennart Borgman wrote:
> On Fri, Feb 5, 2010 at 7:17 PM, Alan Mackenzie <acm@muc.de> wrote:

> > On Fri, Feb 05, 2010 at 04:56:20PM +0100, Lennart Borgman wrote:
> >> On Fri, Feb 5, 2010 at 4:18 PM, Alan Mackenzie <acm@muc.de> wrote:

> >> > On the Emacs manual page "Uniquify" ("Making Buffer Names
> >> > Unique"), it says you can change the style of buffer names like
> >> > foo.c<2> by customising the variable
> >> > `uniquify-buffer-name-style'.

> >> > This variable doesn't exist.  It didn't exist in Emacs 22 or
> >> > Emacs 21 either.

> >> > My feeling is that it is the code rather than the manual which is
> >> > at fault.  :-)


> >> Something is wrong... ;-)

> >> On line 95 in uniquify.el there is something looking pretty much
> >> like that variable...

> > Yes, thanks.  I found that variable by grepping all the sources.
> > To get access to it, you've got to do M-: (require uniquify),
> > which is surely something a "mere" user shouldn't have to do.
> > There also seems to be something about it in menu-bar.el, but I
> > haven't quite figured out what.

> > It just seems very, very strange.


> Yes, I know. We have been discussing this problem here:

>   http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00504.html

> It seems like it is up to me to continue with this. As I have said
> before I would appreciate some help.

Seems to me that what's wanted is an autoload for variables, just like
we've got for functions/macros.  Or have we got this already?  Then when
anybody tries to access this variable in any way, uniquify.elc would get
loaded.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Lennart Borgman]

On Sat, Feb 6, 2010 at 7:17 PM, Alan Mackenzie <acm@muc.de> wrote:
>
> Seems to me that what's wanted is an autoload for variables, just like
> we've got for functions/macros.  Or have we got this already?  Then when
> anybody tries to access this variable in any way, uniquify.elc would get
> loaded.


Hi Alan,

We can autoload defcustoms, but there are so many so we probably do
not want that. There are about 7000 and autoloading them all will take
some computer resources.

Therefore Stefan instead had the idea that we can make them available
for completion, for example when you do "M-x customize-option". If
choosen they will then be loaded. I started to work a bit on that, but
it is not finished. (See the thread I pointed to.)

defgroup:s are already autoloaded (if they are part of Emacs distribution).

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Drew Adams]

> We can autoload defcustoms, but there are so many so we probably do
> not want that. There are about 7000 and autoloading them all will take
> some computer resources.

How many resources? Just what is involved?

The point of autoload is to load just a pointer to a target, rather than loading
the target itself. Why would 7000 additional autoloads be a big runtime or
load-time burden?

I'm not claiming it is not a big burden. I'm asking why it is. I don't see why
it would be so costly for Emacs to record 7000 vars and their target files for
loading.

I haven't seen any explanation or cost analysis so far. All I've seen is Stefan
screaming, essentially, "NO! DON'T!!!". I'm not saying he's wrong. But what's
wrong with seeing some analysis of the cost involved?

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Alan Mackenzie]

HI, Lennart,

On Sat, Feb 06, 2010 at 07:18:55PM +0100, Lennart Borgman wrote:
> On Sat, Feb 6, 2010 at 7:17 PM, Alan Mackenzie <acm@muc.de> wrote:

> > Seems to me that what's wanted is an autoload for variables, just like
> > we've got for functions/macros.  Or have we got this already?  Then when
> > anybody tries to access this variable in any way, uniquify.elc would get
> > loaded.

> We can autoload defcustoms, but there are so many so we probably do
> not want that.

Why?  The "eight megabytes and continually swapping" joke is several
decades out of date.

> There are about 7000 and autoloading them all will take some computer
> resources.

Enough to make a noticeable difference?

Will   (setq uniquify-buffer-name-style 'reverse)  in one's .emacs pick
up such an autoload?  custom-autoload is not in the Elisp manual and its
doc string is not terribly helpful.

> Therefore Stefan instead had the idea that we can make them available
> for completion, for example when you do "M-x customize-option". If
> choosen they will then be loaded. I started to work a bit on that, but
> it is not finished. (See the thread I pointed to.)

What does "make them available" mean?  Create a separate obarray for
them, perhaps?

> defgroups are already autoloaded (if they are part of Emacs distribution).

OK.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Stefan Monnier]

>> > Seems to me that what's wanted is an autoload for variables, just like
>> > we've got for functions/macros.  Or have we got this already?  Then when
>> > anybody tries to access this variable in any way, uniquify.elc would get
>> > loaded.
>> We can autoload defcustoms, but there are so many so we probably do
>> not want that.
> Why?  The "eight megabytes and continually swapping" joke is several
> decades out of date.

Actually, the problem is not just its size, it's that the
current ;;;###autoload behavior for variables is not quite as clean as
it is for functions: it doesn't auto-load the package when accessing the
var, but instead it preloads just the variable, thus changing the order
of execution between the variable that are "autoloaded" and those that
aren't, thus leading to all kinds of bugs and problems.

What Lennart has been working on is a real autoloading mechanism,
whereby the package will be loaded when the user asks to customize
this variable.

>> Therefore Stefan instead had the idea that we can make them available
>> for completion, for example when you do "M-x customize-option". If
>> choosen they will then be loaded. I started to work a bit on that, but
>> it is not finished. (See the thread I pointed to.)

> What does "make them available" mean?  Create a separate obarray for
> them, perhaps?

The technical means by which the autoloading will take place is not
finalized yet.  Lennart has something implemented using some technique,
but IIRC it was still using too much memory for my taste.


        Stefan

bug#5529: `uniquify-buffer-name-style' doesn't exist

[Glenn Morris]

I've mentioned in the manual that uniquify must be loaded explicitly.
This obviously isn't ideal but there is already a separate bug to
improve this specific issue; and the more general issue has also been
discussed elsewhere.