unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Kaushal Modi <kaushal.modi@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Relics of removed dir-locals-file-2 feature in pretest
Date: Mon, 27 Nov 2017 14:57:26 +0000	[thread overview]
Message-ID: <CAFyQvY2fx-HfsXbwcH9Xca1cTSsupm6eSwd5h-85nOdEB7EEbg@mail.gmail.com> (raw)
In-Reply-To: <831skobvvw.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

On Thu, Nov 23, 2017 at 3:09 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Which part of it is incorrect?
>

Let's say a user reads the NEWS and finds:

> * A second dir-local file (.dir-locals-2.el) is now accepted.
> See the variable 'dir-locals-file-2' for more information.

They do C-h v dir-locals-file-2 and read:

> This essentially a second file that can be used like `dir-locals-file', ..

That is incorrect! dir-locals-file-2 *cannot* be used like
`dir-locals-file'! That variable is just declared but not used anywhere
(why is it that only I think that that's a problem). A user can

Reading further in that docstring:

> See Info node `(elisp)Directory Local Variables' for details.

That node has no reference to dir-locals-file-2 variable or a mention of
the feature that .dir-locals-2.el can be used to override .dir-local.el.

Also in the doc-string of dir-locals-file:

> See also `dir-locals-file-2', whose values override this one's.

No, it *does not*! dir-locals-file-2 is not used in any code.

Thank you for volunteering, but I'm not yet sure we should do that.
>

Please consider making this change.

From your earlier email (I missed replying to this part):

> We could remove the defconst, but just removing it is not enough,
> because that would also remove its doc string.

Why is that bad? That variable is anyways not used.. so what's the point of
keeping docstring of an unused variable.

> So we will have to do
> something else in order to keep that special file name documented
> (e.g., so that "M-x apropos-documentation" would find it).  I'm not
> sure we should invest such an effort: after all, what's there does
> work,

Why not just mention that a user can just add "-2" to
(file-name-sans-extension dir-locals-file), and that file can be used to
override dir-locals-file. Mention that in the dir-locals-file docstring and
the (elisp)Directory Local Variables node.

> so why fix that which ain't broken?

The documentation is broken. It is incorrect, misleading.

And I am not just complaining, I am willing to provide a patch that removes
that defconst and updates the dir-local-file doc-string and the manual to
make this feature better discoverable. So why is that is problem? Why would
you want the 26.1 release to go out with this misdocumented feature? What
am I missing?
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 3501 bytes --]

  reply	other threads:[~2017-11-27 14:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12 13:58 Relics of removed dir-locals-file-2 feature in pretest Kaushal Modi
2017-11-21 19:56 ` Kaushal Modi
2017-11-21 20:33   ` Eli Zaretskii
2017-11-21 21:11     ` Kaushal Modi
2017-11-22 15:19       ` Eli Zaretskii
2017-11-22 15:58         ` Kaushal Modi
2017-11-22 16:20           ` Eli Zaretskii
2017-11-22 16:28             ` Kaushal Modi
2017-11-23 15:53               ` Eli Zaretskii
2017-11-23 17:34                 ` Kaushal Modi
2017-11-23 20:08                   ` Eli Zaretskii
2017-11-27 14:57                     ` Kaushal Modi [this message]
2017-11-27 16:14                       ` Eli Zaretskii
2017-11-27 17:04                         ` Kaushal Modi
2017-11-27 17:27                           ` Eli Zaretskii
2017-11-27 17:50                             ` Kaushal Modi
2017-11-28 17:19                               ` Eli Zaretskii
2017-11-28 17:34                                 ` Kaushal Modi
2017-11-28 17:51                                   ` Eli Zaretskii
2017-11-28 17:59                                     ` Kaushal Modi
2017-11-28 20:02                                     ` Davis Herring
2017-11-28 20:36                                       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFyQvY2fx-HfsXbwcH9Xca1cTSsupm6eSwd5h-85nOdEB7EEbg@mail.gmail.com \
    --to=kaushal.modi@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).