unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 28023@debbugs.gnu.org, michael.albinus@gmx.de
Subject: bug#28023: fix make-temp-file race on local host
Date: Sat, 12 Aug 2017 10:57:26 -0700	[thread overview]
Message-ID: <aa97a5b7-3b6b-ff94-ed90-ec9a9e9226b9@cs.ucla.edu> (raw)
In-Reply-To: <83mv74iv8h.fsf@gnu.org>

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

Eli Zaretskii wrote:
> I think the prefix that comes from the file where the function is
> defined is more of a Lisp convention, and the -internal convention is
> more for C implementations.

I see lots of exceptions to these conventions, presumably either because 
developers don't know the intent or because the code was written before the 
conventions were established. Still, it's better to document the intent so I 
installed the attached patch to do that. I'll adjust the make-temp-file patch 
accordingly.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Document-internal-use-naming-conventions.patch --]
[-- Type: text/x-patch; name="0001-Document-internal-use-naming-conventions.patch", Size: 2247 bytes --]

From 57c2de6fce73b77081e59d0527b12f158bac758a Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 12 Aug 2017 10:54:32 -0700
Subject: [PATCH] Document internal-use naming conventions

* doc/lispref/functions.texi (Function Names):
* doc/lispref/variables.texi (Tips for Defining):
Document naming conventions for internal-use functions and vars.
See Bug#28023#59.
---
 doc/lispref/functions.texi |  9 +++++++++
 doc/lispref/variables.texi | 10 ++++++++++
 2 files changed, 19 insertions(+)

diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi
index 283f74f..06de2e2 100644
--- a/doc/lispref/functions.texi
+++ b/doc/lispref/functions.texi
@@ -544,6 +544,15 @@ Function Names
 conflict.  (This is not the case in some dialects of Lisp, like
 Scheme.)
 
+  By convention, if a function's symbol consists of two names
+separated by @samp{--}, the function is intended for internal use and
+the first part names the file defining the function.  For example, a
+function named @code{vc-git--rev-parse} is an internal function
+defined in @file{vc-git.el}.  Internal-use functions written in C have
+names ending in @samp{-internal}, e.g., @code{bury-buffer-internal}.
+Emacs code contributed before 2018 may follow other internal-use
+naming conventions, which are being phased out.
+
 @node Defining Functions
 @section Defining Functions
 @cindex defining a function
diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi
index 2818ea0..7650ed4 100644
--- a/doc/lispref/variables.texi
+++ b/doc/lispref/variables.texi
@@ -574,6 +574,16 @@ Tips for Defining
 
 @item @dots{}-switches
 The value specifies options for a command.
+
+@item @var{prefix}--@dots{}
+The variable is intended for internal use and is defined in the file
+@file{@var{prefix}.el}.  (Emacs code contributed before 2018 may
+follow other conventions, which are being phased out.)
+
+@item @dots{}-internal
+The variable is intended for internal use and is defined in C code.
+(Emacs code contributed before 2018 may follow other conventions,
+which are being phased out.)
 @end table
 
   When you define a variable, always consider whether you should mark
-- 
2.7.4


  reply	other threads:[~2017-08-12 17:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-09  5:38 bug#28023: fix make-temp-file race on local host Paul Eggert
2017-08-09  6:51 ` Michael Albinus
2017-08-09  9:22   ` Paul Eggert
2017-08-09 11:21     ` Michael Albinus
2017-08-13  7:21       ` Paul Eggert
2017-08-12 10:35     ` Michael Albinus
2017-08-12 15:55       ` Paul Eggert
2017-08-12 16:09         ` Eli Zaretskii
2017-08-12 16:25           ` Paul Eggert
2017-08-12 16:52             ` Eli Zaretskii
2017-08-12 17:57               ` Paul Eggert [this message]
2017-08-12 18:07                 ` Eli Zaretskii
2017-08-12 17:51         ` Michael Albinus
2017-08-09 16:05 ` Eli Zaretskii
2017-08-09 18:47   ` Paul Eggert
2017-08-09 19:09     ` Eli Zaretskii
2017-08-09 23:36       ` Paul Eggert
2017-08-10 15:35         ` Eli Zaretskii
2017-08-10 22:24           ` Paul Eggert
2017-08-11  6:21             ` Eli Zaretskii
2017-08-11  7:44               ` Paul Eggert
2017-08-11  8:03                 ` Eli Zaretskii
2017-08-12  8:31                   ` 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=aa97a5b7-3b6b-ff94-ed90-ec9a9e9226b9@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=28023@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=michael.albinus@gmx.de \
    /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).