all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org,
	"Michael Heerdegen" <michael_heerdegen@web.de>,
	"Mattias Engdegård" <mattiase@acm.org>,
	"Richard Stallman" <rms@gnu.org>
Subject: bug#40671: [DOC] modify literal objects
Date: Sun, 10 May 2020 10:29:21 -0700	[thread overview]
Message-ID: <41d69e2e-561f-743a-e1f0-282b2e22b66c@cs.ucla.edu> (raw)
In-Reply-To: <88af48c6-bc39-6ab0-59ec-7d537f2d375d@yandex.ru>

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

On 5/9/20 8:13 PM, Dmitry Gutov wrote:

> You start talking about objects that "should [not] change". And give an example
> of an object that _cannot_ change.

That's easily altered to also give an example of an object that should not
change; see attached patch.

> I could understand it if it was describing an existing type system of the
> language, or implementation internals, but this is a purely imaginary type
> system.

objects.texi already talks about the Emacs Lisp type system and specifically
mentions strings, conses, etc. as types. Even if one considers the Emacs Lisp
type system to be "imaginary", it's reasonable to use the documentation's
already-existing terminology here.

> the list object didn't change, just an outside reference to its head was
> created,

The attached patch alters the example so that the list object does change (or at
least tries to).

> The opposite of "mutable" is "immutable". Are string literals immutable? They are
> not.

They might be mutable, and they might not be. The documentation deliberately
doesn't say, because we don't want to document the details (they have changed in
the past and are likely to change in the future).

> Overall the phrase "that might be shared" is a good replacement. Why not keep to
> it?

Because it's not an accurate statement of the problem. The set of objects that
might be shared differs from the set of objects that should not change. The
Mutability node focuses on the latter set of objects, and gives the former as an
example but it is not the only sort of object that should not change.

> your new meaning of "mutable" doesn't seem indispensable.

That bar is too high, as hardly anything in the manual is *indispensable*. Ihe
notion of mutability is good to have in the manual, as it reduces confusion and
helps in documentation elsewhere. That's good enough.

I'm attaching two patches. The first are the changes mentioned above, and the
second is a single patch that combines the first patch with the changes I
previously proposed.

[-- Attachment #2: 0001-Update-mutability-doc.patch --]
[-- Type: text/x-patch, Size: 3026 bytes --]

From f2f7cff7c72ca399ca49a50ceac660c3b0991d92 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 10 May 2020 10:01:46 -0700
Subject: [PATCH] Update mutability doc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/lispref/objects.texi (Mutability): Revise in response
to Dmitry Gutov’s comments (Bug#40671#420).
---
 doc/lispref/objects.texi | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi
index a0afadc2d7..7727a630dd 100644
--- a/doc/lispref/objects.texi
+++ b/doc/lispref/objects.texi
@@ -2379,26 +2379,37 @@ Mutability
 @section Mutability
 @cindex mutable objects
 
-  Some Lisp objects should never change.  For example, you can create
-a new number by calculating one, but you cannot modify the value of an
-existing number.
+  Some Lisp objects should never change.  For example, the Lisp
+expression @code{"aaa"} yields a string, but you should not change
+its contents.  Indeed, some objects cannot be changed; for example,
+although you can create a new number by calculating one, Lisp provides
+no operation to change the value of an existing number.
 
   Other Lisp objects are @dfn{mutable}: it is safe to change their
 values via destructive operations involving side effects.  For
 example, an existing marker can be changed by moving the marker to
 point to somewhere else.
 
-  Although numbers never change and all markers are mutable, a type
-can be a hybrid with some members mutable and other members not.  These
-types include conses, vectors, strings, and symbols.  For example, the string
-literal @code{"aaa"} yields a string that should not be changed, whereas the
-call @code{(make-string 3 ?a)} yields a mutable string that can be
+  Although numbers never change and all markers are mutable,
+some types have members some of which are mutable and others not.  These
+types include conses, vectors, strings, and symbols.  For example,
+although @code{"aaa"} yields a string that should not be changed,
+@code{(make-string 3 ?a)} yields a mutable string that can be
 changed via later calls to @code{aset}.
 
   A mutable object stops being mutable if it is part of an expression
-that is evaluated.  For example, in @code{(eval (list 'quote (list 1)))}
-the list @code{(1)} was mutable when it was created, but it should not
-be changed after it was part of an argument to @code{eval}.  The
+that is evaluated.  For example:
+
+@example
+(let* ((x (list 0.5))
+       (y (eval (list 'quote x))))
+  (setcar x 1.5) ;; The program should not do this.
+  y)
+@end example
+
+@noindent
+Although the list @code{(0.5)} was mutable when it was created, it should not
+have been changed via @code{setcar} because it given to @code{eval}.  The
 reverse does not occur: an object that should not be changed never
 becomes mutable afterwards.
 
-- 
2.17.1


[-- Attachment #3: 0001-Don-t-use-constant-for-values-you-shouldn-t-change.patch --]
[-- Type: text/x-patch, Size: 18509 bytes --]

From 1ddbbfd38c280822d1bed3c1281909fbfea1f54f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 10 May 2020 09:27:02 -0700
Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20use=20=E2=80=9Cconstant?=
 =?UTF-8?q?=E2=80=9D=20for=20values=20you=20shouldn=E2=80=99t=20change?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Inspired by patch proposed by Dmitry Gutov (Bug#40671#393)
and by his further comments (Bug#40671#420).
* doc/lispintro/emacs-lisp-intro.texi (setcar):
Don’t push mutability here.
* doc/lispref/eval.texi (Self-Evaluating Forms, Quoting)
(Backquote):
* doc/lispref/lists.texi (Modifying Lists):
* doc/lispref/objects.texi (Lisp Data Types, Mutability):
* doc/lispref/sequences.texi (Array Functions, Vectors):
* doc/lispref/strings.texi (String Basics, Modifying Strings):
Don’t use the word “constant” to describe all values that
a program should not change.
* doc/lispref/objects.texi (Mutability):
Rename from “Constants and Mutability”.  All uses changed.
In a footnote, contrast the Emacs behavior with that of Common
Lisp, Python, etc. for clarity, and say the goal is to be nicer.

Update mutability doc

* doc/lispref/objects.texi (Mutability): Revise in response
to Dmitry Gutov’s comments (Bug#40671#420).
---
 doc/lispintro/emacs-lisp-intro.texi |  5 +-
 doc/lispref/elisp.texi              |  2 +-
 doc/lispref/eval.texi               | 21 +++----
 doc/lispref/lists.texi              | 16 ++---
 doc/lispref/objects.texi            | 90 +++++++++++++++--------------
 doc/lispref/sequences.texi          | 25 ++++----
 doc/lispref/strings.texi            | 11 ++--
 7 files changed, 83 insertions(+), 87 deletions(-)

diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi
index ea16d9ef15..46462162ca 100644
--- a/doc/lispintro/emacs-lisp-intro.texi
+++ b/doc/lispintro/emacs-lisp-intro.texi
@@ -7317,8 +7317,6 @@ setcar
 works is to experiment.  We will start with the @code{setcar} function.
 
 @need 1200
-@cindex constant lists
-@cindex mutable lists
 First, we can make a list and then set the value of a variable to the
 list, using the @code{setq} special form.  Because we intend to use
 @code{setcar} to change the list, this @code{setq} should not use the
@@ -7327,8 +7325,7 @@ setcar
 tried to change part of the program while running it.  Generally
 speaking an Emacs Lisp program's components should be constant (or
 unchanged) while the program is running.  So we instead construct an
-animal list that is @dfn{mutable} (or changeable) by using the
-@code{list} function, as follows:
+animal list by using the @code{list} function, as follows:
 
 @smallexample
 (setq animals (list 'antelope 'giraffe 'lion 'tiger))
diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi
index bba1b63115..9a6796790c 100644
--- a/doc/lispref/elisp.texi
+++ b/doc/lispref/elisp.texi
@@ -297,7 +297,7 @@ Top
 * Circular Objects::        Read syntax for circular structure.
 * Type Predicates::         Tests related to types.
 * Equality Predicates::     Tests of equality between any two objects.
-* Constants and Mutability::  Whether an object's value can change.
+* Mutability::              Some objects should not be modified.
 
 Programming Types
 
diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi
index baddce4d9c..39f342a798 100644
--- a/doc/lispref/eval.texi
+++ b/doc/lispref/eval.texi
@@ -158,11 +158,11 @@ Self-Evaluating Forms
 @end group
 @end example
 
-  A self-evaluating form yields constant conses, vectors and strings, and you
-should not attempt to modify their contents via @code{setcar}, @code{aset} or
+  A self-evaluating form yields a value that becomes part of the program,
+and you should not try to modify it via @code{setcar}, @code{aset} or
 similar operations.  The Lisp interpreter might unify the constants
 yielded by your program's self-evaluating forms, so that these
-constants might share structure.  @xref{Constants and Mutability}.
+constants might share structure.  @xref{Mutability}.
 
   It is common to write numbers, characters, strings, and even vectors
 in Lisp code, taking advantage of the fact that they self-evaluate.
@@ -564,8 +564,8 @@ Quoting
 
 @defspec quote object
 This special form returns @var{object}, without evaluating it.
-The returned value is a constant, and should not be modified.
-@xref{Constants and Mutability}.
+The returned value might be shared and should not be modified.
+@xref{Self-Evaluating Forms}.
 @end defspec
 
 @cindex @samp{'} for quoting
@@ -608,9 +608,9 @@ Quoting
 
   Although the expressions @code{(list '+ 1 2)} and @code{'(+ 1 2)}
 both yield lists equal to @code{(+ 1 2)}, the former yields a
-freshly-minted mutable list whereas the latter yields a constant list
-built from conses that may be shared with other constants.
-@xref{Constants and Mutability}.
+freshly-minted mutable list whereas the latter yields a list
+built from conses that might be shared and should not be modified.
+@xref{Self-Evaluating Forms}.
 
   Other quoting constructs include @code{function} (@pxref{Anonymous
 Functions}), which causes an anonymous lambda expression written in Lisp
@@ -710,8 +710,9 @@ Backquote
 @end example
 
 If a subexpression of a backquote construct has no substitutions or
-splices, it acts like @code{quote} in that it yields constant conses,
-vectors and strings that should not be modified.
+splices, it acts like @code{quote} in that it yields conses,
+vectors and strings that might be shared and should not be modified.
+@xref{Self-Evaluating Forms}.
 
 @node Eval
 @section Eval
diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi
index fcaf4386b1..ae793d5e15 100644
--- a/doc/lispref/lists.texi
+++ b/doc/lispref/lists.texi
@@ -873,8 +873,8 @@ Modifying Lists
 operations because they change existing list structure.
 Destructive operations should be applied only to mutable lists,
 that is, lists constructed via @code{cons}, @code{list} or similar
-operations.  Lists created by quoting are constants and should not be
-changed by destructive operations.  @xref{Constants and Mutability}.
+operations.  Lists created by quoting are part of the program and
+should not be changed by destructive operations.  @xref{Mutability}.
 
 @cindex CL note---@code{rplaca} vs @code{setcar}
 @quotation
@@ -911,7 +911,7 @@ Setcar
 
 @example
 @group
-(setq x (list 1 2))  ; @r{Create a mutable list.}
+(setq x (list 1 2))
      @result{} (1 2)
 @end group
 @group
@@ -931,7 +931,7 @@ Setcar
 
 @example
 @group
-;; @r{Create two mutable lists that are partly shared.}
+;; @r{Create two lists that are partly shared.}
 (setq x1 (list 'a 'b 'c))
      @result{} (a b c)
 (setq x2 (cons 'z (cdr x1)))
@@ -1022,11 +1022,11 @@ Setcdr
 
 @example
 @group
-(setq x (list 1 2 3))  ; @r{Create a mutable list.}
+(setq x (list 1 2 3))
      @result{} (1 2 3)
 @end group
 @group
-(setcdr x '(4))  ; @r{Modify the list's tail to be a constant list.}
+(setcdr x '(4))
      @result{} (4)
 @end group
 @group
@@ -1135,11 +1135,11 @@ Rearrangement
 
 @example
 @group
-(setq x (list 1 2 3))  ; @r{Create a mutable list.}
+(setq x (list 1 2 3))
      @result{} (1 2 3)
 @end group
 @group
-(nconc x '(4 5))  ; @r{Modify the list's tail to be a constant list.}
+(nconc x '(4 5))
      @result{} (1 2 3 4 5)
 @end group
 @group
diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi
index 1d5b2c690f..7727a630dd 100644
--- a/doc/lispref/objects.texi
+++ b/doc/lispref/objects.texi
@@ -46,10 +46,6 @@ Lisp Data Types
 Lisp variables can only take on values of a certain type.
 @xref{Variables with Restricted Values}.)
 
-  Some Lisp objects are @dfn{constant}: their values should never change.
-Others are @dfn{mutable}: their values can be changed via destructive
-operations that involve side effects.
-
   This chapter describes the purpose, printed representation, and read
 syntax of each of the standard types in GNU Emacs Lisp.  Details on how
 to use these types can be found in later chapters.
@@ -63,7 +59,7 @@ Lisp Data Types
 * Circular Objects::            Read syntax for circular structure.
 * Type Predicates::             Tests related to types.
 * Equality Predicates::         Tests of equality between any two objects.
-* Constants and Mutability::    Whether an object's value can change.
+* Mutability::                  Some objects should not be modified.
 @end menu
 
 @node Printed Representation
@@ -2379,51 +2375,59 @@ Equality Predicates
 @end example
 @end defun
 
-@node Constants and Mutability
-@section Constants and Mutability
-@cindex constants
+@node Mutability
+@section Mutability
 @cindex mutable objects
 
-  Some Lisp objects are constant: their values should never change
-during a single execution of Emacs running well-behaved Lisp code.
-For example, you can create a new integer by calculating one, but you
-cannot modify the value of an existing integer.
-
-  Other Lisp objects are mutable: it is safe to change their values
-via destructive operations involving side effects.  For example, an
-existing marker can be changed by moving the marker to point to
-somewhere else.
-
-  Although all numbers are constants and all markers are
-mutable, some types contain both constant and mutable members.  These
-types include conses, vectors, strings, and symbols.  For example, the string
-literal @code{"aaa"} yields a constant string, whereas the function
-call @code{(make-string 3 ?a)} yields a mutable string that can be
+  Some Lisp objects should never change.  For example, the Lisp
+expression @code{"aaa"} yields a string, but you should not change
+its contents.  Indeed, some objects cannot be changed; for example,
+although you can create a new number by calculating one, Lisp provides
+no operation to change the value of an existing number.
+
+  Other Lisp objects are @dfn{mutable}: it is safe to change their
+values via destructive operations involving side effects.  For
+example, an existing marker can be changed by moving the marker to
+point to somewhere else.
+
+  Although numbers never change and all markers are mutable,
+some types have members some of which are mutable and others not.  These
+types include conses, vectors, strings, and symbols.  For example,
+although @code{"aaa"} yields a string that should not be changed,
+@code{(make-string 3 ?a)} yields a mutable string that can be
 changed via later calls to @code{aset}.
 
-  A mutable object can become constant if it is part of an expression
-that is evaluated.  The reverse does not occur: constant objects
-should stay constant.
+  A mutable object stops being mutable if it is part of an expression
+that is evaluated.  For example:
+
+@example
+(let* ((x (list 0.5))
+       (y (eval (list 'quote x))))
+  (setcar x 1.5) ;; The program should not do this.
+  y)
+@end example
+
+@noindent
+Although the list @code{(0.5)} was mutable when it was created, it should not
+have been changed via @code{setcar} because it given to @code{eval}.  The
+reverse does not occur: an object that should not be changed never
+becomes mutable afterwards.
 
   Trying to modify a constant variable signals an error
 (@pxref{Constant Variables}).
-A program should not attempt to modify other types of constants because the
-resulting behavior is undefined: the Lisp interpreter might or might
-not detect the error, and if it does not detect the error the
-interpreter can behave unpredictably thereafter.  Another way to put
-this is that although mutable objects are safe to change and constant
-variables reliably prevent attempts to change them, other constants
-are not safely mutable: if a misbehaving program tries to change such a
-constant then the constant's value might actually change, or the
-program might crash or worse.  This problem occurs
-with types that have both constant and mutable members, and that have
-mutators like @code{setcar} and @code{aset} that are valid on mutable
-objects but hazardous on constants.
-
-  When the same constant occurs multiple times in a program, the Lisp
-interpreter might save time or space by reusing existing constants or
-constant components.  For example, @code{(eq "abc" "abc")} returns
+If a program attempts to change other objects that should not be
+changed, the resulting behavior is undefined: the Lisp interpreter
+might signal an error, or it might crash or behave unpredictably in
+other ways.@footnote{This is the behavior specified for languages like
+Common Lisp and C, and it differs from the behavior of languages like
+JavaScript and Python where an interpreter is required to signal an
+error if a program attempts to change a constant.  Ideally the Emacs
+Lisp interpreter will evolve in latter direction.}
+
+  When the same value appears multiple times in a program, the Lisp
+interpreter might save time or space by reusing existing values or
+their components.  For example, @code{(eq "abc" "abc")} returns
 @code{t} if the interpreter creates only one instance of the string
-constant @code{"abc"}, and returns @code{nil} if it creates two
+literal @code{"abc"}, and returns @code{nil} if it creates two
 instances.  Lisp programs should be written so that they work
 regardless of whether this optimization is in use.
diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi
index 1cb0d05cc7..91c3049f87 100644
--- a/doc/lispref/sequences.texi
+++ b/doc/lispref/sequences.texi
@@ -183,11 +183,11 @@ Sequence Functions
 
 @example
 @group
-(setq bar (list 1 2))  ; @r{Create a mutable list.}
+(setq bar (list 1 2))
      @result{} (1 2)
 @end group
 @group
-(setq x (vector 'foo bar))  ; @r{Create a mutable vector.}
+(setq x (vector 'foo bar))
      @result{} [foo (1 2)]
 @end group
 @group
@@ -278,7 +278,7 @@ Sequence Functions
 
 @example
 @group
-(setq x (list 'a 'b 'c))  ; @r{Create a mutable list.}
+(setq x (list 'a 'b 'c))
      @result{} (a b c)
 @end group
 @group
@@ -320,7 +320,7 @@ Sequence Functions
   For the vector, it is even simpler because you don't need setq:
 
 @example
-(setq x (copy-sequence [1 2 3 4]))  ; @r{Create a mutable vector.}
+(setq x (copy-sequence [1 2 3 4]))
      @result{} [1 2 3 4]
 (nreverse x)
      @result{} [4 3 2 1]
@@ -331,6 +331,7 @@ Sequence Functions
 Note that unlike @code{reverse}, this function doesn't work with strings.
 Although you can alter string data by using @code{aset}, it is strongly
 encouraged to treat strings as immutable even when they are mutable.
+@xref{Mutability}.
 
 @end defun
 
@@ -374,7 +375,7 @@ Sequence Functions
 
 @example
 @group
-(setq nums (list 1 3 2 6 5 4 0))  ; @r{Create a mutable list.}
+(setq nums (list 1 3 2 6 5 4 0))
      @result{} (1 3 2 6 5 4 0)
 @end group
 @group
@@ -1228,7 +1229,7 @@ Array Functions
 
 @example
 @group
-(setq w (vector 'foo 'bar 'baz))  ; @r{Create a mutable vector.}
+(setq w (vector 'foo 'bar 'baz))
      @result{} [foo bar baz]
 (aset w 0 'fu)
      @result{} fu
@@ -1237,7 +1238,7 @@ Array Functions
 @end group
 
 @group
-;; @r{@code{copy-sequence} creates a mutable string.}
+;; @r{@code{copy-sequence} copies the string to be modified later.}
 (setq x (copy-sequence "asdfasfd"))
      @result{} "asdfasfd"
 (aset x 3 ?Z)
@@ -1247,9 +1248,7 @@ Array Functions
 @end group
 @end example
 
-The @var{array} should be mutable; that is, it should not be a constant,
-such as the constants created via quoting or via self-evaluating forms.
-@xref{Constants and Mutability}.
+The @var{array} should be mutable.  @xref{Mutability}.
 
 If @var{array} is a string and @var{object} is not a character, a
 @code{wrong-type-argument} error results.  The function converts a
@@ -1262,7 +1261,6 @@ Array Functions
 
 @example
 @group
-;; @r{Create a mutable vector and then fill it with zeros.}
 (setq a (copy-sequence [a b c d e f g]))
      @result{} [a b c d e f g]
 (fillarray a 0)
@@ -1271,7 +1269,6 @@ Array Functions
      @result{} [0 0 0 0 0 0 0]
 @end group
 @group
-;; @r{Create a mutable string and then fill it with "-".}
 (setq s (copy-sequence "When in the course"))
      @result{} "When in the course"
 (fillarray s ?-)
@@ -1310,8 +1307,8 @@ Vectors
 evaluation: the result of evaluating it is the same vector.  This does
 not evaluate or even examine the elements of the vector.
 @xref{Self-Evaluating Forms}.  Vectors written with square brackets
-are constants and should not be modified via @code{aset} or other
-destructive operations.  @xref{Constants and Mutability}.
+should not be modified via @code{aset} or other destructive
+operations.  @xref{Mutability}.
 
   Here are examples illustrating these principles:
 
diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi
index a4c9c2549c..70c3b3cf4b 100644
--- a/doc/lispref/strings.texi
+++ b/doc/lispref/strings.texi
@@ -49,10 +49,9 @@ String Basics
 
   Since strings are arrays, and therefore sequences as well, you can
 operate on them with the general array and sequence functions documented
-in @ref{Sequences Arrays Vectors}.  For example, you can access or
-change individual characters in a string using the functions @code{aref}
-and @code{aset} (@pxref{Array Functions}).  However, you should not
-try to change the contents of constant strings (@pxref{Modifying Strings}).
+in @ref{Sequences Arrays Vectors}.  For example, you can access
+individual characters in a string using the function @code{aref}
+(@pxref{Array Functions}).
 
   There are two text representations for non-@acronym{ASCII}
 characters in Emacs strings (and in buffers): unibyte and multibyte.
@@ -382,9 +381,7 @@ Modifying Strings
 @cindex string modification
 
   You can alter the contents of a mutable string via operations
-described in this section.  However, you should not try to use these
-operations to alter the contents of a constant string.
-@xref{Constants and Mutability}.
+described in this section.  @xref{Mutability}.
 
   The most basic way to alter the contents of an existing string is with
 @code{aset} (@pxref{Array Functions}).  @code{(aset @var{string}
-- 
2.17.1


  parent reply	other threads:[~2020-05-10 17:29 UTC|newest]

Thread overview: 170+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 19:28 bug#40671: [DOC] modify literal objects Kevin Vigouroux via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-04-17 16:09 ` Mattias Engdegård
2020-04-17 16:37   ` Mattias Engdegård
2020-04-17 17:27     ` Eli Zaretskii
2020-04-18 20:10 ` Paul Eggert
2020-04-18 21:54   ` Drew Adams
2020-04-19  2:39     ` Noam Postavsky
2020-04-19 20:39     ` Paul Eggert
2020-04-19 21:01       ` Drew Adams
2020-04-19 21:16         ` Paul Eggert
2020-04-19 22:24           ` Drew Adams
2020-04-19 22:51             ` Paul Eggert
2020-04-20  5:32               ` Drew Adams
2020-04-22 17:36                 ` Paul Eggert
2020-05-01  3:03     ` Dmitry Gutov
2020-05-01  5:16       ` Drew Adams
2020-05-01 21:46       ` Paul Eggert
2020-05-01 23:37         ` Dmitry Gutov
2020-04-19  2:26   ` Richard Stallman
2020-04-19 13:56   ` Eli Zaretskii
2020-04-19 16:59     ` Mattias Engdegård
2020-04-19 19:21       ` Eli Zaretskii
2020-04-19 21:02       ` Paul Eggert
2020-04-19 21:11         ` Drew Adams
2020-04-19 21:57         ` Michael Heerdegen
2020-04-19 22:41           ` Paul Eggert
2020-04-19 23:45             ` Michael Heerdegen
2020-04-20  0:24               ` Paul Eggert
2020-04-20  0:53                 ` Michael Heerdegen
2020-04-20  3:23                   ` Paul Eggert
2020-04-20  3:36                     ` Michael Heerdegen
2020-04-22  6:30                       ` Paul Eggert
2020-04-20  5:54                     ` Drew Adams
2020-04-22 17:21                       ` Paul Eggert
2020-04-23  0:49                         ` Michael Heerdegen
2020-04-24  2:36                           ` Richard Stallman
2020-04-24 15:08                             ` Drew Adams
2020-04-25  1:58                               ` Paul Eggert
2020-04-24 16:39                             ` Mattias Engdegård
2020-04-24 16:46                               ` Dmitry Gutov
2020-04-25  2:21                                 ` Paul Eggert
2020-04-25  2:40                                   ` Dmitry Gutov
2020-04-25  3:20                                     ` Paul Eggert
2020-04-25 19:30                                       ` Dmitry Gutov
2020-04-26  3:49                                         ` Paul Eggert
2020-04-26 14:03                                           ` Dmitry Gutov
2020-04-26 14:19                                             ` Eli Zaretskii
2020-04-26 14:34                                               ` Dmitry Gutov
2020-04-26 15:46                                                 ` Eli Zaretskii
2020-04-26 16:02                                                   ` Dmitry Gutov
2020-04-26 16:58                                                     ` Eli Zaretskii
2020-04-26 17:39                                                       ` Dmitry Gutov
2020-04-26 18:14                                                         ` Eli Zaretskii
2020-04-26 18:32                                                           ` Dmitry Gutov
2020-04-26 18:41                                                             ` Eli Zaretskii
2020-04-26 18:53                                                               ` Dmitry Gutov
2020-04-26 18:57                                             ` Paul Eggert
2020-04-26 19:22                                               ` Philipp Stephani
2020-04-26 20:14                                                 ` Paul Eggert
2020-04-26 21:23                                               ` Dmitry Gutov
2020-04-26 23:13                                                 ` Paul Eggert
2020-04-27  0:53                                                   ` Dmitry Gutov
2020-04-27  1:49                                                     ` Paul Eggert
2020-04-28  3:05                                                       ` Dmitry Gutov
2020-04-28  8:17                                                         ` Paul Eggert
2020-04-28 13:54                                                           ` Dmitry Gutov
2020-04-28 17:59                                                             ` Paul Eggert
2020-04-28 18:46                                                               ` Dmitry Gutov
2020-04-28 19:20                                                                 ` Paul Eggert
2020-04-28 19:33                                                                   ` Dmitry Gutov
2020-04-28 20:09                                                                     ` Paul Eggert
2020-04-28 21:10                                                                       ` Dmitry Gutov
2020-04-28 23:10                                                                         ` Paul Eggert
2020-04-28 23:36                                                                           ` Dmitry Gutov
2020-04-28 23:53                                                                             ` Paul Eggert
2020-04-28 23:57                                                                               ` Dmitry Gutov
2020-04-28 23:53                                                                           ` Dmitry Gutov
2020-04-29  0:04                                                                             ` Paul Eggert
2020-04-29  0:14                                                                               ` Dmitry Gutov
2020-04-29  0:55                                                                           ` Drew Adams
2020-04-29  1:03                                                                             ` Dmitry Gutov
2020-04-29  1:15                                                                               ` Drew Adams
2020-04-29  1:27                                                                                 ` Michael Heerdegen
2020-04-29  1:38                                                                             ` Paul Eggert
2020-04-29  4:36                                                                               ` Drew Adams
2020-04-29 16:18                                                                                 ` Paul Eggert
2020-05-01  2:47                                                                                   ` Richard Stallman
2020-05-01  6:23                                                                                     ` Eli Zaretskii
2020-05-01  3:13                                                                               ` Dmitry Gutov
2020-05-01  5:15                                                                                 ` Drew Adams
2020-05-01 21:40                                                                                 ` Paul Eggert
2020-05-01 22:05                                                                                   ` Drew Adams
2020-05-01 22:28                                                                                     ` Paul Eggert
2020-05-02  1:07                                                                                   ` Dmitry Gutov
2020-05-02  6:28                                                                                     ` Paul Eggert
2020-05-02 15:42                                                                                       ` Dmitry Gutov
2020-05-02 19:35                                                                                         ` Paul Eggert
2020-05-03  1:30                                                                                           ` Dmitry Gutov
2020-05-03  7:40                                                                                             ` Paul Eggert
2020-05-03 16:44                                                                                               ` Dmitry Gutov
2020-05-03 20:48                                                                                                 ` Paul Eggert
2020-05-03 22:17                                                                                                   ` Dmitry Gutov
2020-05-03 22:18                                                                                                   ` Dmitry Gutov
2020-05-03 22:39                                                                                                     ` Paul Eggert
2020-05-03 22:53                                                                                                       ` Dmitry Gutov
2020-05-03 23:10                                                                                                         ` Paul Eggert
2020-05-04 10:16                                                                                                           ` Dmitry Gutov
2020-05-04 17:52                                                                                                             ` Paul Eggert
2020-05-05  1:39                                                                                                               ` Dmitry Gutov
2020-05-05  6:09                                                                                                                 ` Paul Eggert
2020-05-05 12:38                                                                                                                   ` Dmitry Gutov
2020-05-09  6:10                                                                                                                     ` Paul Eggert
2020-05-10  3:13                                                                                                                       ` Dmitry Gutov
2020-05-10 13:34                                                                                                                         ` Dmitry Gutov
2020-05-10 17:29                                                                                                                         ` Paul Eggert [this message]
2020-05-11  0:00                                                                                                                           ` Michael Heerdegen
2020-05-11  0:26                                                                                                                             ` Dmitry Gutov
2020-05-11  1:47                                                                                                                             ` Drew Adams
2020-05-11  1:54                                                                                                                               ` Dmitry Gutov
2020-05-11  2:33                                                                                                                                 ` Drew Adams
2020-05-11  2:56                                                                                                                               ` Michael Heerdegen
2020-05-11  4:21                                                                                                                                 ` Drew Adams
2020-05-11  4:51                                                                                                                                   ` Michael Heerdegen
2020-05-11  6:28                                                                                                                                     ` Paul Eggert
2020-05-11 13:57                                                                                                                                       ` Noam Postavsky
2020-05-11 22:36                                                                                                                                         ` Michael Heerdegen
2020-05-11 22:30                                                                                                                                       ` Michael Heerdegen
2020-05-12  3:20                                                                                                                                       ` Richard Stallman
2020-05-12  4:24                                                                                                                                         ` Michael Heerdegen
2020-05-13  3:57                                                                                                                                           ` Richard Stallman
2020-05-13  5:05                                                                                                                                             ` Michael Heerdegen
2020-05-14  5:14                                                                                                                                               ` Richard Stallman
     [not found]                                                                                                                                       ` <05BEF593-F16A-4DEE-98BC-653221F1F9EE@acm.org>
2020-05-17  0:11                                                                                                                                         ` Paul Eggert
2020-05-17  9:43                                                                                                                                           ` Mattias Engdegård
2020-05-17 16:38                                                                                                                                             ` Paul Eggert
2020-05-11  1:53                                                                                                                             ` Paul Eggert
2020-05-11  3:18                                                                                                                               ` Michael Heerdegen
2020-05-11  0:44                                                                                                                           ` Dmitry Gutov
2020-05-11  1:57                                                                                                                             ` Paul Eggert
2020-05-12  1:59                                                                                                                               ` Dmitry Gutov
2020-05-17  1:28                                                                                                                                 ` Paul Eggert
2020-05-17  5:02                                                                                                                                   ` Michael Heerdegen
2020-05-17 16:34                                                                                                                                     ` Paul Eggert
2020-05-17 12:39                                                                                                                                   ` Dmitry Gutov
2020-05-17 16:21                                                                                                                                     ` Paul Eggert
2020-05-05 17:40                                                                                                                   ` Drew Adams
2020-05-05 18:49                                                                                                                     ` Dmitry Gutov
2020-05-05 19:26                                                                                                                       ` Drew Adams
2020-05-05 20:48                                                                                                               ` Kevin Vigouroux via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-09  5:57                                                                                                                 ` Paul Eggert
2020-04-28 21:18                                                                       ` Dmitry Gutov
2020-04-28 17:25                                                           ` Drew Adams
2020-04-28 17:47                                                             ` Paul Eggert
2020-04-29  0:32                                                               ` Michael Heerdegen
2020-04-29  1:40                                                                 ` Paul Eggert
2020-04-29  4:40                                                                   ` Michael Heerdegen
2020-04-29  8:01                                                                     ` Eli Zaretskii
2020-04-29 16:36                                                                 ` Paul Eggert
2020-04-24 17:18                               ` Drew Adams
2020-04-25  3:38                               ` Richard Stallman
2020-04-25 18:26                                 ` Paul Eggert
2020-04-25  2:22                           ` Paul Eggert
2020-04-25  6:00                             ` Andreas Schwab
2020-04-25 18:23                               ` Paul Eggert
2020-04-28 23:52                             ` Michael Heerdegen
2020-04-21  1:25               ` Michael Heerdegen
2020-04-21  2:20                 ` Paul Eggert
2020-04-20  6:02             ` Drew Adams
2020-04-19 20:45     ` Paul Eggert
2020-04-20 14:10       ` 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=41d69e2e-561f-743a-e1f0-282b2e22b66c@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=40671@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=ke.vigouroux@laposte.net \
    --cc=mattiase@acm.org \
    --cc=michael_heerdegen@web.de \
    --cc=rms@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.