.dir-locals.el

.dir-locals.el

[Eli Zaretskii]

This part of .dir-locals.el from today's CVS does not seem to work:

 ("lisp/mail/pmail*"
  . ((nil . ((change-log-default-name . "ChangeLog.pmail"))))))

(To see that, you will need to remove the file-local variables from
pmail*.el files, because they specify ChangeLog.pmail there as well.)

I took a look at relevant functions in files.el, and it looks like
this wasn't supposed to work with file wildcards.  This fragment from
dir-locals-collect-variables:

	  (when (and sub-file-name
		     (>= (length sub-file-name) (length key))
		     (string= key (substring sub-file-name 0 (length key))))
	    (setq variables (dir-locals-collect-variables
			     (cdr entry) root variables))))

assumes that "lisp/mail/pmail*" is a substring of "lisp/mail/pmail.el",
which of course is false because of the `*'.  The documentation of the
feature in the manual also seems to say that the intent is to specify
here a name of a _directory_ and have that apply to all the files
under that directory.

I tried to see if this works if I change "lisp/mail/pmail*" to just
"lisp/mail", and that still didn't work for an arbitrary Lisp file in
lisp/mail: typing "C-x 4 a" after visiting the file still pops up
ChangeLog, not ChangeLog.pmail.  So maybe I'm missing something here,
and the above report is bogus; apologies if that is the case.

Re: .dir-locals.el

[Eli Zaretskii]

> Date: Fri, 26 Dec 2008 17:18:56 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> This part of .dir-locals.el from today's CVS does not seem to work:
> 
>  ("lisp/mail/pmail*"
>   . ((nil . ((change-log-default-name . "ChangeLog.pmail"))))))

Also, this part:

         (fill-column . 80)))

changes the way we format ChangeLog files in Emacs.  If we indeed want
to use 80 as the fill-column, we should reformat ChangeLog files in
all directories to be consistent with this setting.

Re: .dir-locals.el

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> changes the way we format ChangeLog files in Emacs.  If we indeed want
> to use 80 as the fill-column, we should reformat ChangeLog files in
> all directories to be consistent with this setting.

Why?  There's nothing wrong with having new entries filled to a
different column than old entries.

-Miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: .dir-locals.el

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Dec 2008 11:39:21 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > changes the way we format ChangeLog files in Emacs.  If we indeed want
> > to use 80 as the fill-column, we should reformat ChangeLog files in
> > all directories to be consistent with this setting.
> 
> Why?

Because it looks ugly, IMO.  But if I'm the only one, so be it.

Re: .dir-locals.el

[Juanma Barranquero]

On Sat, Dec 27, 2008 at 10:33, Eli Zaretskii <eliz@gnu.org> wrote:

> Because it looks ugly, IMO.  But if I'm the only one, so be it.

They are not very consistent right now.

Anyway, we could switch to the new fill-column value after the
release, or when we move the current ChangeLog to ChangeLog.nnn and
start anew.

    Juanma

Re: .dir-locals.el

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > This part of .dir-locals.el from today's CVS does not seem to work:
  > 
  >  ("lisp/mail/pmail*"
  >   . ((nil . ((change-log-default-name . "ChangeLog.pmail"))))))

Thanks, I removed that part.

  > Also, this part:
  > 
  >          (fill-column . 80)))
  > 
  > changes the way we format ChangeLog files in Emacs.

There was a typo there, the default value is 70, and there was no
intention change any defaults, just to reenforce them in case a user has
changed them.  The default for change-log-mode seems to be 74, so I
added a rule for it. 

Re: .dir-locals.el

[Eli Zaretskii]

> Date: Sat, 27 Dec 2008 09:13:49 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   > This part of .dir-locals.el from today's CVS does not seem to work:
>   > 
>   >  ("lisp/mail/pmail*"
>   >   . ((nil . ((change-log-default-name . "ChangeLog.pmail"))))))
> 
> Thanks, I removed that part.
> 
>   > Also, this part:
>   > 
>   >          (fill-column . 80)))
>   > 
>   > changes the way we format ChangeLog files in Emacs.
> 
> There was a typo there, the default value is 70, and there was no
> intention change any defaults, just to reenforce them in case a user has
> changed them.  The default for change-log-mode seems to be 74, so I
> added a rule for it. 

Thanks.

Re: .dir-locals.el

[Eric Schulte]

Is there a good way to apply the variables set in .dir-locals.el when
changing into and out of a directory in eshell (or I suppose in other
Emacs shells as well)?

I've tried setting eshell as a mode in the .dir-locals.el file but with
no success.  I've also tried to define after-advice on the `cd' function
in eshell, but there doesn't appear to be any means for applying local
variables to a buffer which doesn't have a file-name.

(defadvice cd (after dir-locals-on-cd activate)
  "Apply the variables defined in .dir-locals.el when changing
into and outof a directory in eshell."
  (hack-dir-local-variables))

Fails because `hack-dir-local-variables' checks that the buffer is
visiting a file before applying the variables.

Is there a supported way to do this?

If not should I write a new function for this?

If so should it be included in the dir-locals.el functionality?

If not is there a reason to only allow setting local variables for
buffers visiting files?

Thanks -- Eric

Re: .dir-locals.el

[Kevin Rodgers]

Eric Schulte wrote:
> Is there a good way to apply the variables set in .dir-locals.el when
> changing into and out of a directory in eshell (or I suppose in other
> Emacs shells as well)?
> 
> I've tried setting eshell as a mode in the .dir-locals.el file but with
> no success.  I've also tried to define after-advice on the `cd' function
> in eshell, but there doesn't appear to be any means for applying local
> variables to a buffer which doesn't have a file-name.
> 
> (defadvice cd (after dir-locals-on-cd activate)
>   "Apply the variables defined in .dir-locals.el when changing
> into and outof a directory in eshell."
>   (hack-dir-local-variables))
> 
> Fails because `hack-dir-local-variables' checks that the buffer is
> visiting a file before applying the variables.
> 
> Is there a supported way to do this?
> 
> If not should I write a new function for this?
> 
> If so should it be included in the dir-locals.el functionality?
> 
> If not is there a reason to only allow setting local variables for
> buffers visiting files?

I don't know.  But you should be able to get your advice to work by
let-binding buffer-file-name to default-directory around the call to
hack-dir-local-variables.

Or perhaps to (expand-file-name "foo").

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: .dir-locals.el

[Eric Schulte]

Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:

> Eric Schulte wrote:
>> Is there a good way to apply the variables set in .dir-locals.el when
>> changing into and out of a directory in eshell (or I suppose in other
>> Emacs shells as well)?
>>
>> I've tried setting eshell as a mode in the .dir-locals.el file but with
>> no success.  I've also tried to define after-advice on the `cd' function
>> in eshell, but there doesn't appear to be any means for applying local
>> variables to a buffer which doesn't have a file-name.
>>
>> (defadvice cd (after dir-locals-on-cd activate)
>>   "Apply the variables defined in .dir-locals.el when changing
>> into and outof a directory in eshell."
>>   (hack-dir-local-variables))
[...]
> I don't know.  But you should be able to get your advice to work by
> let-binding buffer-file-name to default-directory around the call to
> hack-dir-local-variables.
>
> Or perhaps to (expand-file-name "foo").

Thanks for the suggestion, by replacing (buffer-file-name) in
hack-dir-local-variables with default-directory I was able to save the
values specified in .dir-locals.el to the `file-local-variables-alist'.
Unfortunately it looks as though the values of the
`file-local-variables-alist' are only applied when the current buffer is
visiting a file.  Namely the resulting occurs in eshell

  ~ $ (message (format "%S" foo-foo-foo))
  nil
  ~ $ (message (format "%S" file-local-variables-alist))
  nil
  ~ $ cd src/mep/
  ~/src/mep $ cat .dir-locals.el 
  ((nil . ((foo-foo-foo . "eschulte"))))
  ~/src/mep $ (message (format "%S" file-local-variables-alist))
  ((foo-foo-foo . "eschulte"))
  ~/src/mep $ (message (format "%S" foo-foo-foo))
  nil
  ~/src/mep $ 

Either I'm missing something (more than likely) or given the current
implementation it does not make sense to try to use .dir-locals.el for
setting variables inside of an eshell buffer.

Best -- Eric

Re: .dir-locals.el

[Stefan Monnier]

> (defadvice cd (after dir-locals-on-cd activate)
>   "Apply the variables defined in .dir-locals.el when changing
> into and outof a directory in eshell."
>   (hack-dir-local-variables))

If you do

(defadvice cd (after dir-locals-on-cd activate)
  (let ((buffer-file-name default-directory))
    (hack-dir-local-variables)))

it might get you a bit further.  But note that it still won't do what
you want: it'll only give you file-local-variables-alist, which you then
have to apply to the buffer.

Furthermore, before applying it, you'll need to un-apply those settings
you had applied earlier and which were relevant to the directory in
which you were before `cd'.

So you'll want something like (100% guaranteed untested)

(defadvice cd (around dir-locals-on-cd activate)
  (while eshell-previous-values
    (let ((x (pop eshell-previous-values)))
      (if (consp x)
          (set (car x) (cdr x))
        (kill-local-variable x))))
  ad-do-it
  (let ((buffer-file-name default-directory))
    (hack-dir-local-variables))
  (dolist (x file-local-variables-alist)
    (let ((var (car x))
          (val (cdr x)))
      (push (if (buffer-local-p var)
                (cons var (symbol-value var))
              var)
           eshell-previous-values)
      (set (make-local-variable var) val))))

> Is there a supported way to do this?

Not.

> If not should I write a new function for this?

Your call.

> If so should it be included in the dir-locals.el functionality?

Not sure.

> If not is there a reason to only allow setting local variables for
> buffers visiting files?

It's not obviously clear that applying .dir-locals.el to eshell like you
suggest is a good idea.  It seems consistent with the idea that
"cd /ssh:foo:" ends up behaving like "ssh foo", tho.

Maybe your suggestion to change hack-dir-local-variables so it uses
default-directory rather than buffer-file-name is a good one.  It seems
like it would be a safe change and would allow the above advice to feel
a tiny bit less hackish.


        Stefan

Re: .dir-locals.el

[Juri Linkov]

> Maybe your suggestion to change hack-dir-local-variables so it uses
> default-directory rather than buffer-file-name is a good one.  It seems
> like it would be a safe change and would allow the above advice to feel
> a tiny bit less hackish.

This will also set the directory-wide file-variable values
in newly created buffers, for good or bad.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: .dir-locals.el

[Eric Schulte]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> If you do
>
> (defadvice cd (after dir-locals-on-cd activate)
>   (let ((buffer-file-name default-directory))
>     (hack-dir-local-variables)))
>

This generates errors for me which look like.

  Args out of range: "~/src/foo/", 23, 10

However when I actually replace (buffer-file-name) with
default-directory in the function it works fine.

>
> it might get you a bit further.  But note that it still won't do what
> you want: it'll only give you file-local-variables-alist, which you then
> have to apply to the buffer.
>
> Furthermore, before applying it, you'll need to un-apply those settings
> you had applied earlier and which were relevant to the directory in
> which you were before `cd'.
>
> So you'll want something like (100% guaranteed untested)
>
[...]
>

Thanks for this suggestion, using a slightly altered version [1] of what
you suggested I was able to get the behavior I expected.  It's certainly
not pretty, but it seems to work.  Note: most of the code below is just
a copy of hack-dir-local-variables with all calls to buffer-file-name
removed.

Thanks, I'll be using this moving forward -- Eric

[1]
,----
| (defadvice cd (around dir-locals-on-cd activate)
|   "Apply the variables defined in .dir-locals.el when changing
| into and outof a directory in eshell."
|   ;; clean up old variables
|   (while file-local-variables-alist
|     (let ((x (pop file-local-variables-alist)))
|       (kill-local-variable x)))
|   ;; cd
|   ad-do-it
|   ;; run hack-dir-local-variables w/o buffer-file-name
|   (let ((variables-file (dir-locals-find-file default-directory))
| 	(class nil)
| 	(dir-name nil))
|     (cond
|      ((stringp variables-file)
|       (setq dir-name (file-name-directory default-directory))
|       (setq class (dir-locals-read-from-file variables-file)))
|      ((consp variables-file)
|       (setq dir-name (car variables-file))
|       (setq class (cdr variables-file))))
|     (when class
|       (let ((variables
| 	     (dir-locals-collect-variables
| 	      (dir-locals-get-class-variables class) dir-name nil)))
| 	(when variables
| 	  (hack-local-variables-filter variables dir-name)))))
|   ;; apply file-local-variables to buffer
|   (while file-local-variables-alist
|     (let ((x (pop file-local-variables-alist)))
|       (if (consp x)
|           (set (car x) (cdr x))
|         (kill-local-variable x)))))
`----

Re: .dir-locals.el

[Stefan Monnier]

>> Maybe your suggestion to change hack-dir-local-variables so it uses
>> default-directory rather than buffer-file-name is a good one.  It seems
>> like it would be a safe change and would allow the above advice to feel
>> a tiny bit less hackish.

> This will also set the directory-wide file-variable values
> in newly created buffers, for good or bad.

Why?  This code is not expected to be run for new buffers.


        Stefan