make-variable-buffer-local change

make-variable-buffer-local change

[Dan Nicolaescu]

Hi,

Can you please explain the reason for this change:

2009-09-25  Juanma Barranquero  <lekktu@gmail.com>

        * bs.el (bs--get-file-name): Use `list-buffers-directory'
        when available, instead of hardcoding mode names.  Doc fix.

        * menu-bar.el (list-buffers-directory): Add docstring.
        Make automatically buffer-local.

        * dired.el (dired-mode):
        * files.el (cd-absolute):
        * pcvs.el (cvs-temp-buffer):
        * pcvs-util.el (cvs-get-buffer-create):
        * shell.el (shell-mode):
        * vc-dir.el (vc-dir-mode):
        Don't make `list-buffers-directory' buffer local.

The docstring for make-variable-buffer-local says:

In most cases it is better to use `make-local-variable',
which makes a variable local in just one buffer.

Re: make-variable-buffer-local change

[Juanma Barranquero]

On Fri, Sep 25, 2009 at 18:09, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Can you please explain the reason for this change:

Sure.

> In most cases it is better to use `make-local-variable',
> which makes a variable local in just one buffer.

That's true, in the case where a variable has local and non-local
uses. The warning that you quote is intended to keep people from
blindly making variables automatically buffer-local as soon as they
realize that the variable *could* sometimes be useful as buffer-local.
That's a good suggestion.

However, `list-buffers-directory' is *always* used as buffer-local.
All packages that assign it make it buffer-local first. There's no
reason ever (that I can think of) to assign it globally; it would in
fact break some packages, like ibuffer.el or mouse.el. Certainly every
buffer that uses it will want to have its own value. I'd go to far as
betting that any assignment of `list-buffers-directory' that's not
buffer-local is likely an error. So making it automatic is simpler and
safer.

At least, that's my take on it.

BTW, I did this patch while investigating #3224. uniquify has code to
deal with buffers that assign `list-buffers-directory', but it is
doing a bad job of it. I cannot think of a clean way to fix it that
does not involve changing more code than I would like, though. Ideas
welcome.

    Juanma

Re: make-variable-buffer-local change

[Lennart Borgman]

On Fri, Sep 25, 2009 at 6:32 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> However, `list-buffers-directory' is *always* used as buffer-local.

I am a bit surprised that such a discussion takes place about a
variable that even does not have a doc string... ;-)

Re: make-variable-buffer-local change

[Juanma Barranquero]

On Fri, Sep 25, 2009 at 18:50, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I am a bit surprised that such a discussion takes place about a
> variable that even does not have a doc string... ;-)

It does, now:

  list-buffers-directory is a variable defined in `menu-bar.el'.
  Its value is nil

    Automatically becomes buffer-local when set in any fashion.

  Documentation:
  String to display in buffer listings for buffers not visiting a file.
  Dired, shell and other modes use this variable.

and, though the docstring is brand new, the variable was already
documented in the Emacs Lisp Reference (node 27.4 "Buffer File Name").

    Juanma

Re: make-variable-buffer-local change

[Dan Nicolaescu]

Juanma Barranquero <lekktu@gmail.com> writes:

  > On Fri, Sep 25, 2009 at 18:09, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > Can you please explain the reason for this change:
  > 
  > Sure.
  > 
  > > In most cases it is better to use `make-local-variable',
  > > which makes a variable local in just one buffer.
  > 
  > That's true, in the case where a variable has local and non-local
  > uses. The warning that you quote is intended to keep people from
  > blindly making variables automatically buffer-local as soon as they
  > realize that the variable *could* sometimes be useful as buffer-local.
  > That's a good suggestion.
  > 
  > However, `list-buffers-directory' is *always* used as buffer-local.
  > All packages that assign it make it buffer-local first. There's no

"All packages that assign it"

  > reason ever (that I can think of) to assign it globally; it would in

It is globally assigned to nil. 

All buffers that don't set it explicitly use the global nil value.

Isn't it slightly more efficient to access global bindings than buffer
local bindings, so forcing `make-variable-buffer-local' will force this
inefficiency everywhere.

  > BTW, I did this patch while investigating #3224. uniquify has code to
  > deal with buffers that assign `list-buffers-directory', but it is
  > doing a bad job of it. I cannot think of a clean way to fix it that
  > does not involve changing more code than I would like, though. Ideas
  > welcome.

IMHO the first thing to do there is to decide if this is a problem with
uniquify, or if it's just working as expected.  (no idea here).

Re: make-variable-buffer-local change

[Juanma Barranquero]

On Fri, Sep 25, 2009 at 19:07, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> "All packages that assign it"

Of course. For packages that read it, they only want to find the right
(local) value, or nil when it has not been assigned.

> It is globally assigned to nil.

That's the default. Every buffer-local variable has a global default.
Surely you're not implying that is a reason for assigning it globally.

> All buffers that don't set it explicitly use the global nil value.

All buffers that don't set it explicitly don't use it. All packages
that don't set it but read it expect it to be locally set (or globally
nil).

> Isn't it slightly more efficient to access global bindings than buffer
> local bindings, so forcing `make-variable-buffer-local' will force this
> inefficiency everywhere.

Sorry, I think I'm not understanding your point. The packages that
read it will read either the global value, if they're doing some
processing on a buffer that does not have a local value, or the local
value if it exists. There's not such thing as a valid, global, non-nil
value of `list-buffers-directory' (I can imagine uses of local
bindings, though). As I've said, every package that assigns it does it
so locally. So I don't think any inefficiency has been introduced; it
was already buffer-local whenever it was needed. Unless I'm mistaken,
it is not more costly to read a global value for a buffer-local
variable than for an automatically buffer-local variable. The only way
that it could be slightly less efficient is if buffers get
`list-buffers-directory' locally set to nil; I don't think that
happens right now in any standard package, but if it happened, a call
to `kill-local-variable' would be in order.

> IMHO the first thing to do there is to decide if this is a problem with
> uniquify, or if it's just working as expected.  (no idea here).

If you create a buffer *vc-dir* with working dir /emacs/lisp, and
another with working dir /emacs/src, one of the *vc-dir* buffers will
have a value for uniquify-managed and the other will not. That cannot
be right.

    Juanma

RE: make-variable-buffer-local change

[Drew Adams]

>   Documentation:
>   String to display in buffer listings for buffers not 
>   visiting a file.
>   Dired, shell and other modes use this variable.

Interesting that the doc string would say that Dired uses this. It does not,
AFAICT - it _sets_ this var, so that others, such as buff-menu can use it. The
same thing holds for shell, AFAICT.

"Use" here should mean uses the variable to display its value in a buffer
listing (as the first part of the doc string suggests).

I had to grep the code to see if maybe Dired was now displaying non-file buffers
also, a la buff-menu. ;-)

IOW, the only modes the doc string mentions as examples of using this variable
do not in fact use it - they do not display buffer listings at all. Instead,
they merely set the value so that others can use it.

The places where this is used are the places where buffers are listed:
buff-menu, the menu-bar Buffers menu, and the `C-mouse-1' buffers menu.

Please correct the doc string accordingly.

Re: make-variable-buffer-local change

[Juanma Barranquero]

On Fri, Sep 25, 2009 at 19:35, Drew Adams <drew.adams@oracle.com> wrote:

> Interesting that the doc string would say that Dired uses this. It does not,
> AFAICT - it _sets_ this var, so that others, such as buff-menu can use it. The
> same thing holds for shell, AFAICT.
>
> "Use" here should mean uses the variable to display its value in a buffer
> listing (as the first part of the doc string suggests).
>
> IOW, the only modes the doc string mentions as examples of using this variable
> do not in fact use it - they do not display buffer listings at all. Instead,
> they merely set the value so that others can use it.

I'd say "use" covers both kinds of use, but I'll defer to natives.

> Please correct the doc string accordingly.

Don't hesitate to send a patch and I'll commit it ASAP.

    Juanma

RE: make-variable-buffer-local change

[Drew Adams]

> > Interesting that the doc string would say that Dired uses 
> > this. It does not, AFAICT - it _sets_ this var, so that
> > others, such as buff-menu can use it. The
> > same thing holds for shell, AFAICT.
> >
> > "Use" here should mean uses the variable to display its 
> > value in a buffer listing (as the first part of the doc
> > string suggests).
> >
> > IOW, the only modes the doc string mentions as examples of 
> > using this variable do not in fact use it - they do not
> > display buffer listings at all. Instead, they merely set the
> > value so that others can use it.
> 
> I'd say "use" covers both kinds of use, but I'll defer to natives.

It's not a question of native speakers. "Use" here refers to what the string is
_for_; what it is used for. It is used in a buffer listing, as a substitute for
a file name.

"Use" is use for users (including users of Lisp). Users generally don't know or
care which code sets the variable. What's interesting to them is what it is for,
how it is used, what its effect is.

> > Please correct the doc string accordingly.
> 
> Don't hesitate to send a patch and I'll commit it ASAP.

Just get rid of "Dired, shell and other modes use this variable."

We typically do not say where a function variable might be used (a fortiori,
might be set/bound), anyway.

Re: make-variable-buffer-local change

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 25 Sep 2009 11:06:15 -0700
> Cc: 'Dan Nicolaescu' <dann@ics.uci.edu>,
> 	'Lennart Borgman' <lennart.borgman@gmail.com>, emacs-devel@gnu.org
> 
> > I'd say "use" covers both kinds of use, but I'll defer to natives.
> 
> It's not a question of native speakers. "Use" here refers to what the string is
> _for_; what it is used for.

Would replacing "use" with "set" solve this problem?

> > > Please correct the doc string accordingly.
> > 
> > Don't hesitate to send a patch and I'll commit it ASAP.
> 
> Just get rid of "Dired, shell and other modes use this variable."

Sorry, I happen to disagree.  This is important information for such
an obscure feature.  The alternative is let the user grep the whole
lot of Lisp sources.

> We typically do not say where a function variable might be used (a fortiori,
> might be set/bound), anyway.

Never too late to start.

Re: make-variable-buffer-local change

[Dan Nicolaescu]

Juanma Barranquero <lekktu@gmail.com> writes:

  > On Fri, Sep 25, 2009 at 19:07, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > "All packages that assign it"
  > 
  > Of course. For packages that read it, they only want to find the right
  > (local) value, or nil when it has not been assigned.
  > 
  > > It is globally assigned to nil.
  > 
  > That's the default. Every buffer-local variable has a global default.
  > Surely you're not implying that is a reason for assigning it globally.
  > 
  > > All buffers that don't set it explicitly use the global nil value.
  > 
  > All buffers that don't set it explicitly don't use it. All packages
  > that don't set it but read it expect it to be locally set (or globally
  > nil).
  > 
  > > Isn't it slightly more efficient to access global bindings than buffer
  > > local bindings, so forcing `make-variable-buffer-local' will force this
  > > inefficiency everywhere.
  > 
  > Sorry, I think I'm not understanding your point. The packages that

My point is that it is cheaper to make this variable buffer local
exactly in the buffers that need to have it buffer local, rather than
making it buffer local in all buffers. 

What this discussion points out is that it would be good to have a
clarification of the use of make-variable-buffer-local vs
make-local-variable in the docstring of one (or both) of them.  Stefan?

  > > IMHO the first thing to do there is to decide if this is a problem with
  > > uniquify, or if it's just working as expected.  (no idea here).
  > 
  > If you create a buffer *vc-dir* with working dir /emacs/lisp, and
  > another with working dir /emacs/src, one of the *vc-dir* buffers will
  > have a value for uniquify-managed and the other will not. That cannot
  > be right.

That's just a restatement of the facts, I am looking for an analysis of
the cause of issue.  Like, is this a bug in uniquify?  Or is uniquify
working as expected, but it needs extra hand holding to do the right
thing?  Something else?...

Re: make-variable-buffer-local change

[Stefan Monnier]

> Isn't it slightly more efficient to access global bindings than buffer
> local bindings,

No.


        Stefan

Re: make-variable-buffer-local change

[Stefan Monnier]

> The docstring for make-variable-buffer-local says:

> In most cases it is better to use `make-local-variable',
> which makes a variable local in just one buffer.

But for a variable whose global value should never be changed, 
make-variable-buffer-local is preferable.


        Stefan

RE: make-variable-buffer-local change

[Drew Adams]

> > > I'd say "use" covers both kinds of use, but I'll defer to natives.
> > 
> > It's not a question of native speakers. "Use" here refers 
> > to what the string is _for_; what it is used for.
> 
> Would replacing "use" with "set" solve this problem?

You missed the point. We don't want to talk about places where the value is set.
What's important is what the variable is for.

We can give an example of where it is used, if we like, but not where it is set
(pretty much irrelevant). It so happens that the place of consumption
(buffer-listing code) can be far from the place it is set (e.g. Dired).

What is important is to let users know that they can set it for use by
buffer-listing code.

> > > > Please correct the doc string accordingly.
> > > 
> > > Don't hesitate to send a patch and I'll commit it ASAP.
> > 
> > Just get rid of "Dired, shell and other modes use this variable."
> 
> Sorry, I happen to disagree.  This is important information for such
> an obscure feature.  The alternative is let the user grep the whole
> lot of Lisp sources.

You missed the point.

What's most important about this variable is what it is for, not where in the
existing code it happens to be set. _Why_ it is set is important. Which is to
say _what it does_ is important - what you can use it for.

What this variable does is provide text to use for non-file buffers, when
buffers are listed along with their associated file names. It is the consumer of
this feature, buffer-listing code, that needs the feature.

It is for that use that code (anywhere) sets the variable. It's not for Dired or
shell that Dired and shell set this variable - it's for buffer-listing purposes
by Buffer Menu and the `Buffers' menus.

As I mentioned to Juanma off list, we could add something about the use of the
variable, if that helps to clarify things. But what we add shouldn't be about
which code happens to set the variable, but rather which code lists buffers and
thus makes use of the variable.

I suggested adding something like this, if people think something additional is
needed:

"For example, in the Buffer Menu (`C-x C-b'), if the local value for a given
non-file buffer is non-nil, then it is shown in the `File' column for that
buffer."

(Perhaps "it" should be replaced with "that value", to be clearer.)

That describes (gives an example of) what this variable does and how to use it:
set its local value for code that lists buffers and their "files"
(descriptions).

Re: make-variable-buffer-local change

[Juanma Barranquero]

On Fri, Sep 25, 2009 at 21:46, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> My point is that it is cheaper to make this variable buffer local
> exactly in the buffers that need to have it buffer local, rather than
> making it buffer local in all buffers.

"automatically buffer-local" does not mean "buffer local in all
buffers"; only on those that set it. There's no change with respect to
the previous situation. Before, packages manually set it to
buffer-local and then assigned it, now it is automatic.

> That's just a restatement of the facts, I am looking for an analysis of
> the cause of issue.

Trace `uniquify-rationalize-file-buffer-names' and
`uniquify-buffer-file-name' and you'll see it happen. Then you can
judge by yourself whether you think it's a bug or not. I think it is.

    Juanma

Re: make-variable-buffer-local change

[Dan Nicolaescu]

Juanma Barranquero <lekktu@gmail.com> writes:

  > On Fri, Sep 25, 2009 at 21:46, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > That's just a restatement of the facts, I am looking for an analysis of
  > > the cause of issue.
  > 
  > Trace `uniquify-rationalize-file-buffer-names' and
  > `uniquify-buffer-file-name' and you'll see it happen. Then you can
  > judge by yourself whether you think it's a bug or not. I think it is.

Can you please make a note of this in the bug, so that it does not get
lost?  (I don't use uniquify, so my interest in fixing it is close to
zero...)

Re: make-variable-buffer-local change

[Stefan Monnier]

>> > I'd say "use" covers both kinds of use, but I'll defer to natives.
>> It's not a question of native speakers. "Use" here refers to what the
>> string is _for_; what it is used for.

There are often different ways to look at it.  E.g. Let's say that
a mode displays two columns of text and set tab-width to half-the
window-width for that purpose; is it "using" tab-width?  I'd say yes.

Similarly, I tend to think that PCL-CVS "uses" list-buffers-directory in
order to improve the behavior of uniquify.

In general, variables are a means of communication, and each side of
the communication thinks of itself as "using" the variable and the other
side(s) as "providing" the variable.

>> Just get rid of "Dired, shell and other modes use this variable."
> Sorry, I happen to disagree.  This is important information for such
> an obscure feature.  The alternative is let the user grep the whole
> lot of Lisp sources.

If you don't want to get rid of it, then I think it's worthwhile to
improve it and mention that it is used also (on the other side) by
list-buffers and by uniquify.


        Stefan

Re: make-variable-buffer-local change

[Stefan Monnier]

>> Isn't it slightly more efficient to access global bindings than buffer
>> local bindings,
> No.

Sorry, I think I misread.  The answer is "yes".
But the efficiency is the same for a variable after
make-variable-buffer-local as after make-local-variable.


        Stefan

Re: make-variable-buffer-local change

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> My point is that it is cheaper to make this variable buffer local
Dan> exactly in the buffers that need to have it buffer local, rather than
Dan> making it buffer local in all buffers. 

In both cases, a Lisp_Buffer_Local_Value is allocated and stored in the
symbol's value slot.  The only difference is the setting of the
`local_if_set' flag on this object.

Tom

Re: make-variable-buffer-local change

[Juanma Barranquero]

On Fri, Sep 25, 2009 at 22:51, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Can you please make a note of this in the bug, so that it does not get
> lost?  (I don't use uniquify, so my interest in fixing it is close to
> zero...)

I use it, and I'm interested in fixing it (or it being fixed anway).
So I'll continue investigating it and will add any info to the bug
thread.

    Juanma

Re: make-variable-buffer-local change

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >> Isn't it slightly more efficient to access global bindings than buffer
  > >> local bindings,
  > > No.
  > 
  > Sorry, I think I misread.  The answer is "yes".
  > But the efficiency is the same for a variable after
  > make-variable-buffer-local as after make-local-variable.

So if you have:

(defvar foo nil)
(make-variable-buffer-local 'foo)

The do: (if (buffer-local-value 'foo) BLAH)

vs

(defvar foo nil)

and then in very few buffers, majority do not change the value of foo:

(set (make-local-variable 'foo) 'bar)

and do the same computation:

(if (buffer-local-value 'foo) BLAH)


is one of these 2 versions more efficient than the other?

Re: make-variable-buffer-local change

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> (make-variable-buffer-local 'foo)
[...]
Dan> (set (make-local-variable 'foo) 'bar)

Dan> is one of these 2 versions more efficient than the other?

Nope.

If buffer-locals are too slow, maybe they could be sped up.
The implementation uses a per-alist to store buffer-locals.
Maybe a hash table would be better?

Tom

RE: make-variable-buffer-local change

[Drew Adams]

> >> > I'd say "use" covers both kinds of use, but I'll defer 
> >> > to natives.
> >>
> >> It's not a question of native speakers. "Use" here refers 
> >> to what the string is _for_; what it is used for.
> 
> There are often different ways to look at it.  E.g. Let's say that
> a mode displays two columns of text and set tab-width to half-the
> window-width for that purpose; is it "using" tab-width?  I'd say yes.
> 
> Similarly, I tend to think that PCL-CVS "uses" 
> list-buffers-directory in
> order to improve the behavior of uniquify.
> 
> In general, variables are a means of communication, and each side of
> the communication thinks of itself as "using" the variable 
> and the other side(s) as "providing" the variable.

You _cannot_ know what the variable is for, just by looking at Dired's setting
of it. 

...without, that is, also reading the comment in Dired that says that it sets it
for the benefit of `list-buffers':

;; list-buffers uses this to display the dir being edited in this buffer.

The fact that there is such a comment is proof that the setting code does not,
by itself, indicate in any way what the variable does - what its effect/purpose
is.

Why doesn't the setting code help our understanding? Because the variable is set
for its consumer - the code that examines (uses) its value. As the comment says,
Dired sets it for `list-buffers'. The variable has use only for `list-buffers'
(and for similar buffer-listing code). Without that use, setting it has no
effect and no purpose.

You _can_ tell what the variable is for by looking at the consumer code. Why?
Because you can see how it, uh, uses it, concretely.

The point is not that consumers depend logically on producers as much as
producers depend on consumers, and that variables serve for communication
(coupling). That's certainly true, but it doesn't help us describe the
variable's purpose or use.

The point is what the variable is for. The purpose of the doc string is to tell
you what the variable is for, and perhaps a bit about how to use it.

This variable's purpose is to affect buffer listings. No foray into the code
that sets the value will help you understand that - unless there happens to be a
comment there to that effect.

It does help to explain that this is a buffer-local variable. That in itself
makes it clear that you want to set (and test) the value in the buffer that is
to be listed. That is useful info about the producer/consumer relation.

So yes, it doesn't hurt to give, in the doc string, the example of setting this
locally in a Dired buffer, in order to affect the `File' entry display for that
buffer in a buffer listing.

But Dired is actually not such a great example, since a directory is also
(typically) a file, or is file-like. Using the directory name as the buffer's
`File' description is not particularly noteworthy.

A better example would be Info, but Info doesn't actually use this variable -
instead, we hard-code the treatment of Info buffers in the `list-buffers' code.
That code should really be in info.el instead, and it should be used just to set
`list-buffers-directory'. IOW, Info should be treated the same way as Dired.

BTW, this variable's name is obviously not wonderful. Its value is text that
appears in place of a file name in a buffer listing. That has nothing per se to
do with directories - we don't list the directory of an Info node's file. It
should have been called something like `list-buffers-file-field-text' or
`list-buffers-pseudo-file-text'. Too late, perhaps.

Re: make-variable-buffer-local change

[Stefan Monnier]

>>>>> "Drew" == Drew Adams <drew.adams@oracle.com> writes:
[long rant]

I understand you.  But currently, nobody really knows what
list-buffers-directory is for.  Originally, it was just for
communication between dired/shell and list-buffers so its semantics was
pretty simple and didn't matter much (any string was fair game).
Then uniquify appeared and abused it for some slightly different purpose
(i.e. get a buffer-file-name for dired buffers, who normally set
buffer-file-name to nil to avoid timestamp checks and things like that),
where the semantics was more delicate: the string has to be a filename
and should be (to some extent) unique.  So uniquify only uses
list-buffers-directory for some major modes, but not all (see
uniquify-list-buffers-directory-modes).

I.e. "what list-buffers-directory is for" is currently ill-defined.
Rather than try and describe really what it does, it would be better to
re-shape it a bit.  Maybe 2 variables are in order, or maybe the
shell-mode case (which shouldn't influence uniquify) should use
a different value than just a string, so uniquify can tell whether to
use the value or not without having to check the major-mode.

Also its name should be changed because it's not just for "list-buffers"
any more.  Maybe buffer-file-name-replacement or
pseudo-buffer-file-name, or buffer-quasi-file-name, or ...


        Stefan

Re: make-variable-buffer-local change

[Juanma Barranquero]

On Sat, Sep 26, 2009 at 03:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I understand you.  But currently, nobody really knows what
> list-buffers-directory is for.

The elisp ref says:

 -- Variable: list-buffers-directory
     This buffer-local variable specifies a string to display in a
     buffer listing where the visited file name would go, for buffers
     that don't have a visited file name.  Dired buffers use this
     variable.

and that's how list-buffers, ibuffer and now bs use it. It makes sense.

> Then uniquify appeared and abused it for some slightly different purpose
[...]
> Maybe 2 variables are in order, or maybe the
> shell-mode case (which shouldn't influence uniquify) should use
> a different value than just a string, so uniquify can tell whether to
> use the value or not without having to check the major-mode.

I think uniquify should use another variable.

> Also its name should be changed because it's not just for "list-buffers"
> any more.  Maybe buffer-file-name-replacement or
> pseudo-buffer-file-name, or buffer-quasi-file-name, or ...

The way it is used (other than in uniquify), it's more of a directory
than a filename, I think. buffer-working-directory, something like
that, perhaps.

    Juanma

Re: make-variable-buffer-local change

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Drew Adams <drew.adams@oracle.com>, lekktu@gmail.com, dann@ics.uci.edu,
>         lennart.borgman@gmail.com, emacs-devel@gnu.org
> Date: Fri, 25 Sep 2009 17:04:59 -0400
> 
> >> Just get rid of "Dired, shell and other modes use this variable."
> > Sorry, I happen to disagree.  This is important information for such
> > an obscure feature.  The alternative is let the user grep the whole
> > lot of Lisp sources.
> 
> If you don't want to get rid of it, then I think it's worthwhile to
> improve it and mention that it is used also (on the other side) by
> list-buffers and by uniquify.

I agree.

Re: make-variable-buffer-local change

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <lekktu@gmail.com>, <dann@ics.uci.edu>, <lennart.borgman@gmail.com>,
>         <emacs-devel@gnu.org>
> Date: Fri, 25 Sep 2009 13:10:51 -0700
> 
> > > > I'd say "use" covers both kinds of use, but I'll defer to natives.
> > > 
> > > It's not a question of native speakers. "Use" here refers 
> > > to what the string is _for_; what it is used for.
> > 
> > Would replacing "use" with "set" solve this problem?
> 
> You missed the point. We don't want to talk about places where the value is set.
> What's important is what the variable is for.

The doc string already includes that information:

  String to display in buffer listings for buffers not visiting a file.

If you think this is insufficient or can suggest a better wording,
please do.  But you began this sub-thread by complaining against the
next sentence, which, at least for me, caused confusion as to what you
were complaining about.

> What is important is to let users know that they can set it for use by
> buffer-listing code.

I agree, and I think the above portion of the doc string does
precisely that.