all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 34911@debbugs.gnu.org
Subject: bug#34911: 26.1; doc about lock file names
Date: Tue, 19 Mar 2019 07:54:48 -0700 (PDT)	[thread overview]
Message-ID: <a916e9f9-e66e-40b8-b02d-1d697108774e@default> (raw)
In-Reply-To: <<83bm27uzbr.fsf@gnu.org>>

> > I don't see documented anywhere what a lock file name looks like.
> > I looked through both the Emacs manual and the Elisp manual.  Did I miss
> > it somehow, or is it defined/described nowhere?
> 
> It is described in the node "File Locks" in the ELisp manual.

I started there.  I see nothing in that node that says
what the name looks like.  I'm using Emacs 26.  Did
someone perhaps add a description of it since that
release?

> > Please let users know what how lock files are named.  Thx.  If this is
> > already done somewhere, please refer to that location from node (elisp)
> > `File Locks'.
> 
> The node "Interlocking" in the user manual, where file locking is
> described on the user level, has a cross-reference to the above node
> pf ELisp manual.  So I'm unsure how you missed that.

Please explain how that replies to the text you quote,
or to any of the text in the bug report?  AFAICT, there
is nothing in the Emacs manual (including of course the
node you cite) or in the Elisp manual (including the node
you cite) that tells you how lock files are named.

That's what this bug report is about (and its near-duplicate,
#25469, also touches on this lack).  

> > Please also update the doc of `dired-omit-files' to make clear that its
> > default value only approximately matches auto-save files (and lock
> > files?), and that even this is true only for the default naming regime
> > for auto-save files.
> 
> I don't understand this part.  Concretely, what is missing in the doc
> string, and why do you think it is necessary to add whatever is
> missing?

The default value is "^\\.?#\\|^\\.$\\|^\\.\\.$".

\\.?# matches only the first char of an auto-save file
name, and the first two chars of a lock file name.  It
does not match the full name, requiring it to end with
`#'.  That means that (1) it cannot be used as is for,
say, font-locking such a (complete) name, and (2) as
it is now, it can falsely identify files that are not
auto-save or lock files.

And it does not necessarily match auto-save file names
at all, as they can be nearly anything, it seems:

(elisp) `Auto-Saving' makes a point of saying that each
of  `auto-save-file-name-p' and `make-auto-save-file-name'
exists "so that you can customize it if you wish to change
the naming convention for auto-save files".  And for each
it reminds us "If you redefine it, be sure to redefine the
[other] function ... correspondingly."

IOW, apparently the `#...#' is conventional but users are
practically invited to adopt alternative naming schemes.

While those two functions go together, so that changing
the naming scheme for one calls for changing it also for
the other, there are other functions and variables that
presume the standard naming convention.  Their doc does
not, so far, speak to the possibility of a naming change.

Also, please add a doc string for `dired-omit-regexp',
referring to `dired-omit-files' (where this missing doc
will hopefully be added) and `dired-omit-extensions', as
is done for `dired-mark-omitted', for example.

Does this clarify what I meant by "the default value only
approximately matches auto-save files (and lock files?)"?





       reply	other threads:[~2019-03-19 14:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<db8aca56-6185-4e1a-a627-53aed26103c2@default>
     [not found] ` <<83bm27uzbr.fsf@gnu.org>
2019-03-19 14:54   ` Drew Adams [this message]
2019-03-19 18:23     ` bug#34911: 26.1; doc about lock file names Eli Zaretskii
2019-05-12 16:34     ` Noam Postavsky
2019-05-19 14:43       ` Noam Postavsky
2019-05-19 15:04         ` Drew Adams
2019-05-19 15:11           ` Noam Postavsky
2019-05-19 16:29             ` Drew Adams
2019-05-19 17:22               ` Noam Postavsky
2019-05-19 19:49                 ` Drew Adams
2020-08-26 10:39       ` Lars Ingebrigtsen
2020-08-26 16:55         ` Drew Adams
     [not found] <<<db8aca56-6185-4e1a-a627-53aed26103c2@default>
     [not found] ` <<<83bm27uzbr.fsf@gnu.org>
     [not found]   ` <<a916e9f9-e66e-40b8-b02d-1d697108774e@default>
     [not found]     ` <<83r2b2u3j4.fsf@gnu.org>
2019-03-19 20:15       ` Drew Adams
2019-03-19 20:23         ` Eli Zaretskii
2019-03-18 22:47 Drew Adams
2019-03-18 23:17 ` Glenn Morris
2019-03-19  0:28   ` Drew Adams
2019-03-19  7:07   ` Eli Zaretskii
2019-03-19  6:56 ` Eli Zaretskii
2019-03-19 11:49   ` 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

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

  git send-email \
    --in-reply-to=a916e9f9-e66e-40b8-b02d-1d697108774e@default \
    --to=drew.adams@oracle.com \
    --cc=34911@debbugs.gnu.org \
    --cc=eliz@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.