bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

Quote with curved single quotes, ‘like this’, in diagnostics
generated from C code.  This mostly uses C11-style UTF-8 strings,
e.g., u8"quote ‘like this’", with a backward compatibility macro
u8 for pre-C11 compilers.
* src/buffer.c (Fmake_indirect_buffer, Frename_buffer)
(Fset_buffer_multibyte):
* src/callint.c (Fcall_interactively):
* src/category.c (Fmake_category_set, Fdefine_category):
* src/chartab.c (Fchar_table_range, Fset_char_table_range):
* src/coding.c (Ffind_operation_coding_system)
(Fdefine_coding_system_internal):
* src/dispnew.c (add_window_display_history):
* src/editfns.c (Fsubst_char_in_region):
* src/eval.c (FletX, Flet, eval_sub, Ffuncall):
* src/fileio.c (Ffile_name_nondirectory)
(Ffile_name_as_directory, Fdirectory_file_name)
(Fexpand_file_name, Fsubstitute_in_file_name):
* src/fns.c (Frequire):
* src/font.c (Ffont_spec):
* src/fontset.c (check_fontset_name):
* src/frame.c (x_set_font):
* src/image.c (xbm_read_bitmap_data, xbm_load_image, xbm_load)
(xpm_load, xpm_load_image, xpm_load, pbm_load, png_load_body)
(jpeg_load_body, tiff_load, gif_load, imagemagick_load_image)
(imagemagick_load, svg_load, svg_load_image, gs_load)
(x_kill_gs_process):
* src/keymap.c (store_in_keymap, Fdescribe_buffer_bindings):
* src/lread.c (load_warn_old_style_backquotes, Fload):
* src/nsfns.m (Fns_list_colors):
* src/regex.c (PUSH_FAILURE_POINT, POP_FAILURE_POINT)
(re_match_2_internal):
* src/search.c (Freplace_match):
* src/syntax.c (Finternal_describe_syntax_value):
* src/sysdep.c (serial_configure):
* src/w32.c (serial_configure):
* src/window.c (Fset_frame_selected_window, Fset_window_buffer)
(Frecenter):
* src/xfaces.c (load_pixmap):
Reword to avoid quoting with grave accent and apostrophe
in diagnostics.
* src/conf_post.h (u8): New macro, for compatibility with pre-C11.
* src/doc.c (Fsubstitute_command_keys):
Use curved quotes when generating keymap info.
* src/lisp.h (uLSQM, uRSQM): New macros.
---
 src/buffer.c    |   8 ++--
 src/callint.c   |   5 ++-
 src/category.c  |   4 +-
 src/chartab.c   |   4 +-
 src/coding.c    |   6 +--
 src/conf_post.h |   4 ++
 src/dispnew.c   |   2 +-
 src/doc.c       |   4 +-
 src/editfns.c   |   2 +-
 src/eval.c      |   8 ++--
 src/fileio.c    |  14 +++---
 src/fns.c       |   4 +-
 src/font.c      |   2 +-
 src/fontset.c   |   2 +-
 src/frame.c     |   4 +-
 src/image.c     | 130 ++++++++++++++++++++++++++++----------------------------
 src/keymap.c    |   6 +--
 src/lisp.h      |   7 +++
 src/lread.c     |   8 ++--
 src/nsfns.m     |   2 +-
 src/regex.c     |  14 +++---
 src/search.c    |   6 +--
 src/syntax.c    |   2 +-
 src/sysdep.c    |   4 +-
 src/w32.c       |   4 +-
 src/window.c    |   6 +--
 src/xfaces.c    |   2 +-
 27 files changed, 138 insertions(+), 126 deletions(-)

diff --git a/src/buffer.c b/src/buffer.c
index 0b98431..f95a726 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -745,12 +745,12 @@ CLONE nil means the indirect buffer's state is reset to default values.  */)
   CHECK_STRING (name);
   buf = Fget_buffer (name);
   if (!NILP (buf))
-    error ("Buffer name `%s' is in use", SDATA (name));
+    error (u8"Buffer name ‘%s’ is in use", SDATA (name));
 
   tem = base_buffer;
   base_buffer = Fget_buffer (base_buffer);
   if (NILP (base_buffer))
-    error ("No such buffer: `%s'", SDATA (tem));
+    error (u8"No such buffer: ‘%s’", SDATA (tem));
   if (!BUFFER_LIVE_P (XBUFFER (base_buffer)))
     error ("Base buffer has been killed");
 
@@ -1429,7 +1429,7 @@ This does not change the name of the visited file (if any).  */)
       if (!NILP (unique))
 	newname = Fgenerate_new_buffer_name (newname, BVAR (current_buffer, name));
       else
-	error ("Buffer name `%s' is in use", SDATA (newname));
+	error (u8"Buffer name ‘%s’ is in use", SDATA (newname));
     }
 
   bset_name (current_buffer, newname);
@@ -2412,7 +2412,7 @@ current buffer is cleared.  */)
   struct gcpro gcpro1;
 
   if (current_buffer->base_buffer)
-    error ("Cannot do `set-buffer-multibyte' on an indirect buffer");
+    error (u8"Cannot do ‘set-buffer-multibyte’ on an indirect buffer");
 
   /* Do nothing if nothing actually changes.  */
   if (NILP (flag) == NILP (BVAR (current_buffer, enable_multibyte_characters)))
diff --git a/src/callint.c b/src/callint.c
index 2ff2f80..d31aade 100644
--- a/src/callint.c
+++ b/src/callint.c
@@ -413,7 +413,7 @@ invoke it.  If KEYS is omitted or nil, the return value of
   while (1)
     {
       if (*string == '+')
-	error ("`+' is not used in `interactive' for ordinary commands");
+	error (u8"‘+’ is not used in ‘interactive’ for ordinary commands");
       else if (*string == '*')
 	{
 	  string++;
@@ -785,7 +785,8 @@ invoke it.  If KEYS is omitted or nil, the return value of
 	     if anyone tries to define one here.  */
 	case '+':
 	default:
-	  error ("Invalid control letter `%c' (#o%03o, #x%04x) in interactive calling string",
+	  error ((u8"Invalid control letter ‘%c’ (#o%03o, #x%04x)"
+		  u8" in interactive calling string"),
 		 STRING_CHAR ((unsigned char *) tem),
 		 (unsigned) STRING_CHAR ((unsigned char *) tem),
 		 (unsigned) STRING_CHAR ((unsigned char *) tem));
diff --git a/src/category.c b/src/category.c
index ab90f5f..5dadea4 100644
--- a/src/category.c
+++ b/src/category.c
@@ -100,7 +100,7 @@ those categories.  */)
   val = MAKE_CATEGORY_SET;
 
   if (STRING_MULTIBYTE (categories))
-    error ("Multibyte string in `make-category-set'");
+    error (u8"Multibyte string in ‘make-category-set’");
 
   len = SCHARS (categories);
   while (--len >= 0)
@@ -134,7 +134,7 @@ the current buffer's category table.  */)
   table = check_category_table (table);
 
   if (!NILP (CATEGORY_DOCSTRING (table, XFASTINT (category))))
-    error ("Category `%c' is already defined", (int) XFASTINT (category));
+    error (u8"Category ‘%c’ is already defined", (int) XFASTINT (category));
   if (!NILP (Vpurify_flag))
     docstring = Fpurecopy (docstring);
   SET_CATEGORY_DOCSTRING (table, XFASTINT (category), docstring);
diff --git a/src/chartab.c b/src/chartab.c
index acaabce..b0d3d9a 100644
--- a/src/chartab.c
+++ b/src/chartab.c
@@ -622,7 +622,7 @@ a cons of character codes (for characters in the range), or a character code.  *
       /* Not yet implemented. */
     }
   else
-    error ("Invalid RANGE argument to `char-table-range'");
+    error (u8"Invalid RANGE argument to ‘char-table-range’");
   return val;
 }
 
@@ -655,7 +655,7 @@ or a character code.  Return VALUE.  */)
 			    XINT (XCAR (range)), XINT (XCDR (range)), value);
     }
   else
-    error ("Invalid RANGE argument to `set-char-table-range'");
+    error (u8"Invalid RANGE argument to ‘set-char-table-range’");
 
   return value;
 }
diff --git a/src/coding.c b/src/coding.c
index 9342c38..8f536d4 100644
--- a/src/coding.c
+++ b/src/coding.c
@@ -9853,14 +9853,14 @@ usage: (find-operation-coding-system OPERATION ARGUMENTS...)  */)
       || (target_idx = Fget (operation, Qtarget_idx), !NATNUMP (target_idx)))
     error ("Invalid first argument");
   if (nargs <= 1 + XFASTINT (target_idx))
-    error ("Too few arguments for operation `%s'",
+    error (u8"Too few arguments for operation ‘%s’",
 	   SDATA (SYMBOL_NAME (operation)));
   target = args[XFASTINT (target_idx) + 1];
   if (!(STRINGP (target)
 	|| (EQ (operation, Qinsert_file_contents) && CONSP (target)
 	    && STRINGP (XCAR (target)) && BUFFERP (XCDR (target)))
 	|| (EQ (operation, Qopen_network_stream) && INTEGERP (target))))
-    error ("Invalid argument %"pI"d of operation `%s'",
+    error ("Invalid argument %"pI"d of operation "uLSQM"%s"uRSQM,
 	   XFASTINT (target_idx) + 1, SDATA (SYMBOL_NAME (operation)));
   if (CONSP (target))
     target = XCAR (target);
@@ -10094,7 +10094,7 @@ usage: (define-coding-system-internal ...)  */)
 	      : EQ (coding_type, Qemacs_mule)
 	      ? CHARSET_EMACS_MULE_ID (charset) < 0
 	      : 0)
-	    error ("Can't handle charset `%s'",
+	    error (u8"Can't handle charset ‘%s’",
 		   SDATA (SYMBOL_NAME (CHARSET_NAME (charset))));
 
 	  XSETCAR (tail, make_number (charset->id));
diff --git a/src/conf_post.h b/src/conf_post.h
index 1a080fa..e9c7863 100644
--- a/src/conf_post.h
+++ b/src/conf_post.h
@@ -43,6 +43,10 @@ typedef unsigned int bool_bf;
 typedef bool bool_bf;
 #endif
 
+/* On older compilers that do not support C11-style UTF-8 string literals,
+   treat the u8 encoding prefix as a no-op.  */
+#define u8
+
 #ifndef WINDOWSNT
 /* On AIX 3 this must be included before any other include file.  */
 #include <alloca.h>
diff --git a/src/dispnew.c b/src/dispnew.c
index 1fc3cfe..ede7adf 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -177,7 +177,7 @@ add_window_display_history (struct window *w, const char *msg, bool paused_p)
   ++history_idx;
 
   snprintf (buf, sizeof redisplay_history[0].trace,
-	    "%"pMu": window %p (`%s')%s\n%s",
+	    "%"pMu": window %p ("uLSQM"%s"uRSQM")%s\n%s",
 	    history_tick++,
 	    ptr,
 	    ((BUFFERP (w->contents)
diff --git a/src/doc.c b/src/doc.c
index f1ba643..aa87282 100644
--- a/src/doc.c
+++ b/src/doc.c
@@ -891,11 +891,11 @@ Otherwise, return a new string.  */)
 	  if (NILP (tem))
 	    {
 	      name = Fsymbol_name (name);
-	      insert_string ("\nUses keymap `");
+	      insert_string (u8"\nUses keymap ‘");
 	      insert_from_string (name, 0, 0,
 				  SCHARS (name),
 				  SBYTES (name), 1);
-	      insert_string ("', which is not currently defined.\n");
+	      insert_string (u8"’, which is not currently defined.\n");
 	      if (start[-1] == '<') keymap = Qnil;
 	    }
 	  else if (start[-1] == '<')
diff --git a/src/editfns.c b/src/editfns.c
index c387dc7..8dc2a47 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -2994,7 +2994,7 @@ Both characters must have the same length of multi-byte form.  */)
     {
       len = CHAR_STRING (fromc, fromstr);
       if (CHAR_STRING (toc, tostr) != len)
-	error ("Characters in `subst-char-in-region' have different byte-lengths");
+	error (u8"Characters in ‘subst-char-in-region’ have different byte-lengths");
       if (!ASCII_CHAR_P (*tostr))
 	{
 	  /* If *TOSTR is in the range 0x80..0x9F and TOCHAR is not a
diff --git a/src/eval.c b/src/eval.c
index 4655095..92b5653 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -864,7 +864,7 @@ usage: (let* VARLIST BODY...)  */)
 	  val = Qnil;
 	}
       else if (! NILP (Fcdr (Fcdr (elt))))
-	signal_error ("`let' bindings can have only one value-form", elt);
+	signal_error (u8"‘let’ bindings can have only one value-form", elt);
       else
 	{
 	  var = Fcar (elt);
@@ -931,7 +931,7 @@ usage: (let VARLIST BODY...)  */)
       if (SYMBOLP (elt))
 	temps [argnum++] = Qnil;
       else if (! NILP (Fcdr (Fcdr (elt))))
-	signal_error ("`let' bindings can have only one value-form", elt);
+	signal_error (u8"‘let’ bindings can have only one value-form", elt);
       else
 	temps [argnum++] = eval_sub (Fcar (Fcdr (elt)));
       gcpro2.nvars = argnum;
@@ -2087,7 +2087,7 @@ eval_sub (Lisp_Object form)
       if (max_lisp_eval_depth < 100)
 	max_lisp_eval_depth = 100;
       if (lisp_eval_depth > max_lisp_eval_depth)
-	error ("Lisp nesting exceeds `max-lisp-eval-depth'");
+	error (u8"Lisp nesting exceeds ‘max-lisp-eval-depth’");
     }
 
   original_fun = XCAR (form);
@@ -2658,7 +2658,7 @@ usage: (funcall FUNCTION &rest ARGUMENTS)  */)
       if (max_lisp_eval_depth < 100)
 	max_lisp_eval_depth = 100;
       if (lisp_eval_depth > max_lisp_eval_depth)
-	error ("Lisp nesting exceeds `max-lisp-eval-depth'");
+	error (u8"Lisp nesting exceeds ‘max-lisp-eval-depth’");
     }
 
   /* This also GCPROs them.  */
diff --git a/src/fileio.c b/src/fileio.c
index aad0270..13ee4c0 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -410,7 +410,7 @@ or the entire name if it contains no slash.  */)
 					filename);
       if (STRINGP (handled_name))
 	return handled_name;
-      error ("Invalid handler in `file-name-handler-alist'");
+      error (u8"Invalid handler in ‘file-name-handler-alist’");
     }
 
   beg = SSDATA (filename);
@@ -514,7 +514,7 @@ For a Unix-syntax file name, just appends a slash.  */)
 					file);
       if (STRINGP (handled_name))
 	return handled_name;
-      error ("Invalid handler in `file-name-handler-alist'");
+      error (u8"Invalid handler in ‘file-name-handler-alist’");
     }
 
 #ifdef WINDOWSNT
@@ -580,7 +580,7 @@ In Unix-syntax, this function just removes the final slash.  */)
 					directory);
       if (STRINGP (handled_name))
 	return handled_name;
-      error ("Invalid handler in `file-name-handler-alist'");
+      error (u8"Invalid handler in ‘file-name-handler-alist’");
     }
 
 #ifdef WINDOWSNT
@@ -798,7 +798,7 @@ filesystem tree, not (expand-file-name ".."  dirname).  */)
 			    name, default_directory);
       if (STRINGP (handled_name))
 	return handled_name;
-      error ("Invalid handler in `file-name-handler-alist'");
+      error (u8"Invalid handler in ‘file-name-handler-alist’");
     }
 
 
@@ -831,7 +831,7 @@ filesystem tree, not (expand-file-name ".."  dirname).  */)
 				name, default_directory);
 	  if (STRINGP (handled_name))
 	    return handled_name;
-	  error ("Invalid handler in `file-name-handler-alist'");
+	  error (u8"Invalid handler in ‘file-name-handler-alist’");
 	}
     }
 
@@ -1424,7 +1424,7 @@ filesystem tree, not (expand-file-name ".."  dirname).  */)
       handled_name = call3 (handler, Qexpand_file_name,
 			    result, default_directory);
       if (! STRINGP (handled_name))
-	error ("Invalid handler in `file-name-handler-alist'");
+	error (u8"Invalid handler in ‘file-name-handler-alist’");
       result = handled_name;
     }
 
@@ -1680,7 +1680,7 @@ those `/' is discarded.  */)
 					filename);
       if (STRINGP (handled_name))
 	return handled_name;
-      error ("Invalid handler in `file-name-handler-alist'");
+      error (u8"Invalid handler in ‘file-name-handler-alist’");
     }
 
   /* Always work on a copy of the string, in case GC happens during
diff --git a/src/fns.c b/src/fns.c
index 235a4f6..642df5c 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2878,7 +2878,7 @@ The normal messages at start and end of loading FILENAME are suppressed.  */)
 	  tem = XCDR (tem);
 	}
       if (nesting > 3)
-	error ("Recursive `require' for feature `%s'",
+	error (u8"Recursive ‘require’ for feature ‘%s’",
 	       SDATA (SYMBOL_NAME (feature)));
 
       /* Update the list for any nested `require's that occur.  */
@@ -2901,7 +2901,7 @@ The normal messages at start and end of loading FILENAME are suppressed.  */)
 
       tem = Fmemq (feature, Vfeatures);
       if (NILP (tem))
-	error ("Required feature `%s' was not provided",
+	error (u8"Required feature ‘%s’ was not provided",
 	       SDATA (SYMBOL_NAME (feature)));
 
       /* Once loading finishes, don't undo it.  */
diff --git a/src/font.c b/src/font.c
index 1405d43..4fb5d52 100644
--- a/src/font.c
+++ b/src/font.c
@@ -3885,7 +3885,7 @@ usage: (font-spec ARGS...)  */)
 
       CHECK_SYMBOL (key);
       if (i + 1 >= nargs)
-	error ("No value for key `%s'", SDATA (SYMBOL_NAME (key)));
+	error (u8"No value for key ‘%s’", SDATA (SYMBOL_NAME (key)));
       val = args[i + 1];
 
       if (EQ (key, QCname))
diff --git a/src/fontset.c b/src/fontset.c
index e957c38..848bc7a 100644
--- a/src/fontset.c
+++ b/src/fontset.c
@@ -1303,7 +1303,7 @@ check_fontset_name (Lisp_Object name, Lisp_Object *frame)
 	/* For backward compatibility, try again NAME as pattern.  */
 	id = fs_query_fontset (name, 0);
       if (id < 0)
-	error ("Fontset `%s' does not exist", SDATA (name));
+	error (u8"Fontset ‘%s’ does not exist", SDATA (name));
     }
   return FONTSET_FROM_ID (id);
 }
diff --git a/src/frame.c b/src/frame.c
index e3ad82f..368775e 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -3562,14 +3562,14 @@ x_set_font (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 	{
 	  font_object = font_open_by_name (f, arg);
 	  if (NILP (font_object))
-	    error ("Font `%s' is not defined", SSDATA (arg));
+	    error (u8"Font ‘%s’ is not defined", SSDATA (arg));
 	  arg = AREF (font_object, FONT_NAME_INDEX);
 	}
       else if (fontset > 0)
 	{
 	  font_object = font_open_by_name (f, fontset_ascii (fontset));
 	  if (NILP (font_object))
-	    error ("Font `%s' is not defined", SDATA (arg));
+	    error (u8"Font ‘%s’ is not defined", SDATA (arg));
 	  arg = AREF (font_object, FONT_NAME_INDEX);
 	}
       else
diff --git a/src/image.c b/src/image.c
index dfa8941..a33448c 100644
--- a/src/image.c
+++ b/src/image.c
@@ -2791,7 +2791,7 @@ xbm_read_bitmap_data (struct frame *f, unsigned char *contents, unsigned char *e
   if (!check_image_size (f, *width, *height))
     {
       if (!inhibit_image_error)
-	image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+	image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       goto failure;
     }
   else if (data == NULL)
@@ -2936,13 +2936,13 @@ xbm_load_image (struct frame *f, struct image *img, unsigned char *contents,
       if (img->pixmap == NO_PIXMAP)
 	{
 	  x_clear_image (f, img);
-	  image_error ("Unable to create X pixmap for `%s'", img->spec, Qnil);
+	  image_error (u8"Unable to create X pixmap for ‘%s’", img->spec, Qnil);
 	}
       else
 	success_p = 1;
     }
   else
-    image_error ("Error loading XBM image `%s'", img->spec, Qnil);
+    image_error (u8"Error loading XBM image ‘%s’", img->spec, Qnil);
 
   return success_p;
 }
@@ -2983,14 +2983,14 @@ xbm_load (struct frame *f, struct image *img)
       file = x_find_image_file (file_name);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", file_name, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", file_name, Qnil);
 	  return 0;
 	}
 
       contents = slurp_file (SSDATA (file), &size);
       if (contents == NULL)
 	{
-	  image_error ("Error loading XBM image `%s'", img->spec, Qnil);
+	  image_error (u8"Error loading XBM image ‘%s’", img->spec, Qnil);
 	  return 0;
 	}
 
@@ -3025,7 +3025,7 @@ xbm_load (struct frame *f, struct image *img)
 	  eassert (img->width > 0 && img->height > 0);
 	  if (!check_image_size (f, img->width, img->height))
 	    {
-	      image_error ("Invalid image size (see `max-image-size')",
+	      image_error (u8"Invalid image size (see ‘max-image-size’)",
 			   Qnil, Qnil);
 	      return 0;
 	    }
@@ -3103,7 +3103,7 @@ xbm_load (struct frame *f, struct image *img)
 	    success_p = 1;
 	  else
 	    {
-	      image_error ("Unable to create pixmap for XBM image `%s'",
+	      image_error (u8"Unable to create pixmap for XBM image ‘%s’",
 			   img->spec, Qnil);
 	      x_clear_image (f, img);
 	    }
@@ -3626,7 +3626,7 @@ xpm_load (struct frame *f, struct image *img)
       Lisp_Object file = x_find_image_file (specified_file);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", specified_file, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", specified_file, Qnil);
 #ifdef ALLOC_XPM_COLORS
 	  xpm_free_color_cache ();
 #endif
@@ -3657,7 +3657,7 @@ xpm_load (struct frame *f, struct image *img)
       Lisp_Object buffer = image_spec_value (img->spec, QCdata, NULL);
       if (!STRINGP (buffer))
 	{
-	  image_error ("Invalid image data `%s'", buffer, Qnil);
+	  image_error (u8"Invalid image data ‘%s’", buffer, Qnil);
 #ifdef ALLOC_XPM_COLORS
 	  xpm_free_color_cache ();
 #endif
@@ -4101,7 +4101,7 @@ xpm_load_image (struct frame *f,
 
   if (!check_image_size (f, width, height))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       goto failure;
     }
 
@@ -4291,14 +4291,14 @@ xpm_load (struct frame *f,
       file = x_find_image_file (file_name);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", file_name, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", file_name, Qnil);
 	  return 0;
 	}
 
       contents = slurp_file (SSDATA (file), &size);
       if (contents == NULL)
 	{
-	  image_error ("Error loading XPM image `%s'", img->spec, Qnil);
+	  image_error (u8"Error loading XPM image ‘%s’", img->spec, Qnil);
 	  return 0;
 	}
 
@@ -4312,7 +4312,7 @@ xpm_load (struct frame *f,
       data = image_spec_value (img->spec, QCdata, NULL);
       if (!STRINGP (data))
 	{
-	  image_error ("Invalid image data `%s'", data, Qnil);
+	  image_error (u8"Invalid image data ‘%s’", data, Qnil);
 	  return 0;
 	}
       success_p = xpm_load_image (f, img, SDATA (data),
@@ -5266,14 +5266,14 @@ pbm_load (struct frame *f, struct image *img)
       file = x_find_image_file (specified_file);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", specified_file, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", specified_file, Qnil);
 	  return 0;
 	}
 
       contents = slurp_file (SSDATA (file), &size);
       if (contents == NULL)
 	{
-	  image_error ("Error reading `%s'", file, Qnil);
+	  image_error (u8"Error reading ‘%s’", file, Qnil);
 	  return 0;
 	}
 
@@ -5286,7 +5286,7 @@ pbm_load (struct frame *f, struct image *img)
       data = image_spec_value (img->spec, QCdata, NULL);
       if (!STRINGP (data))
 	{
-	  image_error ("Invalid image data `%s'", data, Qnil);
+	  image_error (u8"Invalid image data ‘%s’", data, Qnil);
 	  return 0;
 	}
       p = SDATA (data);
@@ -5296,7 +5296,7 @@ pbm_load (struct frame *f, struct image *img)
   /* Check magic number.  */
   if (end - p < 2 || *p++ != 'P')
     {
-      image_error ("Not a PBM image: `%s'", img->spec, Qnil);
+      image_error (u8"Not a PBM image: ‘%s’", img->spec, Qnil);
     error:
       xfree (contents);
       img->pixmap = NO_PIXMAP;
@@ -5330,7 +5330,7 @@ pbm_load (struct frame *f, struct image *img)
       break;
 
     default:
-      image_error ("Not a PBM image: `%s'", img->spec, Qnil);
+      image_error (u8"Not a PBM image: ‘%s’", img->spec, Qnil);
       goto error;
     }
 
@@ -5356,7 +5356,7 @@ pbm_load (struct frame *f, struct image *img)
 
   if (!check_image_size (f, width, height))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       goto error;
     }
 
@@ -5429,7 +5429,7 @@ pbm_load (struct frame *f, struct image *img)
 			x_destroy_x_image (ximg);
 #endif
 			x_clear_image (f, img);
-			image_error ("Invalid image size in image `%s'",
+			image_error (u8"Invalid image size in image ‘%s’",
 				     img->spec, Qnil);
 			goto error;
 		      }
@@ -5464,7 +5464,7 @@ pbm_load (struct frame *f, struct image *img)
 	  x_destroy_x_image (ximg);
 #endif
 	  x_clear_image (f, img);
-	  image_error ("Invalid image size in image `%s'",
+	  image_error (u8"Invalid image size in image ‘%s’",
 		       img->spec, Qnil);
 	  goto error;
 	}
@@ -5508,7 +5508,7 @@ pbm_load (struct frame *f, struct image *img)
 #else
 		x_destroy_x_image (ximg);
 #endif
-		image_error ("Invalid pixel value in image `%s'",
+		image_error (u8"Invalid pixel value in image ‘%s’",
 			     img->spec, Qnil);
 		goto error;
 	      }
@@ -5904,7 +5904,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
       file = x_find_image_file (specified_file);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", specified_file, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", specified_file, Qnil);
 	  return 0;
 	}
 
@@ -5912,7 +5912,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
       fp = emacs_fopen (SSDATA (file), "rb");
       if (!fp)
 	{
-	  image_error ("Cannot open image file `%s'", file, Qnil);
+	  image_error (u8"Cannot open image file ‘%s’", file, Qnil);
 	  return 0;
 	}
 
@@ -5921,7 +5921,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
 	  || png_sig_cmp (sig, 0, sizeof sig))
 	{
 	  fclose (fp);
-	  image_error ("Not a PNG file: `%s'", file, Qnil);
+	  image_error (u8"Not a PNG file: ‘%s’", file, Qnil);
 	  return 0;
 	}
     }
@@ -5929,7 +5929,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
     {
       if (!STRINGP (specified_data))
 	{
-	  image_error ("Invalid image data `%s'", specified_data, Qnil);
+	  image_error (u8"Invalid image data ‘%s’", specified_data, Qnil);
 	  return 0;
 	}
 
@@ -5942,7 +5942,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
       if (tbr.len < sizeof sig
 	  || png_sig_cmp (tbr.bytes, 0, sizeof sig))
 	{
-	  image_error ("Not a PNG image: `%s'", img->spec, Qnil);
+	  image_error (u8"Not a PNG image: ‘%s’", img->spec, Qnil);
 	  return 0;
 	}
 
@@ -6010,7 +6010,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
   if (! (width <= INT_MAX && height <= INT_MAX
 	 && check_image_size (f, width, height)))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       goto error;
     }
 
@@ -6668,20 +6668,20 @@ jpeg_load_body (struct frame *f, struct image *img,
       file = x_find_image_file (specified_file);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", specified_file, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", specified_file, Qnil);
 	  return 0;
 	}
 
       fp = emacs_fopen (SSDATA (file), "rb");
       if (fp == NULL)
 	{
-	  image_error ("Cannot open `%s'", file, Qnil);
+	  image_error (u8"Cannot open ‘%s’", file, Qnil);
 	  return 0;
 	}
     }
   else if (!STRINGP (specified_data))
     {
-      image_error ("Invalid image data `%s'", specified_data, Qnil);
+      image_error (u8"Invalid image data ‘%s’", specified_data, Qnil);
       return 0;
     }
 
@@ -6697,13 +6697,13 @@ jpeg_load_body (struct frame *f, struct image *img,
 	  {
 	    char buf[JMSG_LENGTH_MAX];
 	    mgr->cinfo.err->format_message ((j_common_ptr) &mgr->cinfo, buf);
-	    image_error ("Error reading JPEG image `%s': %s", img->spec,
+	    image_error (u8"Error reading JPEG image ‘%s’: %s", img->spec,
 			 build_string (buf));
 	    break;
 	  }
 
 	case MY_JPEG_INVALID_IMAGE_SIZE:
-	  image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+	  image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
 	  break;
 
 	case MY_JPEG_CANNOT_CREATE_X:
@@ -7183,7 +7183,7 @@ tiff_load (struct frame *f, struct image *img)
       file = x_find_image_file (specified_file);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", specified_file, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", specified_file, Qnil);
 	  return 0;
 	}
 # ifdef WINDOWSNT
@@ -7194,7 +7194,7 @@ tiff_load (struct frame *f, struct image *img)
       tiff = TIFFOpen (SSDATA (file), "r");
       if (tiff == NULL)
 	{
-	  image_error ("Cannot open `%s'", file, Qnil);
+	  image_error (u8"Cannot open ‘%s’", file, Qnil);
 	  return 0;
 	}
     }
@@ -7202,7 +7202,7 @@ tiff_load (struct frame *f, struct image *img)
     {
       if (!STRINGP (specified_data))
 	{
-	  image_error ("Invalid image data `%s'", specified_data, Qnil);
+	  image_error (u8"Invalid image data ‘%s’", specified_data, Qnil);
 	  return 0;
 	}
 
@@ -7222,7 +7222,7 @@ tiff_load (struct frame *f, struct image *img)
 
       if (!tiff)
 	{
-	  image_error ("Cannot open memory source for `%s'", img->spec, Qnil);
+	  image_error (u8"Cannot open memory source for ‘%s’", img->spec, Qnil);
 	  return 0;
 	}
     }
@@ -7234,7 +7234,7 @@ tiff_load (struct frame *f, struct image *img)
       if (! (TYPE_MINIMUM (tdir_t) <= ino && ino <= TYPE_MAXIMUM (tdir_t)
 	     && TIFFSetDirectory (tiff, ino)))
 	{
-	  image_error ("Invalid image number `%s' in image `%s'",
+	  image_error (u8"Invalid image number ‘%s’ in image ‘%s’",
 		       image, img->spec);
 	  TIFFClose (tiff);
 	  return 0;
@@ -7248,7 +7248,7 @@ tiff_load (struct frame *f, struct image *img)
 
   if (!check_image_size (f, width, height))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       TIFFClose (tiff);
       return 0;
     }
@@ -7278,7 +7278,7 @@ tiff_load (struct frame *f, struct image *img)
   TIFFClose (tiff);
   if (!rc)
     {
-      image_error ("Error reading TIFF image `%s'", img->spec, Qnil);
+      image_error (u8"Error reading TIFF image ‘%s’", img->spec, Qnil);
       xfree (buf);
       return 0;
     }
@@ -7615,7 +7615,7 @@ gif_load (struct frame *f, struct image *img)
       file = x_find_image_file (specified_file);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", specified_file, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", specified_file, Qnil);
 	  return 0;
 	}
 #ifdef WINDOWSNT
@@ -7627,14 +7627,14 @@ gif_load (struct frame *f, struct image *img)
       gif = DGifOpenFileName (SSDATA (file));
       if (gif == NULL)
 	{
-	  image_error ("Cannot open `%s'", file, Qnil);
+	  image_error (u8"Cannot open ‘%s’", file, Qnil);
 	  return 0;
 	}
 #else
       gif = DGifOpenFileName (SSDATA (file), &gif_err);
       if (gif == NULL)
 	{
-	  image_error ("Cannot open `%s': %s",
+	  image_error (u8"Cannot open ‘%s’: %s",
 		       file, build_string (GifErrorString (gif_err)));
 	  return 0;
 	}
@@ -7644,7 +7644,7 @@ gif_load (struct frame *f, struct image *img)
     {
       if (!STRINGP (specified_data))
 	{
-	  image_error ("Invalid image data `%s'", specified_data, Qnil);
+	  image_error (u8"Invalid image data ‘%s’", specified_data, Qnil);
 	  return 0;
 	}
 
@@ -7658,14 +7658,14 @@ gif_load (struct frame *f, struct image *img)
       gif = DGifOpen (&memsrc, gif_read_from_memory);
       if (!gif)
 	{
-	  image_error ("Cannot open memory source `%s'", img->spec, Qnil);
+	  image_error (u8"Cannot open memory source ‘%s’", img->spec, Qnil);
 	  return 0;
 	}
 #else
       gif = DGifOpen (&memsrc, gif_read_from_memory, &gif_err);
       if (!gif)
 	{
-	  image_error ("Cannot open memory source `%s': %s",
+	  image_error (u8"Cannot open memory source ‘%s’: %s",
 		       img->spec, build_string (GifErrorString (gif_err)));
 	  return 0;
 	}
@@ -7675,7 +7675,7 @@ gif_load (struct frame *f, struct image *img)
   /* Before reading entire contents, check the declared image size. */
   if (!check_image_size (f, gif->SWidth, gif->SHeight))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       gif_close (gif, NULL);
       return 0;
     }
@@ -7684,7 +7684,7 @@ gif_load (struct frame *f, struct image *img)
   rc = DGifSlurp (gif);
   if (rc == GIF_ERROR || gif->ImageCount <= 0)
     {
-      image_error ("Error reading `%s'", img->spec, Qnil);
+      image_error (u8"Error reading ‘%s’", img->spec, Qnil);
       gif_close (gif, NULL);
       return 0;
     }
@@ -7695,7 +7695,7 @@ gif_load (struct frame *f, struct image *img)
     idx = INTEGERP (image_number) ? XFASTINT (image_number) : 0;
     if (idx < 0 || idx >= gif->ImageCount)
       {
-	image_error ("Invalid image number `%s' in image `%s'",
+	image_error (u8"Invalid image number ‘%s’ in image ‘%s’",
 		     image_number, img->spec);
 	gif_close (gif, NULL);
 	return 0;
@@ -7714,7 +7714,7 @@ gif_load (struct frame *f, struct image *img)
 
   if (!check_image_size (f, width, height))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       gif_close (gif, NULL);
       return 0;
     }
@@ -7968,10 +7968,10 @@ gif_load (struct frame *f, struct image *img)
       char *error_text = GifErrorString (gif_err);
 
       if (error_text)
-	image_error ("Error closing `%s': %s",
+	image_error (u8"Error closing ‘%s’: %s",
 		     img->spec, build_string (error_text));
 #else
-      image_error ("Error closing `%s'", img->spec, Qnil);
+      image_error (u8"Error closing ‘%s’", img->spec, Qnil);
 #endif
     }
 
@@ -8516,7 +8516,7 @@ imagemagick_load_image (struct frame *f, struct image *img,
 
   if (ino < 0 || ino >= MagickGetNumberImages (image_wand))
     {
-      image_error ("Invalid image number `%s' in image `%s'",
+      image_error (u8"Invalid image number ‘%s’ in image ‘%s’",
 		   image, img->spec);
       DestroyMagickWand (image_wand);
       return 0;
@@ -8651,7 +8651,7 @@ imagemagick_load_image (struct frame *f, struct image *img,
   if (! (image_width <= INT_MAX && image_height <= INT_MAX
 	 && check_image_size (f, image_width, image_height)))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       goto imagemagick_error;
     }
 
@@ -8787,7 +8787,7 @@ imagemagick_load_image (struct frame *f, struct image *img,
 
   MagickWandTerminus ();
   /* TODO more cleanup.  */
-  image_error ("Error parsing IMAGEMAGICK image `%s'", img->spec, Qnil);
+  image_error (u8"Error parsing IMAGEMAGICK image ‘%s’", img->spec, Qnil);
   return 0;
 }
 
@@ -8811,7 +8811,7 @@ imagemagick_load (struct frame *f, struct image *img)
       file = x_find_image_file (file_name);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", file_name, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", file_name, Qnil);
 	  return 0;
 	}
 #ifdef WINDOWSNT
@@ -8828,7 +8828,7 @@ imagemagick_load (struct frame *f, struct image *img)
       data = image_spec_value (img->spec, QCdata, NULL);
       if (!STRINGP (data))
 	{
-	  image_error ("Invalid image data `%s'", data, Qnil);
+	  image_error (u8"Invalid image data ‘%s’", data, Qnil);
 	  return 0;
 	}
       success_p = imagemagick_load_image (f, img, SDATA (data),
@@ -9092,7 +9092,7 @@ svg_load (struct frame *f, struct image *img)
       file = x_find_image_file (file_name);
       if (!STRINGP (file))
 	{
-	  image_error ("Cannot find image file `%s'", file_name, Qnil);
+	  image_error (u8"Cannot find image file ‘%s’", file_name, Qnil);
 	  return 0;
 	}
 
@@ -9100,7 +9100,7 @@ svg_load (struct frame *f, struct image *img)
       contents = slurp_file (SSDATA (file), &size);
       if (contents == NULL)
 	{
-	  image_error ("Error loading SVG image `%s'", img->spec, Qnil);
+	  image_error (u8"Error loading SVG image ‘%s’", img->spec, Qnil);
 	  return 0;
 	}
       /* If the file was slurped into memory properly, parse it.  */
@@ -9116,7 +9116,7 @@ svg_load (struct frame *f, struct image *img)
       data = image_spec_value (img->spec, QCdata, NULL);
       if (!STRINGP (data))
 	{
-	  image_error ("Invalid image data `%s'", data, Qnil);
+	  image_error (u8"Invalid image data ‘%s’", data, Qnil);
 	  return 0;
 	}
       original_filename = BVAR (current_buffer, filename);
@@ -9183,7 +9183,7 @@ svg_load_image (struct frame *f,         /* Pointer to emacs frame structure.  *
   rsvg_handle_get_dimensions (rsvg_handle, &dimension_data);
   if (! check_image_size (f, dimension_data.width, dimension_data.height))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       goto rsvg_error;
     }
 
@@ -9315,7 +9315,7 @@ svg_load_image (struct frame *f,         /* Pointer to emacs frame structure.  *
   g_object_unref (rsvg_handle);
   /* FIXME: Use error->message so the user knows what is the actual
      problem with the image.  */
-  image_error ("Error parsing SVG image `%s'", img->spec, Qnil);
+  image_error (u8"Error parsing SVG image ‘%s’", img->spec, Qnil);
   g_error_free (err);
   return 0;
 }
@@ -9468,7 +9468,7 @@ gs_load (struct frame *f, struct image *img)
   if (! (in_width <= INT_MAX && in_height <= INT_MAX
 	 && check_image_size (f, in_width, in_height)))
     {
-      image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+      image_error (u8"Invalid image size (see ‘max-image-size’)", Qnil, Qnil);
       return 0;
     }
   img->width = in_width;
@@ -9489,7 +9489,7 @@ gs_load (struct frame *f, struct image *img)
 
   if (!img->pixmap)
     {
-      image_error ("Unable to create pixmap for `%s'", img->spec, Qnil);
+      image_error (u8"Unable to create pixmap for ‘%s’", img->spec, Qnil);
       return 0;
     }
 
@@ -9601,7 +9601,7 @@ x_kill_gs_process (Pixmap pixmap, struct frame *f)
 #endif
 	}
       else
-	image_error ("Cannot get X image of `%s'; colors will not be freed",
+	image_error (u8"Cannot get X image of ‘%s’; colors will not be freed",
 		     img->spec, Qnil);
 
       unblock_input ();
diff --git a/src/keymap.c b/src/keymap.c
index 8f4ac0d..6e370a4 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -770,7 +770,7 @@ store_in_keymap (Lisp_Object keymap, register Lisp_Object idx, Lisp_Object def)
   where_is_cache_keymaps = Qt;
 
   if (EQ (idx, Qkeymap))
-    error ("`keymap' is reserved for embedded parent maps");
+    error (u8"‘keymap’ is reserved for embedded parent maps");
 
   /* If we are preparing to dump, and DEF is a menu element
      with a menu item indicator, copy it to ensure it is not pure.  */
@@ -2858,7 +2858,7 @@ You type        Translation\n\
       if (!NILP (start1))
 	{
 	  describe_map_tree (start1, 1, shadow, prefix,
-			     "\f\n`keymap' Property Bindings", nomenu,
+			     u8"\f\n‘keymap’ Property Bindings", nomenu,
 			     0, 0, 0);
 	  shadow = Fcons (start1, shadow);
 	}
@@ -2903,7 +2903,7 @@ You type        Translation\n\
 			       "\f\nMajor Mode Bindings", nomenu, 0, 0, 0);
 	  else
 	    describe_map_tree (start1, 1, shadow, prefix,
-			       "\f\n`local-map' Property Bindings",
+			       u8"\f\n‘local-map’ Property Bindings",
 			       nomenu, 0, 0, 0);
 
 	  shadow = Fcons (start1, shadow);
diff --git a/src/lisp.h b/src/lisp.h
index 198f116..82d5f8f 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -156,6 +156,13 @@ typedef EMACS_UINT uprintmax_t;
 # define pMu pI"u"
 #endif
 
+/* UTF-8 sequences for U+2018 LEFT SINGLE QUOTATION MARK and U+2019
+   RIGHT SINGLE QUOTATION MARK.  These may be useful in string
+   literals that use pI and similar macros, since these literals
+   cannot also portably use the u8 encoding prefix.  */
+#define uLSQM "\xE2\x80\x98"
+#define uRSQM "\xE2\x80\x99"
+
 /* Use pD to format ptrdiff_t values, which suffice for indexes into
    buffers and strings.  Emacs never allocates objects larger than
    PTRDIFF_MAX bytes, as they cause problems with pointer subtraction.
diff --git a/src/lread.c b/src/lread.c
index 11c8d00..5402494 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -947,7 +947,7 @@ load_warn_old_style_backquotes (Lisp_Object file)
 {
   if (!NILP (Vold_style_backquotes))
     {
-      AUTO_STRING (format, "Loading `%s': old-style backquotes detected!");
+      AUTO_STRING (format, u8"Loading ‘%s’: old-style backquotes detected!");
       CALLN (Fmessage, format, file);
     }
 }
@@ -1211,9 +1211,9 @@ Return t if the file exists and loads successfully.  */)
 	    {
 	      safe_p = 0;
 	      if (!load_dangerous_libraries)
-		error ("File `%s' was not compiled in Emacs", SDATA (found));
+		error (u8"File ‘%s’ was not compiled in Emacs", SDATA (found));
 	      else if (!NILP (nomessage) && !force_load_messages)
-		message_with_string ("File `%s' not compiled in Emacs", found, 1);
+		message_with_string (u8"File ‘%s’ not compiled in Emacs", found, 1);
 	    }
 
 	  compiled = 1;
@@ -1245,7 +1245,7 @@ Return t if the file exists and loads successfully.  */)
                     {
                       Lisp_Object msg_file;
                       msg_file = Fsubstring (found, make_number (0), make_number (-1));
-                      message_with_string ("Source file `%s' newer than byte-compiled file",
+                      message_with_string (u8"Source file ‘%s’ newer than byte-compiled file",
                                            msg_file, 1);
                     }
                 }
diff --git a/src/nsfns.m b/src/nsfns.m
index 6a2e2ff..264e53b 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -1948,7 +1948,7 @@ The optional argument FRAME is currently ignored.  */)
     {
       CHECK_FRAME (frame);
       if (! FRAME_NS_P (XFRAME (frame)))
-        error ("non-Nextstep frame used in `ns-list-colors'");
+        error (u8"non-Nextstep frame used in ‘ns-list-colors’");
     }
 
   block_input ();
diff --git a/src/regex.c b/src/regex.c
index 38c5e35..dcf2864 100644
--- a/src/regex.c
+++ b/src/regex.c
@@ -1544,9 +1544,9 @@ do {									\
   DEBUG_PRINT ("  Push frame index: %zd\n", fail_stack.frame);		\
   PUSH_FAILURE_INT (fail_stack.frame);					\
   									\
-  DEBUG_PRINT ("  Push string %p: `", string_place);			\
+  DEBUG_PRINT ("  Push string %p: \"", string_place);			\
   DEBUG_PRINT_DOUBLE_STRING (string_place, string1, size1, string2, size2);\
-  DEBUG_PRINT ("'\n");							\
+  DEBUG_PRINT ("\"\n");							\
   PUSH_FAILURE_POINTER (string_place);					\
   									\
   DEBUG_PRINT ("  Push pattern %p: ", pattern);				\
@@ -1598,9 +1598,9 @@ do {									\
      on_failure_keep_string_jump opcode, and we want to throw away the	\
      saved NULL, thus retaining our current position in the string.  */	\
   str = POP_FAILURE_POINTER ();						\
-  DEBUG_PRINT ("  Popping string %p: `", str);				\
+  DEBUG_PRINT ("  Popping string %p: \"", str);				\
   DEBUG_PRINT_DOUBLE_STRING (str, string1, size1, string2, size2);	\
-  DEBUG_PRINT ("'\n");							\
+  DEBUG_PRINT ("\"\n");							\
 									\
   fail_stack.frame = POP_FAILURE_INT ();				\
   DEBUG_PRINT ("  Popping  frame index: %zd\n", fail_stack.frame);	\
@@ -5127,9 +5127,9 @@ re_match_2_internal (struct re_pattern_buffer *bufp, const_re_char *string1,
 
   DEBUG_PRINT ("The compiled pattern is: ");
   DEBUG_PRINT_COMPILED_PATTERN (bufp, p, pend);
-  DEBUG_PRINT ("The string to match is: `");
+  DEBUG_PRINT ("The string to match is: \"");
   DEBUG_PRINT_DOUBLE_STRING (d, string1, size1, string2, size2);
-  DEBUG_PRINT ("'\n");
+  DEBUG_PRINT ("\"\n");
 
   /* This loops over pattern commands.  It exits by returning from the
      function if the match is complete, or it drops through if the match
@@ -5435,7 +5435,7 @@ re_match_2_internal (struct re_pattern_buffer *bufp, const_re_char *string1,
 		    && buf_ch == '\000'))
 	      goto fail;
 
-	    DEBUG_PRINT ("  Matched `%d'.\n", *d);
+	    DEBUG_PRINT ("  Matched \"%d\".\n", *d);
 	    d += buf_charlen;
 	  }
 	  break;
diff --git a/src/search.c b/src/search.c
index 5da99c4..5a6549e 100644
--- a/src/search.c
+++ b/src/search.c
@@ -2346,7 +2346,7 @@ since only regular expressions have distinguished subexpressions.  */)
 				/* but some C compilers blew it */
 
   if (search_regs.num_regs <= 0)
-    error ("`replace-match' called before any match found");
+    error (u8"‘replace-match’ called before any match found");
 
   if (NILP (subexp))
     sub = 0;
@@ -2510,7 +2510,7 @@ since only regular expressions have distinguished subexpressions.  */)
 		  else if (c == '\\')
 		    delbackslash = 1;
 		  else if (c != '?')
-		    error ("Invalid use of `\\' in replacement text");
+		    error (u8"Invalid use of ‘\\’ in replacement text");
 		}
 	      if (substart >= 0)
 		{
@@ -2642,7 +2642,7 @@ since only regular expressions have distinguished subexpressions.  */)
 	      else
 		{
 		  xfree (substed);
-		  error ("Invalid use of `\\' in replacement text");
+		  error (u8"Invalid use of ‘\\’ in replacement text");
 		}
 	    }
 	  else
diff --git a/src/syntax.c b/src/syntax.c
index 1695815..02c4137 100644
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -1333,7 +1333,7 @@ DEFUN ("internal-describe-syntax-value", Finternal_describe_syntax_value,
     insert_string (" (nestable)");
 
   if (prefix)
-    insert_string (",\n\t  is a prefix character for `backward-prefix-chars'");
+    insert_string (u8",\n\t  is a prefix character for ‘backward-prefix-chars’");
 
   return syntax;
 }
diff --git a/src/sysdep.c b/src/sysdep.c
index 0a0b0ac..58dc40a 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -2592,7 +2592,7 @@ serial_configure (struct Lisp_Process *p,
   else
     tem = Fplist_get (p->childp, QCparity);
   if (!NILP (tem) && !EQ (tem, Qeven) && !EQ (tem, Qodd))
-    error (":parity must be nil (no parity), `even', or `odd'");
+    error (u8":parity must be nil (no parity), ‘even’, or ‘odd’");
 #if defined (PARENB) && defined (PARODD) && defined (IGNPAR) && defined (INPCK)
   attr.c_cflag &= ~(PARENB | PARODD);
   attr.c_iflag &= ~(IGNPAR | INPCK);
@@ -2647,7 +2647,7 @@ serial_configure (struct Lisp_Process *p,
   else
     tem = Fplist_get (p->childp, QCflowcontrol);
   if (!NILP (tem) && !EQ (tem, Qhw) && !EQ (tem, Qsw))
-    error (":flowcontrol must be nil (no flowcontrol), `hw', or `sw'");
+    error (u8":flowcontrol must be nil (no flowcontrol), ‘hw’, or ‘sw’");
 #if defined (CRTSCTS)
   attr.c_cflag &= ~CRTSCTS;
 #endif
diff --git a/src/w32.c b/src/w32.c
index 8721ed9..36f9808 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -9391,7 +9391,7 @@ serial_configure (struct Lisp_Process *p, Lisp_Object contact)
   else
     tem = Fplist_get (p->childp, QCparity);
   if (!NILP (tem) && !EQ (tem, Qeven) && !EQ (tem, Qodd))
-    error (":parity must be nil (no parity), `even', or `odd'");
+    error (u8":parity must be nil (no parity), ‘even’, or ‘odd’");
   dcb.fParity = FALSE;
   dcb.Parity = NOPARITY;
   dcb.fErrorChar = FALSE;
@@ -9438,7 +9438,7 @@ serial_configure (struct Lisp_Process *p, Lisp_Object contact)
   else
     tem = Fplist_get (p->childp, QCflowcontrol);
   if (!NILP (tem) && !EQ (tem, Qhw) && !EQ (tem, Qsw))
-    error (":flowcontrol must be nil (no flowcontrol), `hw', or `sw'");
+    error (u8":flowcontrol must be nil (no flowcontrol), ‘hw’, or ‘sw’");
   dcb.fOutxCtsFlow	= FALSE;
   dcb.fOutxDsrFlow	= FALSE;
   dcb.fDtrControl	= DTR_CONTROL_DISABLE;
diff --git a/src/window.c b/src/window.c
index ad5ac79..24d7c14 100644
--- a/src/window.c
+++ b/src/window.c
@@ -432,7 +432,7 @@ Return WINDOW.  */)
   CHECK_LIVE_WINDOW (window);
 
   if (! EQ (frame, WINDOW_FRAME (XWINDOW (window))))
-    error ("In `set-frame-selected-window', WINDOW is not on FRAME");
+    error (u8"In ‘set-frame-selected-window’, WINDOW is not on FRAME");
 
   if (EQ (frame, selected_frame))
     return Fselect_window (window, norecord);
@@ -3521,7 +3521,7 @@ This function runs `window-scroll-functions' before running
 	  if (EQ (w->dedicated, Qt))
 	    /* WINDOW is strongly dedicated to its buffer, signal an
 	       error.  */
-	    error ("Window is dedicated to `%s'", SDATA (BVAR (XBUFFER (tem), name)));
+	    error (u8"Window is dedicated to ‘%s’", SDATA (BVAR (XBUFFER (tem), name)));
 	  else
 	    /* WINDOW is weakly dedicated to its buffer, reset
 	       dedication.  */
@@ -5755,7 +5755,7 @@ and redisplay normally--don't erase and redraw the frame.  */)
   int this_scroll_margin;
 
   if (buf != current_buffer)
-    error ("`recenter'ing a window that does not display current-buffer.");
+    error (u8"‘recenter’ing a window that does not display current-buffer.");
 
   /* If redisplay is suppressed due to an error, try again.  */
   buf->display_error_modiff = 0;
diff --git a/src/xfaces.c b/src/xfaces.c
index f0b6d39..a7c74bf 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -797,7 +797,7 @@ load_pixmap (struct frame *f, Lisp_Object name)
 
   if (bitmap_id < 0)
     {
-      add_to_log ("Invalid or undefined bitmap `%s'", name, Qnil);
+      add_to_log (u8"Invalid or undefined bitmap ‘%s’", name, Qnil);
       bitmap_id = 0;
     }
   else
-- 
2.1.0

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

In article <mailman.4052.1433144480.904.bug-gnu-emacs@gnu.org> you wrote:
> Quote with curved single quotes, ?like this?, in diagnostics
> generated from C code.  This mostly uses C11-style UTF-8 strings,
> e.g., u8"quote ?like this?", with a backward compatibility macro
> u8 for pre-C11 compilers.

Must we?  It is a very clever thing to be able to do, but just because we
can doesn't mean we must, or even should.

Currently, we can grep C source code (whether on the command line or
within Emacs), specifically specifying quote characters like " (even if
they have to be escaped).  With this patch, this ability will disappear.
OK, there may be some arcane way of specifying these curly quotes, but
somebody like me will have to refer to documentation each time they need
it, since it will be used seldomly enough in comparison to its complexity
that it won't stay memorised.  This is a significant loss.

Curly quotes display as ? on my terminal, sometimes inverted.  This looks
horrible, and is much worse than ", `, and '.  OK, there may be, there
probably is, a way of modifying this terminal to be able to display these
characters, but that's a lot of work, and that work will be multiplied by
the number of people using Emacs on a terminal, not all of whom will be
able to fix it, or have the time to fix it.

And all for what?  So that we can look "more modern" on some display
environments?

At the very least, can you not make curly quoting a configuration option,
something like --with-curly-quotes?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/01/2015 03:49 AM, Alan Mackenzie wrote:
> Currently, we can grep C source code (whether on the command line or
> within Emacs), specifically specifying quote characters like " (even if
> they have to be escaped).

Having just gone through this exercise, I can say that it doesn't work 
as well as I had hoped.  Characters are sometimes escaped, sometimes 
not, and even something easy like searching for '`' finds many false 
hits in comments.

> OK, there may be some arcane way of specifying these curly quotes

Hmm, well, it's not arcane for me.  This shell command:

    grep ‘ *.c

generates all .c lines that contain left single quotation mark in a 
string (after the proposed patch is applied).  This is simpler than any 
shell command to find apostrophe or double-quote or grave accent.

> Curly quotes display as ? on my terminal, sometimes inverted.

That's not good.  What terminal are you using, and why does it not 
handle UTF-8?  What is your operating system and locale settings? If 
this is a common problem among Emacs developers, I suppose we'll have to 
come up with a different way.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Mon, Jun 01, 2015 at 09:01:08AM -0700, Paul Eggert wrote:
> On 06/01/2015 03:49 AM, Alan Mackenzie wrote:
> > Currently, we can grep C source code (whether on the command line or
> > within Emacs), specifically specifying quote characters like " (even if
> > they have to be escaped).

> Having just gone through this exercise, I can say that it doesn't work 
> as well as I had hoped.  Characters are sometimes escaped, sometimes 
> not, and even something easy like searching for '`' finds many false 
> hits in comments.

> > OK, there may be some arcane way of specifying these curly quotes

> Hmm, well, it's not arcane for me.  This shell command:

>     grep ‘ *.c

That begs the question how do you type that left curly quote.  I have no
way of doing so on my keyboard.  Having to memorise a 4 digit hex value
would count as arcane for me.

In mutt, that curly quote displays as `.  However, searching for the
ASCII back tick (correctly) fails to find it.  This is disconcerting.
Dumping the text to a file, visiting that file in Emacs and C-u C-x =
shows the character to be LEFT SINGLE QUOTATION MARK, 0x2018.

> generates all .c lines that contain left single quotation mark in a 
> string (after the proposed patch is applied).  This is simpler than any 
> shell command to find apostrophe or double-quote or grave accent.

> > Curly quotes display as ? on my terminal, sometimes inverted.

> That's not good.  What terminal are you using, and why does it not 
> handle UTF-8?

I use the Linux virtual terminal:

    $TERM = linux
    consolefont="lat1-16"

It doesn't handle UTF-8, because I never put in the effort to make it do
so.  Looking at the available fonts in /usr/share/consolefonts, there
isn't one whose name looks like "utf" or "uni", except for four with
names beginning with "UniCyr", which probably means something like "UTF
Cyrillic".

> What is your operating system and locale settings?

(Gentoo) GNU/Linux with:

    $LANG = en_GB.utf8

, none of the LC_ variables being set.

> If this is a common problem among Emacs developers, I suppose we'll
> have to come up with a different way.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/01/2015 10:17 AM, Alan Mackenzie wrote:
> how do you type that left curly quote.

In the new Electric Quote minor mode you can type just ` for the typical 
case.  Outside Electric Quote, you can type C-x 8 ` (or A-` if your Alt 
key is working).  Except for A-` this all should work on any keyboard.  
You don't need to memorize a 4 digit hex value (I can never remember it 
myself).

>  However, searching for the ASCII back tick (correctly) fails to find 
> it. This is disconcerting.

It may be disconcerting at first, but it's easy to get used to and it 
has advantages, e.g., it provides finer-grained control over searching.  
Where I want to find a left single quote of either style, I can do a 
regexp search for "[`‘]" but in interactive usage this is rare, at least 
for me.

> I use the Linux virtual terminal: $TERM = linux consolefont="lat1-16" 
> It doesn't handle UTF-8, because I never put in the effort to make it 
> do so.

According to <https://wiki.gentoo.org/wiki/UTF-8#The_system_console> it 
should work if you have sys-apps/baselayout 
<http://packages.gentoo.org/package/sys-apps/baselayout> 1.11.9 or 
higher installed, have unicode="yes" in /etc/rc.conf, and specify e.g. 
keymap="uk" in /etc/conf.d/keymaps.  The console font lat9w-16 seems to 
be reasonably popular, so you might try that. UTF-8 works out of the box 
in Ubuntu and Fedora on the system console; I don't use Gentoo but it 
shouldn't be a lot of trouble to get it to work there too.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello again, Paul.

On Mon, Jun 01, 2015 at 11:50:36AM -0700, Paul Eggert wrote:
> On 06/01/2015 10:17 AM, Alan Mackenzie wrote:
> > how do you type that left curly quote.

> In the new Electric Quote minor mode you can type just ` for the typical 
> case.  Outside Electric Quote, you can type C-x 8 ` (or A-` if your Alt 
> key is working).  Except for A-` this all should work on any keyboard.  
> You don't need to memorize a 4 digit hex value (I can never remember it 
> myself).

Yes, that's fine.  It's only marginally more difficult to type this
within Emacs than for other self-inserting characters, though this
difference prevents these curly-quotes from being first class characters.

What I really meant with my question is how do you type curly characters
when outwith Emacs?  Say, inside of less, or at a bash shell prompt, or
in any of numerous other tools one might wish to use?

The only answer I can conceive of involves the enhancing of keyboard
layouts.  That's several hours of work.

> >  However, searching for the ASCII back tick (correctly) fails to find 
> > it. This is disconcerting.

> It may be disconcerting at first, but it's easy to get used to and it 
> has advantages, e.g., it provides finer-grained control over searching.  
> Where I want to find a left single quote of either style, I can do a 
> regexp search for "[`‘]" but in interactive usage this is rare, at least 
> for me.

But it's yet another trivial annoyance that one has to heep onto all the
other y-a-t-as we have to cope with every day.

> > I use the Linux virtual terminal: $TERM = linux consolefont="lat1-16" 
> > It doesn't handle UTF-8, because I never put in the effort to make it 
> > do so.

> According to <https://wiki.gentoo.org/wiki/UTF-8#The_system_console> it 
> should work if you have sys-apps/baselayout 
> <http://packages.gentoo.org/package/sys-apps/baselayout> 1.11.9 or 
> higher installed, have unicode="yes" in /etc/rc.conf, and specify e.g. 
> keymap="uk" in /etc/conf.d/keymaps.  The console font lat9w-16 seems to 
> be reasonably popular, so you might try that. UTF-8 works out of the box 
> in Ubuntu and Fedora on the system console; I don't use Gentoo but it 
> shouldn't be a lot of trouble to get it to work there too.

<Sigh>.  I've had a look at these instructions.  There's a lot of glib
handwaving on them, like "Do <this> and read the comments".  There's not
a recipe on that page, for the simple reason that the process is too
complicated.  It says nothing about, for example, what consoletranslation
or unicodemap to select, whatever these things might be.  It gives a font
which "seems to be reasonably popular", without saying anything about it:
which characters it displays, for example.  I'm not familiar with font
manipulating software; I'd have to find some.

Yes, all these things are doable - I've done them before, and it took
several days (I kept notes).  Maybe it would only take several hours this
time.

But I come back to the point.  Why start using these curly characters at
all?  I put it to you you're fixing what isn't broken.  One of Emacs's
strong points has always been its working in pretty much any environment.
You're going to slightly improve what these things look like in some
display environments at the cost of slight inconvenience all round.  What
we currently have works, works well, and has done for decades.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Drew Adams]

> But I come back to the point.  Why start using these curly
> characters at all?  I put it to you you're fixing what
> isn't broken.
>
> One of Emacs's strong points has always been its working
> in pretty much any environment.  You're going to slightly
> improve what these things look like in some display
> environments at the cost of slight inconvenience all
> round. What we currently have works, works well, and has
> done for decades.

+1.  So that makes two of us.  (Whoopee.)

Unfortunately, our dear leader has opted to follow down this
rabbit hole, under the delusory banner of "Modernization".

Perhaps in a decade or two someone will have the brilliant
eureka of introducing an easy-to-type, unambiguous convention
for distinguishing code from ordinary text, including from
quotations.  For example, enclosing it in `...'.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

Alan Mackenzie wrote:

> What I really meant with my question is how do you type curly characters
> when outwith Emacs?  Say, inside of less, or at a bash shell prompt, or
> in any of numerous other tools one might wish to use?

It doesn't come up that often, but for 'less' I am typically searching and 
searching for '.' will do -- I sometimes do that even for ASCII-only searches, 
as '.' is easier to type than, say, '\'.  I typically run Bash under Emacs where 
it's not a problem there either.

In the rarer cases where I'm outside Emacs or want to search just for curved 
quotes and nothing else, I can type Compose < ' and Compose > ' to get curved 
single quotes.  On my current keyboard, the Compose key looks like a menu and is 
just to the right of the right Alt key; this is the default setup that came with 
Ubuntu 15.04.  I'm sure one can get the Compose key to work on the Linux console 
too, as plenty of people need to type accented letters on the Linux console.

> it's yet another trivial annoyance that one has to heep onto all

Heh.  Trivial annoyances are what motivated this change.  I've been trivially 
annoyed at Emacs quoting `like this' for at least a decade.  Nearly every other 
GNU package has fixed it.  I was hoping Somebody Else would fix it for Emacs, 
but nobody ever stepped up so here we are.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Dmitry Gutov]

On 06/02/2015 06:39 PM, Paul Eggert wrote:

> Nearly every other GNU package has fixed it.  I was hoping Somebody Else
> would fix it for Emacs, but nobody ever stepped up so here we are.

GCC outputs curly quotes, but doesn't use them in the source code. So 
that's still an option.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/02/2015 08:51 AM, Dmitry Gutov wrote:
> GCC outputs curly quotes, but doesn't use them in the source code. So 
> that's still an option. 

Yes, and the changes installed into the master preserve that option for 
Emacs as well.  Eventually we should move away from the idea of quoting 
`like this' in the source code with the understanding that the quotes 
are transliterated for the user, as in the long run that'll be one more 
annoying thing to deal with, but in the meantime it's a reasonable 
transition strategy to stick with ASCII-only formats in diagnostics.

In this sense, the patch proposed in Bug#20707 goes too far, as it would 
require either curved quotes in C source strings, or ugly 
circumlocutions like "Error: "uLSQ"%s"uRSQ" is invalid" in place of 
"Error: ‘%s’ is invalid".  So I plan to draft a different approach that 
will be more like what GCC does.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Tue, Jun 02, 2015 at 08:39:34AM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:

> > What I really meant with my question is how do you type curly characters
> > when outwith Emacs?  Say, inside of less, or at a bash shell prompt, or
> > in any of numerous other tools one might wish to use?

> It doesn't come up that often, but for 'less' I am typically searching and 
> searching for '.' will do -- I sometimes do that even for ASCII-only searches, 
> as '.' is easier to type than, say, '\'.  I typically run Bash under Emacs where 
> it's not a problem there either.

> In the rarer cases where I'm outside Emacs or want to search just for curved 
> quotes and nothing else, I can type Compose < ' and Compose > ' to get curved 
> single quotes.  On my current keyboard, the Compose key looks like a menu and is 
> just to the right of the right Alt key; this is the default setup that came with 
> Ubuntu 15.04.  I'm sure one can get the Compose key to work on the Linux console 
> too, as plenty of people need to type accented letters on the Linux console.

There appears to be provision for a compose key in the Linux terminal,
yes; it's partially documented in man loadkeys.

> > it's yet another trivial annoyance that one has to heep onto all

> Heh.  Trivial annoyances are what motivated this change.  I've been trivially 
> annoyed at Emacs quoting `like this' for at least a decade.  Nearly every other 
> GNU package has fixed it.  I was hoping Somebody Else would fix it for Emacs, 
> but nobody ever stepped up so here we are.

You're breaking things.  Right now, Emacs works in "any" environment, and
I think this was a positive design decision way back when.  You're now
changing Emacs so that its proper working is restricted to UTF-8
environemnts, which is fine for you because you run under such.

As I've suggested before, why don't you make --with-curly-quotes a
configuration option?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello again, Paul.

On Tue, Jun 02, 2015 at 05:07:24PM +0000, Alan Mackenzie wrote:

> As I've suggested before, why don't you make --with-curly-quotes a
> configuration option?

All you would need (at least, in the C files) would be a macro
declaration like this:

    #ifdef WITH_CURLY_QUOTES
    #define Q(s) "?" #s "?"
    #else
    #define Q(s) "`" #s "'"
    #endif

, and a typical use of Q would look like this:

    error ("Buffer name " Q(%s) " is in use", SDATA (name));

.  The preprocessor produces either this:

    error ("Buffer name " "`" "%s" "'" " is in use", SDATA (name));

, or this

    error ("Buffer name " "?" "%s" "?" " is in use", SDATA (name));

, depending on whether WITH_CURLY_QUOTES is defined.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

Alan Mackenzie wrote:
> a typical use of Q would look like this:
>
>      error ("Buffer name " Q(%s) " is in use", SDATA (name));

I'm afraid that's not sufficient, as sometimes we have code like this:

	      insert_string ("\nUses keymap `");

with unbalanced quotes.  We can fix this by using another macro, uLSQM in the 
originally proposed patch:

	      insert_string ("\nUses keymap "uLSQM);

though this is starting to get ugly.

The more serious problem, though is that neither approach will work well in the 
Elisp code, which is where the vast majority of these quotes live.  It would be 
quite painful to change this:

     (format "Parsing `%s': expected %s `%s', got `%s'." a b c d)

to this:

     (format (concat "Parsing " (q "%s") ": expected %s " (q "%s")
                     ", got " (q "%s") ".")
             a b c)

I considered changing 'format' so that it automatically curves quotes in the 
format string.  But that would mishandle common cases like this:

      (format "\\`%s" path-separator)

where 'format' is being used to compose a regular expression containing '\`'.

More reasonable would be to add a new function, 'format-message', that behaves 
like 'format' except it also curves quotes, and to change functions like 
'message' and 'error' to use 'format-message' instead of plain 'format'.  But 
even here we have lots of examples like this:

      (y-or-n-p (format "File `%s' exists; overwrite? " filename))

where we'd have to change 'format' to 'format-message'.

We could go the GCC route and add a new format flag 'q', so that the above 
examples could be written like this:

     (format "Parsing %qs: expected %s %qs, got %qs." a b c d)
     (y-or-n-p (format "File %qs exists; overwrite? " filename))

This approach would make sense if 8-bit environments were still common, as they 
were when GCC added the 'q' flag to its message formatter.  However, nowadays 
8-bit environments are obsolescent (sorry) and so this approach seems like 
overkill now.  If we are bothering to go through code to fix quotes, it's better 
to change the above examples to:

     (format "Parsing ‘%s’: expected %s ‘%s’, got ‘%s’." a b c d)
     (y-or-n-p (format "File ‘%s’ exists; overwrite? " filename))

for two reasons.  First, unlike %qs the resulting code will work on older Emacs 
implementations and thus will make the code more backward-compatible.  Second, 
it's easier to read and maintain quote marks that you can see.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Thu, Jun 04, 2015 at 08:43:50AM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > a typical use of Q would look like this:

> >      error ("Buffer name " Q(%s) " is in use", SDATA (name));

> I'm afraid that's not sufficient, as sometimes we have code like this:

[ .... ]

> though this is starting to get ugly.

> The more serious problem, though is that neither approach will work well in the 
> Elisp code, which is where the vast majority of these quotes live.

[ .... ]

> I considered changing 'format' so that it automatically curves quotes in the 
> format string.  But that would mishandle common cases like this:

>       (format "\\`%s" path-separator)

> where 'format' is being used to compose a regular expression containing '\`'.

> More reasonable would be to add a new function, 'format-message', that behaves 
> like 'format' except it also curves quotes, and to change functions like 
> 'message' and 'error' to use 'format-message' instead of plain 'format'.  But 
> even here we have lots of examples like this:

>       (y-or-n-p (format "File `%s' exists; overwrite? " filename))

> where we'd have to change 'format' to 'format-message'.

> We could go the GCC route and add a new format flag 'q', so that the above 
> examples could be written like this:

>      (format "Parsing %qs: expected %s %qs, got %qs." a b c d)
>      (y-or-n-p (format "File %qs exists; overwrite? " filename))

, or even "Parsing `%qs': expected %s `%qs', got `%qs'.", where the q
means "make the surrounding quote marks display marks".

> This approach would make sense if 8-bit environments were still common, as they 
> were when GCC added the 'q' flag to its message formatter.  However, nowadays 
> 8-bit environments are obsolescent (sorry) and so this approach seems like 
> overkill now.

8-bit environments may not be all that common any more, at least on a
desktop machine, but what about over comms links?  Linux consoles are not
rare: anybody on a G/L machine without X (e.g. a server) will be using
one, as well as those, such as I, who prefer the directness and lack of
distraction the console provides.

On the Linux console, there are a maximum of 256 glyphs which can be
displayed (or 512 if you're prepared to do without half of the colours),
each of which can be assigned to an arbitrary set of unicode characters.
This limit is a hangover from video hardware made ~30 years ago, and it
is a shame that it still persists, even on modern software generated
video.

> If we are bothering to go through code to fix quotes, it's better 
> to change the above examples to:

>      (format "Parsing ‘%s’: expected %s ‘%s’, got ‘%s’." a b c d)
>      (y-or-n-p (format "File ‘%s’ exists; overwrite? " filename))

I assume that the single quotes in there are the curly ones.  I literally
cannot see the difference, since the two varieties of quotes are mapped
to the same glyphs in my consolefont.  (The curly double quotes are not
mapped at all, hence display as inverse question mark.).

I think it is this lack of WYSIWYH ("what you see is what you have") that
makes me most unhappy about this proposed change to curly quotes.

> for two reasons.  First, unlike %qs the resulting code will work on older Emacs 
> implementations and thus will make the code more backward-compatible.

But it will not work well on a console, even with the most recent Emacs.

> Second, it's easier to read and maintain quote marks that you can see.

See the `%qs' idea above.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

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

Alan Mackenzie wrote:

> , or even "Parsing `%qs': expected %s `%qs', got `%qs'.", where the q
> means "make the surrounding quote marks display marks".

I'd rather not go that route, as it's more complex to implement and to explain, 
and would mean that we'd have to figure out what happens when someone uses %q 
without surrounding grave accent, and so forth.  Even the unquoted %q would be 
bad enough: WYSIWYH says quotation marks are best represented by using, well, 
quotation marks.

> 8-bit environments may not be all that common any more, at least on a
> desktop machine, but what about over comms links?

I don't see why comms links are relevant.  What matters is what can be 
displayed.  In the old days somm comms links wouldn't transmit 8-bit data, only 
7-bit, but I assume that's not what you're talking about as that didn't support 
even 8-bit charsets.

> Linux consoles are not rare

Well, that depends on one's definition of "rare" :-), but even assuming they're 
common, curved quotes work on Linux consoles, either by default (as on Fedora) 
or by configuration (needed on Arch).  All we need to do is to set you up.

> On the Linux console, there are a maximum of 256 glyphs which can be
> displayed

That's not a problem: we're only talking about two glyphs. and you undoubtedly 
have two to spare (what are you using? CP437? I'll bet you never use its U+263B 
BLACK SMILING FACE ...).

 > the two varieties of quotes are mapped
> to the same glyphs in my consolefont.

I assume this is because you're running bleeding-edge Emacs and have told it 
that you're in an 8-bit environment that can't display curved quotes.  This is 
what commit 496bfe74990d6601d3584cb900643aa77d7b7a78 was about (Bug#20545).  The 
idea is that ordinary users in obsolescent locales will just see straight 
apostrophes instead of curved quotes, which is good enough for them.

But you're not an ordinary user: you're a developer, and would prefer to see the 
the various kinds of quotes when you're writing error messages and the like.  So 
it'd be nice to get that to work for you.

> But it will not work well on a console, even with the most recent Emacs.

Sure it will.  It works fine.  I just tried it on my Linux console (Ubuntu 
15.04).  All you have to do is configure your fonts.  This is not too much to 
ask of an Emacs developer.  We should not have to contort Emacs source code 
merely to make it fit into the character set of a circa-1981 IBM PC.

So how about trying a font that works?  You're running Arch Linux, and an 
8-year-old post in the Arch Linux forums 
<https://bbs.archlinux.org/viewtopic.php?id=121633#p954383> says that the Debian 
Lat15-Terminus16 works and looks nice on Arch Linux.  I just tried this font on 
Ubuntu 15.04 and it worked for me too, and displayed curved quotes well.  Please 
give it a try.  You can use the attached file (a copy of Ubuntu 15.04 
/usr/share/consolefonts/Lat15-Terminus16.psf.gz), and check out its curved quotes.

[-- Attachment #2: Lat15-Terminus16.psf.gz --]
[-- Type: application/gzip, Size: 2372 bytes --]

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Sat, Jun 06, 2015 at 11:11:25AM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:

[ .... ]

> > Linux consoles are not rare

> Well, that depends on one's definition of "rare" :-), ...

If you were to regard the Linux console as too rare to be worth
supporting, you'd effectively be saying that Emacs was now only supported
within GUIs.

> ... but even assuming they're common, curved quotes work on Linux
> consoles, either by default (as on Fedora) or by configuration (needed
> on Arch).  All we need to do is to set you up.

No.  You need to make sure that _everybody_ on a non-unicode terminal is
set up.  After all, you are making a drastic change to the software.  Up
till now, all messages output have been ASCII (with the exception of user
supplied characters and in some other rare instances such as outputting
`sentence-end').  You are now changing the character set to UTF-8.  At
the very least, this warrants an extensive entry in NEWS.

> > On the Linux console, there are a maximum of 256 glyphs which can be
> > displayed

> That's not a problem: we're only talking about two glyphs. and you
> undoubtedly have two to spare (what are you using? CP437? I'll bet you
> never use its U+263B BLACK SMILING FACE ...).

I'm using lat1-16.  Somehow, I'm sure I can find four (not two - there's
the curly double quotes, too) glyphs to sacrifice.

>  > the two varieties of quotes are mapped
> > to the same glyphs in my consolefont.

> I assume this is because you're running bleeding-edge Emacs and have told it 
> that you're in an 8-bit environment that can't display curved quotes.

No.  My environment is set up as UTF-8.  It's lat1-16 that maps the two
characters to the same glyph, something I wasn't aware of until the last
few days.

> This is what commit 496bfe74990d6601d3584cb900643aa77d7b7a78 was about
> (Bug#20545).  The idea is that ordinary users in obsolescent locales
> will just see straight apostrophes instead of curved quotes, which is
> good enough for them.

I don't have a straight apostrophe.  :-)  I haven't looked at that change
in any detail, but I have a question: does the code test the output
display setup to decide what sort of quotes to output (best), or is it up
to some user option (middling) or is it hard coded (worst)?

> But you're not an ordinary user: you're a developer, and would prefer
> to see the the various kinds of quotes when you're writing error
> messages and the like.  So it'd be nice to get that to work for you.

I've an idea that Richard uses a Linux terminal, too, but I'm not sure.

> > But it will not work well on a console, even with the most recent Emacs.

> Sure it will.  It works fine.  I just tried it on my Linux console
> (Ubuntu 15.04).  All you have to do is configure your fonts.  This is
> not too much to ask of an Emacs developer.

Of course not, but could it be too much to ask of an Emacs user?

> We should not have to contort Emacs source code merely to make it fit
> into the character set of a circa-1981 IBM PC.

> So how about trying a font that works?  You're running Arch Linux, ....

Gentoo, actually, and just to pre-empt RMS, we should say GNU/Linux.  ;-)

> .... and an 8-year-old post in the Arch Linux forums
> <https://bbs.archlinux.org/viewtopic.php?id=121633#p954383> says that
> the Debian Lat15-Terminus16 works and looks nice on Arch Linux.  I just
> tried this font on Ubuntu 15.04 and it worked for me too, and displayed
> curved quotes well.  Please give it a try.  You can use the attached
> file (a copy of Ubuntu 15.04
> /usr/share/consolefonts/Lat15-Terminus16.psf.gz), and check out its
> curved quotes.

I don't think that's the font for me.  It has one-pixel thick spidery
characters, rather than the two-pixel thick ones the default fonts have.
I find its @ difficult to make out, and perhaps most critically, there
isn't a big enough difference between ( and { or between ) and }.  Its
apostrophe is a vertical line rather than a top right to bottom left
sloping character, and I find its curly single quotes too indistinct,
each of them being a mere 3 pixels.  Perhaps most seriously, it's missing
an ffdf "character not found" character.  Other than that, it's not too
bad.

It at least gives another idea of which characters are worth including in
the 256 character list.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

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

Alan Mackenzie wrote:
> Up till now, all messages output have been ASCII (with the exception of user
> supplied characters and in some other rare instances such as outputting
> `sentence-end').

No, even the current stable version of Emacs (24.4) regularly outputs curved 
quotes on typical displays.  I just now ran emacs -Q, typed "C-h i m emacs RET", 
and saw curved quotes on the first screenful of the Emacs manual.  So we're not 
making such a drastic change here; we're just evolving Emacs in the natural 
direction.

> does the code test the output
> display setup to decide what sort of quotes to output (best), or is it up
> to some user option (middling) or is it hard coded (worst)?

It tests the output display setup.

>> This is not too much to ask of an Emacs developer.
>
> Of course not, but could it be too much to ask of an Emacs user?

Emacs users in 8-bit environments shouldn't need to worry about this; they 
should just see straight quotes where the Emacs manual etc. uses curved ones. 
This thread is more about the special case of a developer who's using a Linux 
console that doesn't support the full Unicode gamut.

> this warrants an extensive entry in NEWS.

Makes sense, and the next iteration of this patch will add a NEWS entry.

> I don't think that's the font for me.  It has one-pixel thick spidery
> characters, rather than the two-pixel thick ones the default fonts have.

The font has a bold variant.  I'll attach Lat15-TerminusBold16.psf.gz.  There 
are other variants that are even bigger, if you like.

> ... Its apostrophe is a vertical line rather than a top right to bottom left
> sloping character, and I find its curly single quotes too indistinct

If you just want to continue to use the same font, how about the attached font 
lat1-16.psfu.gz instead?  It's taken from the current stable version of kbd 
<http://kbd-project.org/>; see 
<http://kbd-project.org/download/kbd-2.0.2.tar.xz> and extract the file 
kbd-2.0.2/data/consolefonts/lat1-16.psfu and then use gzip to get the compressed 
version.  This handles curved single quotes and if it's the same lat1-16 font 
you're used to you should find it comfortable.  Curved double quotes don't come 
up as often, but if you want them to be displayed using a graphical 
representation other than '"', you can do something like the following:

(printf '0x0d3 U+201C\n0x0d9 U+201D\n'; psfgettable lat1-16.psfu) |
psfaddtable lat1-16.psfu - lat1-16-double.psfu
gzip -9n lat1-16-double.psfu

and then use the font lat1-16-double.psfu.gz instead.

[-- Attachment #2: Lat15-TerminusBold16.psf.gz --]
[-- Type: application/gzip, Size: 2383 bytes --]

[-- Attachment #3: lat1-16.psfu.gz --]
[-- Type: application/gzip, Size: 2076 bytes --]

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Sat, Jun 06, 2015 at 05:09:13PM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > Up till now, all messages output have been ASCII (with the exception of user
> > supplied characters and in some other rare instances such as outputting
> > `sentence-end').

> No, even the current stable version of Emacs (24.4) regularly outputs
> curved quotes on typical displays.  I just now ran emacs -Q, typed "C-h
> i m emacs RET", and saw curved quotes on the first screenful of the
> Emacs manual.

The topic was specifically "message output".  And up till now this has
been ASCII.  Saying "somebody else did it first, therefore it must be all
right for us" is a red herring.  I hope you never use that as an excuse
in a court of law.  Further, we don't control Info output, there's
nothing much we can do about it, and you have been amongst the loudest
complaining about Info 5, albeit about a different aspect.

> So we're not making such a drastic change here; we're just evolving
> Emacs in the natural direction.

Sorry Paul, but that's not so.  There's nothing "natural" about
"evolving" from ubiquitous common characters to obscure, difficult to
type, difficult to display ones.  The change in philosopy is marked.
"There's a massive movement afloat, and we're just allowing ourselves to
be swept along with it" isn't the Emacs norm.

What you want to do is to change Emacs so that it works less well on many,
if not most[*], current setups.  The one justification you've given is that
you personally find the current use of ASCII quote marks irritating,
which I would accept as a good reason, but you could fix that by fixing
your fonts, in much the same way you're advocating I fix my fonts.  I
don't think "everybody else is doing it" counts as justification at all.

[*] Even on GUI systems with all these quirky characters displayable,
it's going to be more difficult to do search operations involving them.

> > does the code test the output display setup to decide what sort of
> > quotes to output (best), or is it up to some user option (middling)
> > or is it hard coded (worst)?

> It tests the output display setup.

Excellent!  I've just updated and built my master copy, and tried it out
on the Emacs manual as bundled with the 24.5 release.  That still
displays double curly quotes as inverse question marks, though.  Could I
have misunderstood you, and the code that does this test hasn't yet found
its way into master?

> >> This is not too much to ask of an Emacs developer.

> > Of course not, but could it be too much to ask of an Emacs user?

> Emacs users in 8-bit environments shouldn't need to worry about this; they 
> should just see straight quotes where the Emacs manual etc. uses curved ones. 

And they'll see C-s searches involving "these" characters failing
inexplicably.  And this will happen in more than just "8-bit"
environments.

> This thread is more about the special case of a developer who's using a Linux 
> console that doesn't support the full Unicode gamut.

It's potentially about the "special case" of USERS of all display
environments other than unicode GUI ones.  How many environments other
than the Linux terminal are there in which these new characters won't be
displayed properly?  As the proponent of the change, you'll surely have
done this research, yes?.

> > this warrants an extensive entry in NEWS.

> Makes sense, and the next iteration of this patch will add a NEWS entry.

> > I don't think that's the font for me.  It has one-pixel thick spidery
> > characters, rather than the two-pixel thick ones the default fonts have.

> The font has a bold variant.  I'll attach Lat15-TerminusBold16.psf.gz.  There 
> are other variants that are even bigger, if you like.

I don't think it makes too much sense to talk about my personal setup.
I've already resigned myself to spending many hours on the topic, and
finding out about how Linux console fonts work has already consumed the
first few hours of this.  The real question is what support is to be
given to the bulk of other users of non-full-unicode terminals.

> > ... Its apostrophe is a vertical line rather than a top right to bottom left
> > sloping character, and I find its curly single quotes too indistinct

> If you just want to continue to use the same font, how about the attached font 
> lat1-16.psfu.gz instead?

That's the one I'm using anyway.  :-).  It's an excellent font, but it
lacks curly double quotes and distinct glyphs for curly single quotes.  I
have the requisite programs for editing fonts, namely psf2txt, and
txt2psf, part of the GNU/Linux psftools package.  psf2txt dumps a font
into a readable (and editable) format, and txt2psf does the reverse.

> It's taken from the current stable version of kbd 
> <http://kbd-project.org/>; see 
> <http://kbd-project.org/download/kbd-2.0.2.tar.xz> and extract the file 
> kbd-2.0.2/data/consolefonts/lat1-16.psfu and then use gzip to get the compressed 
> version.  This handles curved single quotes and if it's the same lat1-16 font 
> you're used to you should find it comfortable.  Curved double quotes don't come 
> up as often, but if you want them to be displayed using a graphical 
> representation other than '"', you can do something like the following:

> (printf '0x0d3 U+201C\n0x0d9 U+201D\n'; psfgettable lat1-16.psfu) |
> psfaddtable lat1-16.psfu - lat1-16-double.psfu
> gzip -9n lat1-16-double.psfu

> and then use the font lat1-16-double.psfu.gz instead.

This, indeed, is another approach.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

Alan Mackenzie wrote:

> The topic was specifically "message output".

OK.

> we don't control Info output

Actually, we do control it, and can easily tell makeinfo to output straight 
ASCII quotes.  Although that would have made sense in 1995, it doesn't make 
sense now, as makeinfo's default behavior of outputting curved quotes works 
better for ordinary usage today.

> you could fix that by fixing your fonts

No, that would disagree with common usage for these characters.  Almost 
everybody uses the current standard in this area, and it wouldn't be reasonable 
to require users to switch to long-obsolete font styles just to see decent output.

> That still displays double curly quotes as inverse question marks, though.

This is not a problem if the topic is specifically "message output", as only 
single quotes are being proposed for message output.  That being said, most 
likely your problem is because you told Emacs you were in a UTF-8 locale.  You 
can try setting LC_ALL=en_GB.iso885915 or something like that before starting Emacs.

But I'm not sure I would do that.  If I understand the rest of your message 
correctly, your environment already displays curved single quotes as nicely 
curved single quotes.  The main problem for message output is that you don't 
like the exact appearance of curved single quotes in your font and would prefer 
a different appearance and don't like any of the other fonts I've suggested and 
would rather fire up a font editor to get an appearance you like.  Although 
that's all fine of course, this appears to be mainly an issue of font style 
preference, which means it's an issue that does not block the proposed change.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Mon, Jun 08, 2015 at 11:53:54PM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:

> > The topic was specifically "message output".

> OK.

> > we don't control Info output

> Actually, we do control it, and can easily tell makeinfo to output straight 
> ASCII quotes.

Can we?  I've had a look at the online Texinfo-5 manual, but couldn't
find anything specifically about ASCII quotes.  The only thing remotely
relevant I saw was the --enable-encoding option, which I think is more
about the encoding in the .texi file than in the output .info.

> Although that would have made sense in 1995, it doesn't make sense now,
> as makeinfo's default behavior of outputting curved quotes works better
> for ordinary usage today.

Paul, this is vague hand-waving, and is simply untrue.  The only use case
where curly quotes might be said to "work" better is in passive viewing
of an Info file, and that only in a subset of our display environments.

For every other thing you might want to do with an Info file, ASCII
quotes are superior.

The abstract principle at work here is that ASCII quotes are
@dfn{working} characters, whereas the curly quotes are merely
@dfn{display} characters.  The working characters are on keyboards
(without awkward workarounds) and they can be displayed "anywhere".  The
display characters are great when sent to the printer, or in PDF files,
though.

> > you could fix that by fixing your fonts

> No, that would disagree with common usage for these characters.

I meant change the appearance of your 0x27 apostrophe so that its
appearance as a quote mark doesn't jar your aesthetic sensibilities.
This has nothing to do with its usage, surely?

> Almost everybody uses the current standard in this area, and it
> wouldn't be reasonable to require users to switch to long-obsolete font
> styles just to see decent output.

What standard?  What other projects do is their thing, and shouldn't be
affecting Emacs.  Emacs is different from most of them, in that its users
manipulate its outputs.  Anyhow, who said that the traditional form of
quoting is not decent?

> > That still displays double curly quotes as inverse question marks, though.

> This is not a problem if the topic is specifically "message output", as only 
> single quotes are being proposed for message output.  That being said, most 
> likely your problem is because you told Emacs you were in a UTF-8 locale.  You 
> can try setting LC_ALL=en_GB.iso885915 or something like that before starting Emacs.

> But I'm not sure I would do that.  If I understand the rest of your message 
> correctly, your environment already displays curved single quotes as nicely 
> curved single quotes.

Yes, the single curly quotes are "hard linked" to the ASCII single
quotes in the font.  That isn't acceptable for me - they should have
distinct glyphs if they're going to be there at all.

> The main problem for message output is that you don't like the exact
> appearance of curved single quotes in your font and would prefer a
> different appearance and don't like any of the other fonts I've
> suggested and would rather fire up a font editor to get an appearance
> you like.  Although that's all fine of course, this appears to be
> mainly an issue of font style preference, which means it's an issue
> that does not block the proposed change.

This is not the case; the discussion of individual fonts, and my personal
setup, and so on were just a distraction from the main points.  I've
described in some detail many of the things I don't like about the
proposed change, and few of them are to do with the minutiae of the
available fonts.  The change is not intended to be optional, I think,
because that would be difficult to implement.

So, it's going to be a pain in the posterior for most, if not all, users
of Emacs on terminals, and the benefit for users in GUI environments
seems marginal.  I am against this change being made.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

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

 >>> we don't control Info output
 >
 >> Actually, we do control it, and can easily tell makeinfo to output 
straight
 >> ASCII quotes.
 >
 > Can we?

I'm sure we can, though I'm too lazy to look it up right now.  And we 
can transliterate the .info files ourselves, though that would be just 
as silly.

 > The abstract principle at work here is that ASCII quotes are
 > @dfn{working} characters, whereas the curly quotes are merely
 > @dfn{display} characters.

Curved single quotes are also "working" characters, both in Emacs 
(master branch) and in Texinfo (latest stable version).  It's true that 
not every keyboard can generate them in every Emacs context with just a 
single keypress, but that's also true for many ASCII characters.  In 
practice the data entry problem is not that big a deal.

 > I meant change the appearance of your 0x27 apostrophe

It's not my apostrophe.  It's the appearance of U+0027 APOSTROPHE in 
most environments nowadays.  You may not like its appearance, and I may 
not like it either, but it's a waste of our time to reargue this now.  
The appearance has been common practice for many years, and Emacs should 
work well out of the box in common and standard environments.

 > Yes, the single curly quotes are "hard linked" to the ASCII single
 > quotes in the font.  That isn't acceptable for me - they should have
 > distinct glyphs if they're going to be there at all.

That's easy enough.  Just take lat1-16.psfu and run this shell script:

   (psfgettable lat1-16.psfu
    echo '0x0c3 U+2018'
    echo '0x0c9 U+2019'
    echo '0x0d3 U+201C'
    echo '0x0d9 U+201D') |
   psfaddtable lat1-16.psfu - lat1cq-16.psfu
   gzip -9n lat1cq-16.psfu

I'll attach the resulting font file, so you can save it and run 
'setfont' on it.  This font provides easy-to-distinguish glyphs for 
curved quotes (both single and double), and it retains the appearance of 
all ASCII characters in the font you've expressed a preference for.  
Most users won't need this sort of thing of course -- I'm just trying to 
help create a font that meets your specific needs.

 > So, it's going to be a pain in the posterior for most, if not all, users
 > of Emacs on terminals,

No, it works fine for users of Emacs on terminals in most environments 
(gnome-terminal, xterm, etc.).  It works fine even on most Linux 
consoles, where curved single quotes display as curved single quotes out 
of the box.  Ordinary users shouldn't have to fiddle with font files; 
things just work.

[-- Attachment #2: lat1cq-16.psfu.gz --]
[-- Type: application/gzip, Size: 2085 bytes --]

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Tue, Jun 09, 2015 at 01:49:47PM -0700, Paul Eggert wrote:

>  > The abstract principle at work here is that ASCII quotes are
>  > @dfn{working} characters, whereas the curly quotes are merely
>  > @dfn{display} characters.

> Curved single quotes are also "working" characters, both in Emacs 
> (master branch) and in Texinfo (latest stable version).

They're not, no matter how conventient it would be for your argument for
them to be so....

> It's true that not every keyboard can generate them in every Emacs
> context with just a single keypress, ....

.... largely for this reason.

> but that's also true for many ASCII characters.

Also untrue, for the large class of keyboards which are based on the
Latin alphabet.  That's on the sensible principle that "single
keypresses" encompass the auxiliary depression of the shift key.  There
are European keyboard layouts which require the AltGr key for some rarer
characters.  But there are NO working characters which require a
monstrosity such as C-x 8 * ?, (which is a display character to me, but a
working character for a Spaniard, who'll have a proper key for it.)

> In practice the data entry problem is not that big a deal.

It's one extra hassle, one further tedious thing to have to be learnt,
one which will bring no exquisite joy to the learner.

Using 0x60 and 0x27 as single quotes isn't a big deal either, for that
matter.

>  > I meant change the appearance of your 0x27 apostrophe

> It's not my apostrophe.

The one on your own machine is, and you're just as capable of changing
its appearance as I am of changing my console font.

> It's the appearance of U+0027 APOSTROPHE in most environments nowadays.
> You may not like its appearance, and I may not like it either, but it's
> a waste of our time to reargue this now.  The appearance has been
> common practice for many years, and Emacs should work well out of the
> box in common and standard environments.

Emacs should work well out of the box in ALL supported environments.

Just as another data point, the standard default Linux console font,
default8x16 displays the curly single quotes as inverse question marks.

[ .... ]

> That's easy enough.  Just take lat1-16.psfu and run this shell script:

[ .... ]

For the umpteenth time, the matter at hand is not the setting up of my
personal machine.  It's the fate of users of the Linux console in
general, of whom I am just one.

>  > So, it's going to be a pain in the posterior for most, if not all, users
>  > of Emacs on terminals,

> No, it works fine for users of Emacs on terminals in most environments 
> (gnome-terminal, xterm, etc.).

These all run under X.  We're in danger here of descending to arguing
about what words like "terminal" and "environment" mean.

> It works fine even on most Linux consoles, where curved single quotes
> display as curved single quotes out of the box.

????

> Ordinary users shouldn't have to fiddle with font files; things just
> work.

Indeed they shouldn't; indeed they should.  I'm glad we can agree on
that.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

Alan Mackenzie wrote:
>> Curved single quotes are also "working" characters, both in Emacs
>> >(master branch) and in Texinfo (latest stable version).
> They're not

It sounds like your definition of "working" differs from what I thought it 
meant.  I thought you were using "working" to mean that a character has a 
special function in Emacs or in the file that one is editing.  But as I 
understand it now, by "working" you mean that it's a character on your keyboard. 
  If so, then yes, you're right, curved single quotes are typically not 
"working" characters.  But I fail to see the significance of this point.  For 
example, the newline character is not a "working" character on my keyboard, but 
that doesn't mean we should exclude newlines from our source files.

>> >It's true that not every keyboard can generate them in every Emacs
>> >context with just a single keypress, ....
>> >but that's also true for many ASCII characters.
> Also untrue, for the large class of keyboards which are based on the
> Latin alphabet.

I have such a keyboard, and when I type Return, Emacs doesn't put a carriage 
return into a typical buffer; it does something else.  Or when I type the \ key 
in a Lisp string, Emacs doesn't put a \ into the string; it does something else. 
  Or when I type a space character when searching, Emacs doesn't search for a 
space; it does something else.  In all these cases, if I really want to get 
exactly the ASCII character in question, I have to do something other than type 
a key labeled by that character.  And my point was that this is something that 
many ASCII characters have in common with curved quotes.

> the standard default Linux console font, default8x16

It's news to me that this is the standard default Linux console font.  It's not 
available in Ubuntu or in Fedora, which are popular GNU/Linux distributions. 
Perhaps it's something used at a low level while booting?  That would make 
sense, if it uses the same encoding that the IBM PC used back in 1981.  Anyway, 
it doesn't seem to be of much practical relevance to this thread.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello again, Paul.

On Tue, Jun 09, 2015 at 04:42:33PM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> >> Curved single quotes are also "working" characters, both in Emacs
> >> >(master branch) and in Texinfo (latest stable version).
> > They're not

> It sounds like your definition of "working" differs from what I thought it 
> meant.

I had thought an informal definition with examples would suffice.  Seems
not.  How about a "working character" being "a character it's easy to
work with"?  That would involve it being easy to type on some standard
keyboard, and being displayable on "all" standard display environments.

> I thought you were using "working" to mean that a character has a 
> special function in Emacs or in the file that one is editing.  But as I 
> understand it now, by "working" you mean that it's a character on your keyboard. 
>   If so, then yes, you're right, curved single quotes are typically not 
> "working" characters.  But I fail to see the significance of this point.

Imagine a keyboard where _all_ characters had to be input by giving their
ASCII (or unicode) code.  That would be hellish, and completely unusable
by any normal person.  Now scale that back a bit, so that only _some_
characters need to be input by code.  That's bad if you use these
characters.  That's like the situation you want to create.  You want to
promote difficult-to-type and problematic-to-display characters to the
status of standard "working characters".  This will make Emacs less
usable.

> For example, the newline character is not a "working" character on my
> keyboard, but that doesn't mean we should exclude newlines from our
> source files.

Newline isn't a "character" in the sense meant.  It does not appear in
any font.  It is more a command than a character.  I admit you could
repeatedly pick holes in any informal definition of "working character" I
give, until we end up with a rigorous, and bearly readable, definition.
That wouldn't be a good use of time for either of us.

> >> >It's true that not every keyboard can generate them in every Emacs
> >> >context with just a single keypress, ....
> >> >but that's also true for many ASCII characters.
> > Also untrue, for the large class of keyboards which are based on the
> > Latin alphabet.

> I have such a keyboard, and when I type Return, Emacs doesn't put a carriage 
> return into a typical buffer; it does something else.  Or when I type the \ key 
> in a Lisp string, Emacs doesn't put a \ into the string; it does something else. 
>   Or when I type a space character when searching, Emacs doesn't search for a 
> space; it does something else.  In all these cases, if I really want to get 
> exactly the ASCII character in question, I have to do something other than type 
> a key labeled by that character.  And my point was that this is something that 
> many ASCII characters have in common with curved quotes.

That's a total diversion.  In normal typing, the characters embossed on
your physical keys are what you see when you type them.  I put it to you
that you don't have any of the four curly quote characters embossed on
any key on your keyboard, and you have no easy way to type them.  I.e.
they're "display characters" even for you.  You have no problem
whatsoever typing \ or space.

I have a feeling you're intending to argue for making the use of curly
quotes in our Lisp files standard.  That would be a backward step for
usability.  

Anyway, here's another idea for making curly quotes in lisp code
optional: an escaped 0x27 or 0x60 in a string should be translated by the
reader to the appropriate ASCII or curly quote, depending on the user's
configuration.  So a doc string might contain this:

    \`foo-bar\'

, and would become ?foo-bar? on your system and `foo-bar' on mine.  That
way, the quotes are still visible in the source as quotes, and the extra
space taken up is minimal, in fact no more than when a " needs to be
escaped.  It would also be fully backward compatible with earlier
Emacsen.  A slight disadvantage would be that users would have to compile
the lisp sources when building a new Emacs.  There are fewer than 61004
occurrences of `...' in our sources.

This could make the extra effort involved in adapting the C source to
handle --with-curly-quotes worthwhile.

> > the standard default Linux console font, default8x16

> It's news to me that this is the standard default Linux console font.  It's not 
> available in Ubuntu or in Fedora, which are popular GNU/Linux distributions.

It's a first class member of the set of fonts distributed in the source
from http://freshmeat.net/projects/kbd/.  It's certainly the default in
Gentoo, quite likely in other distros, too.

> Perhaps it's something used at a low level while booting?  That would make 
> sense, if it uses the same encoding that the IBM PC used back in 1981.  Anyway, 
> it doesn't seem to be of much practical relevance to this thread.

Getting back on topic, we agreed yesterday that things should "just
work", and that users should not have to fiddle around with fonts.  If
you make this change, then fiddling around with fonts is precisely what
some users are going to have to do.

Again, I think the only justification for the change you've given is that
you personally don't like the look of 0x60 and 0x27 used as quote
characters.  Is that really sufficient justification for the loss of
usability we would all face, and the problems with fonts which a subset
of users would be faced with?  With my new idea above for `...' in lisp
files, how about reconsidering my "Q" C macro from a few days ago?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

Alan Mackenzie wrote:

> You want to
> promote difficult-to-type and problematic-to-display characters to the
> status of standard "working characters".

The problems aren't that serious.  Display problems are limited to obsolete 
environments that hardly anybody uses because they're so awful, and even there 
we have workarounds.  And typing problems aren't a big deal in my Emacs 
environment: for left and right single quotes I normally type a single 
keystroke, without any control or shift or meta keys.  (This is because I use 
Electric Quote mode.)  Other typing environments are also available that work 
nearly as well (using Alt-[ and Alt-] for the two characters, if your Alt key 
works).

I'm not expecting everyone to use these keyboard methods right away.  There will 
be a transition period, and perhaps other, better methods of dealing this will 
emerge.  However, there should be no obstacle to people who do want to use those 
methods.

> I have a feeling you're intending to argue for making the use of curly
> quotes in our Lisp files standard.

Yes, of course.  It should be normal to type quotes as themselves in doc 
strings.  It's basic WYSIWYG.

> Anyway, here's another idea for making curly quotes in lisp code
> optional: an escaped 0x27 or 0x60 in a string should be translated by the
> reader to the appropriate ASCII or curly quote, depending on the user's
> configuration.  So a doc string might contain this:
>
>      \`foo-bar\'

I considered doing that, but there were problems.  First, it would make doc 
strings harder to read.  For example, this:

"Setting this attribute will also set the \`:family\',
\`:foundry\', \`:width\', \`:height\', \`:weight\', and
\`:slant\' attributes."

is harder to read than this:

"Setting this attribute will also set the ‘:family’, ‘:foundry’,
‘:width’, ‘:height’, ‘:weight’, and ‘:slant’ attributes."

Second, the new escapes would cause mental overload with similar 
already-existing uses (e.g., ?\`, "\\`").  Third, and most serious, is that the 
new escapes would mean that string literals are not constants but are instead 
expressions whose values depend on runtime context, and this would affect 
everything: how the byte-compiler works, for example.

To avoid the most serious problem, I considered a simpler idea: have the Lisp 
reader treat \` and \' as curved single quotes in strings.  However, this still 
has the basic problem of being hard to read.  It is needless work to add a 
hard-to-read and nearly-ubiquitous feature merely to cater to obsolete 
platforms.  It's simpler to use quote characters to represent themselves.

> Again, I think the only justification for the change you've given is that
> you personally don't like the look

It's not just me personally.  The rest of the world has moved on.  At this point 
when outsiders look at Emacs they see mysterious and inappropriate and 
off-putting quoting.  And this sort of thing has been happening for a while. 
See, for example:

http://www.trilithium.com/johan/2005/07/quotation-marks/

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Dmitry Gutov]

On 06/10/2015 07:20 PM, Paul Eggert wrote:

> Yes, of course.  It should be normal to type quotes as themselves in doc
> strings.  It's basic WYSIWYG.

One doesn't usually see WYSIWYG in program source files.

I think it's okay (more or less) if you want to type a curly quote in a 
docstring if it has no secondary meaning. Less so if you want to use it 
to delineate Lisp symbols or code.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/10/2015 10:39 AM, Dmitry Gutov wrote:
> One doesn't usually see WYSIWYG in program source files. 

I suppose it depends on what one means by "WYSIWYG"; I was referring to 
a primary use of character string literals, which is that they're parts 
of programs that look like what will be displayed.  That is, in 
principle one could write sequences of character codes instead, but this:

    printf ((char const []) { 0x48, 0x65, 0x6c, 0x6c, 0x6f, 0 });

is much simpler when written as this:

   printf ("Hello");

> I think it's okay (more or less) if you want to type a curly quote in 
> a docstring if it has no secondary meaning. Less so if you want to use 
> it to delineate Lisp symbols or code. 

I don't see where that "less so" is coming from.  In doc strings it's 
clearer to use curved quotes to delimit English from Lisp, and to use 
grave accent for its ordinary use in Lisp.  This helps the reader 
distinguish English text that talks about Lisp code from the Lisp code 
itself.  For example, this:

``VAL' matches if the object is `equal' to VAL

is confusing compared to this:

‘`VAL’ matches if the object is ‘equal’ to VAL

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Wed, Jun 10, 2015 at 09:20:26AM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:

> > You want to
> > promote difficult-to-type and problematic-to-display characters to the
> > status of standard "working characters".

> The problems aren't that serious.  Display problems are limited to obsolete 
> environments that hardly anybody uses ....

Is that right?  How many people is that, then?  The answer is you haven't
a clue.  You haven't even a clue how many people in total use Emacs.
None of us has, and neither has anybody else.

It seems to me, judging by the number of questions relating to Emacs on
the Linux console I've answered over the years, the number of users is
not small.  And "obsolete" these environments are not.  They're useful,
and they're used.

> ... because they're so awful, ...

Actually, I happen rather to like them.  I believe RMS does, too.  There
are several advantages the console has over a GUI, even assuming both are
available (which they aren't always).  Logically, if you're doing pure
text work, a GUI is going to have lots of irrelevant graphicsy things
which are just going to get in the way.  One example is window managers
taking M-<tab> away from Emacs.  Yes, I know there are workarounds for
this.

> ... and even there we have workarounds.

Workarounds are by their very nature second rate.  As competent hackers,
we should be finding solutions rather than workarounds.

> And typing problems aren't a big deal in my Emacs environment: for left
> and right single quotes I normally type a single keystroke, without any
> control or shift or meta keys.  (This is because I use Electric Quote
> mode.)  Other typing environments are also available that work nearly
> as well (using Alt-[ and Alt-] for the two characters, if your Alt key
> works).

It doesn't.  Last time I checked, the Alt key wasn't in use at all in
standard Emacs.  It would be easy enough to introduce an Alt in
GNU/Linux, there's no shortage of silly keys around, but it would be more
problematic in MS-Windows, where the silly keys are already in use.

And things like Electric Quote mode will only work inside Emacs.  But
we've talked about that before.

> I'm not expecting everyone to use these keyboard methods right away.
> There will be a transition period, and perhaps other, better methods of
> dealing this will emerge.  However, there should be no obstacle to
> people who do want to use those methods.

> > I have a feeling you're intending to argue for making the use of curly
> > quotes in our Lisp files standard.

> Yes, of course.  It should be normal to type quotes as themselves in doc 
> strings.  It's basic WYSIWYG.

My entire argument over the last several posts has been about upholding
WYSIWYG.

> > Anyway, here's another idea for making curly quotes in lisp code
> > optional: an escaped 0x27 or 0x60 in a string should be translated by the
> > reader to the appropriate ASCII or curly quote, depending on the user's
> > configuration.  So a doc string might contain this:

> >      \`foo-bar\'

> I considered doing that, but there were problems.  First, it would make doc 
> strings harder to read.  For example, this:

> "Setting this attribute will also set the \`:family\',
> \`:foundry\', \`:width\', \`:height\', \`:weight\', and
> \`:slant\' attributes."

> is harder to read than this:

> "Setting this attribute will also set the ‘:family’, ‘:foundry’,
> ‘:width’, ‘:height’, ‘:weight’, and ‘:slant’ attributes."

Only marginally harder.  We routinely cope with \" and \n and so on
inside strings without problems.  \' and \` are no harder.  And the
number of strings with lots of single quoted symbols on a line is going
to be quite small.

> Second, the new escapes would cause mental overload with similar 
> already-existing uses (e.g., ?\`, "\\`").

We cope fine with ?\" in code and \" in strings.  The mental overload
for the corresponding ` and ' cases will be no higher.  And, most
importantly, it will be confined to the source code.  When reading the
doc strings with C-h f/v, the backslashes wouldn't be there.

> Third, and most serious, is that the new escapes would mean that string
> literals are not constants but are instead expressions whose values
> depend on runtime context, and this would affect everything: how the
> byte-compiler works, for example.

No, not at all.  My proposition is that string literals remain constants
just as they are now.  The decision would be made at configuration time,
and a trivial #ifdef in the reader would decide at build time how to
expand the escaped quotes.  The necessary change took me less than 20
minutes, having started with no familiarity of the reader:


--- lread.c	2015-06-08 12:54:35.000000000 +0000
+++ lread.c.acm	2015-06-10 17:58:01.000000000 +0000
@@ -2350,6 +2350,13 @@
 	return i;
       }
 
+#ifdef WITH_CURLY_QUOTES
+    case '\'':
+      return '?';
+    case '`':
+      return '?';
+#endif
+
     default:
       return c;
     }


.  As always, forgive me not having the requisite keys to type the actual
curly quote characters in the above.

> To avoid the most serious problem, I considered a simpler idea: have the Lisp 
> reader treat \` and \' as curved single quotes in strings.  However, this still 
> has the basic problem of being hard to read.  It is needless work to add a 
> hard-to-read and nearly-ubiquitous feature merely to cater to obsolete 
> platforms.  It's simpler to use quote characters to represent themselves.

By "obsolete platforms" you just mean ones you yourself don't like, I
think.  I believe it's a tradition that when retiring obsolete OS support
from Emacs, a single dissenting voice is sufficient to "rescue" an OS
from being dropped.  The same should apply here.

Emacs on the Linux console is used.  Gratuitously damaging functionality
on supported platforms is not something to be done lightly, particularly
when there's an easy, if tedious, way to carry on supporting them
properly.  The whole ethos of Emacs is about being able to set it up to
suit personal preferences.  I'm anxious that this continue.

As noted before you are proposing a massive philosophical change from
pure ASCII (modulo a few "display characters") source to (presumably
unrestricted) Unicode.  The number of unicode characters you want to
insert is in the tens of thousands.

> > Again, I think the only justification for the change you've given is that
> > you personally don't like the look

> It's not just me personally.  The rest of the world has moved on.

Much of the world might well have moved, but that's not grounds for
allowing ourselves to be dragged along with it.  If we allowed popularity
to be the deciding criterion for making our decisions, we'd all be using
MS-Windows.

> At this point when outsiders look at Emacs they see mysterious and
> inappropriate and off-putting quoting.  And this sort of thing has been
> happening for a while.  See, for example:

> http://www.trilithium.com/johan/2005/07/quotation-marks/

One person doesn't like 0x60 and 0x27 as quote marks.  So?  Follow my
suggestion above, and he can configure his Emacs with --with-curly-quotes
(or, more likely, just allow the default to take its course).  And if he
neither uses Emacs nor intends to, of what value are his opinions in this
thread?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/10/2015 12:17 PM, Alan Mackenzie wrote:
> It seems to me, judging by the number of questions relating to Emacs on
> the Linux console I've answered over the years, the number of users is
> not small.

I'm afraid there was a miscommunication there.  My message was not about 
people who use the Linux console, a small but hardy band of hackers.  It 
was about people who use the Linux console in an awful mode that can't 
display curved single quotes.  That's not you, and it's not me (and I do 
use Emacs on the Linux console and I haven't configured it specially), 
and I doubt whether it's RMS either. Perhaps some people use Emacs that 
way occasionally, but I'm skeptical that this is a significant problem.  
If it is, we can easily solve it by automatically doing in Emacs the 
equivalent of the font substitution I gave the shell script for in a 
recent message.  So this issue is not a fundamental obstacle to the change.

> My proposition is that string literals remain constants
> just as they are now.  The decision would be made at configuration time,
> and a trivial #ifdef in the reader would decide at build time how to
> expand the escaped quotes.

Making them constants removes the most serious objection I had to the 
idea.  I wouldn't favor writing documentation that way, as it's ugly to 
quote \`like this\' when it can easily be quoted ‘like this’.  But it 
could be useful for people who prefer its minor ugliness to having to 
learn how to type curved quotes, so I suppose we can add it.

However, the configuration-time switch sounds like a non-starter, as it 
would be one more source of portability hassles and it shouldn't be 
needed if we get the display problems fixed, which we need to fix 
anyway.  That is, the escapes should simply generate curved single 
quotes on all platforms.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Wed, Jun 10, 2015 at 12:44:51PM -0700, Paul Eggert wrote:
> On 06/10/2015 12:17 PM, Alan Mackenzie wrote:
> > It seems to me, judging by the number of questions relating to Emacs on
> > the Linux console I've answered over the years, the number of users is
> > not small.

> I'm afraid there was a miscommunication there.  My message was not about 
> people who use the Linux console, a small but hardy band of hackers.

Phew!  I'm glad to hear that!

> It was about people who use the Linux console in an awful mode that
> can't display curved single quotes.  That's not you, and it's not me
> (and I do use Emacs on the Linux console and I haven't configured it
> specially), and I doubt whether it's RMS either.

My setup couldn't display curly single quotes (I've now created a font
based on lat1-16.psfu where I substitued the French glyphs "oe" and "OE"
with the single curly quotes) - instead it lied to me and displayed the
glyphs for 0x60 and 0x27 when there were curly quotes.  This hard linking
of curly and ASCII quotes contravenes the WYSIWYG principle.  I presume
this lack of distinct glyphs will be quite common.

> Perhaps some people use Emacs that way occasionally, but I'm skeptical
> that this is a significant problem.

We simply don't know, one way or the other.

> If it is, we can easily solve it by automatically doing in Emacs the
> equivalent of the font substitution I gave the shell script for in a
> recent message.  So this issue is not a fundamental obstacle to the
> change.

Hmm.  Not sure about "easily".  On a Linux console being used for editing
files.el, we can probably safely assume that all ASCII characters are
available.  More than that, not much.

In fact, I've tried out quite a few different fonts in
/usr/share/consolefonts.  All of them have ASCII, most, but not all,
alias the single curly quotes with 0x27, 0x60, none of them that I've
seen so far have distinct glyphs for the curly quotes.

> > My proposition is that string literals remain constants
> > just as they are now.  The decision would be made at configuration time,
> > and a trivial #ifdef in the reader would decide at build time how to
> > expand the escaped quotes.

> Making them constants removes the most serious objection I had to the 
> idea.  I wouldn't favor writing documentation that way, as it's ugly to 
> quote \`like this\' when it can easily be quoted ‘like this’.

That easiness remains controversial.  Typing \ then ` is going to be in
people's muscle memory, whereas something like <some-modifier-key>-` less
so.  In fact, I'd bet a fair amount that people will carry on writing
`...', just as they've done for decades, and there will be regular
"raids" from the wonderful people here who do finnicky thankless
corrections.

> But it could be useful for people who prefer its minor ugliness to
> having to learn how to type curved quotes, so I suppose we can add it.

To be useful, it would have to become the standard way of quoting
symbols.

> However, the configuration-time switch sounds like a non-starter, as it 
> would be one more source of portability hassles and it shouldn't be 
> needed if we get the display problems fixed, ...

Where do you see any portability hassles?  If built
--without-curly-quotes, Emacs would run under any system handling ASCII,
as at present.  If built --with-curly-quotes, it will be less portable,
as we've discussed at length, but will be no less portable than the
non-optional curly quote system you're proposing.

What exactly do you mean by "display problems fixed"?  Either a font has
curly quotes (I haven't found one, other than my own, which has), aliases
them with other characters, or doesn't have them.  In the first case
there's nothing to fix, while the other two cases can't really be fixed
at all - there are merely workarounds.

> ... which we need to fix anyway.  That is, the escapes should simply
> generate curved single quotes on all platforms.

... which removes half the point in having the \` \' constructs in the
first place.  (The other half is in it being easier to type \` and /'
than ? and ?.)

Incidentally, I've just tried electric-quote-mode in master.  It seems
more like a proof of concept than a finished feature.  In particular, I
don't think it's TRT simply to curlify any quote typed within a string -
some strings mean quite definitely 0x27 and 0x60.  And to be 100% sure
we're within a string is difficult.  How about only curlifying when
there's a matched pair of quotes containing exactly a symbol, and
uncurlifying when that ceases to be the case?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

Alan Mackenzie wrote:

> My setup couldn't display curly single quotes

Sure it could.  It displayed curved single quotes as curved single quotes.  Your 
objection was that your setup also displayed grave accent and apostrophe as 
curved single quotes (a style you happen to prefer), and you wanted your setup 
to display *different-shaped curves* for curved single quotes.  This will not be 
not a problem to the few ordinary Emacs users who happen to use a similar 
obsolescent environment; they'll merely see nicely curved single quotes and move on.

> none of them that I've
> seen so far have distinct glyphs for the curly quotes.

Again, distinct glyphs are not a requirement for ordinary Emacs users.  That 
being said, for Emacs developers such as yourself, the Lat15-Terminus16 font I 
mentioned earlier has distinct glyphs for curved quotes, as does 
Lat15-TerminusBold16.  You can find them archived at 
<http://bugs.gnu.org/20707>.  There are many other choices in this area.

> That easiness remains controversial.

It's certainly easier to read text quoted ‘like this’ than to read text quoted 
\`like this\'.

> To be useful, it would have to become the standard way of quoting
> symbols.

I doubt whether it'll be the standard.  It's uglier and more complicated than 
the alternative.  Its main advantage is that it's easier to type for users who 
want to type only ASCII.

> Where do you see any portability hassles?

Code might work when running on a typical Emacs system, but might fail on an 
Emacs system configured --without-curved-quotes, because Emacs will generate 
different strings that will be treated differently.

> What exactly do you mean by "display problems fixed"?

On the rare systems that don't display curved quotes as quotes, Emacs should 
display straight quotes as substitutes.  That's good enough for these rare and 
obsolescent systems.

> I don't think it's TRT simply to curlify any quote typed within a string

Electric Quote mode doesn't do that.  If you type an apostrophe, it normally 
leaves the apostrophe alone.  And in the rare cases where one really wants a 
grave accent and not a left single quote, it's easy enough to type C-q `.

> How about only curlifying when
> there's a matched pair of quotes containing exactly a symbol, and
> uncurlifying when that ceases to be the case?

That wouldn't work well; for example, it'd mishandle the common case of "`%s'". 
  Worse, it'd mean that Emacs couldn't curve the open quote until the user types 
the corresponding closed quote.  I experimented with several approaches along 
the lines you're suggesting, and they all had action-at-a-distance problems that 
made for confusing UIs.  It's much better if quotes are curved only when near 
the cursor, so users see them being curved.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Thu, Jun 11, 2015 at 07:41:54PM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:

> > My setup couldn't display curly single quotes

> Sure it could.  It displayed curved single quotes as curved single quotes.  Your 
> objection was that your setup also displayed grave accent and apostrophe as 
> curved single quotes (a style you happen to prefer), ....

No.  The curly quotes had hijacked the glyphs for 0x27 and 0x60.  I think
it likely that these glyphs originated as those for 0x27 and 0x60, and
were so before Unicode even existed.

> ... and you wanted your setup to display *different-shaped curves* for
> curved single quotes.  This will not be not a problem to the few
> ordinary Emacs users who happen to use a similar obsolescent
> environment; they'll merely see nicely curved single quotes and move
> on.

That's pure speculation.  So far, we've got one data point, me, and I was
not at all happy about this aliasing when I discovered it.  Nobody has
yet chimed in and said they'd be happy about it on their own system.

> > none of them that I've seen so far have distinct glyphs for the curly
> > quotes.

> Again, distinct glyphs are not a requirement for ordinary Emacs users.

Again, we just don't know this one way or the other.  Anyway I thought
we'd agreed on the WYSIWYG principle.  With this aliasing, WYS is
ambiguous, WYG is not.

> That being said, for Emacs developers such as yourself, the
> Lat15-Terminus16 font I mentioned earlier has distinct glyphs for
> curved quotes, as does Lat15-TerminusBold16.  You can find them
> archived at <http://bugs.gnu.org/20707>.  There are many other choices
> in this area.

Yes, but of the standard fonts (i.e., those distributed in the kbd
GNU/Linux package) I'm not sure there're any with distinct glyphs for
curly quotes.  I think whatever happens, messing around with fonts would
be needed for lots of console users.

> > That easiness remains controversial.

> It's certainly easier to read text quoted ‘like this’ than to read text quoted 
> \`like this\'.

Yes, but marginally so.  It's not easier to type it, electric-quote-mode
notwithstanding.  Nobody's ever complained about \"like this\" in a
string.  We all cope with far worse in complicated regular expressions.

> > To be useful, it would have to become the standard way of quoting
> > symbols.

> I doubt whether it'll be the standard.  It's uglier and more complicated than 
> the alternative.  Its main advantage is that it's easier to type for users who 
> want to type only ASCII.

The main advantage is that it would allow users to chose whether they want
curly quotes routinely in their doc strings.

How about another approach - leave the doc strings as they are, and
translate `foo-bar' to ?foo-bar? when doing C-h f/v, and so on?  `..' is
used in doc strings mainly for quoting _symbols_, and it may well be that
that's the only use of this quoting style.  Making this enhancement would
certainly be less work than changing several tens of thousands of
`foo-bar's in the source code.

> > Where do you see any portability hassles?

> Code might work when running on a typical Emacs system, but might fail on an 
> Emacs system configured --without-curved-quotes, because Emacs will generate 
> different strings that will be treated differently.

I can't see that.  There'd just be displayable characters in the two
versions - why would it matter that they were different?  Maybe if the
string were being passed to `read', there could be a difference, but in
that case it's the curly-quote version which is more likely to be
erroneous.

> > What exactly do you mean by "display problems fixed"?

> On the rare systems that don't display curved quotes as quotes, Emacs should 
> display straight quotes as substitutes.  That's good enough for these rare and 
> obsolescent systems.

OK.  I don't agree with this approach, of course.

> > I don't think it's TRT simply to curlify any quote typed within a string

> Electric Quote mode doesn't do that.  If you type an apostrophe, it normally 
> leaves the apostrophe alone.  And in the rare cases where one really wants a 
> grave accent and not a left single quote, it's easy enough to type C-q `.

OK.  I hadn't tried typing just apostrophes.  Sorry.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/12/2015 04:25 AM, Alan Mackenzie wrote:
> No. The curly quotes had hijacked the glyphs for 0x27 and 0x60.

Only from the point of view of someone who prefers an obsolescent 
style.  Nowadays those two glyphs in computer text typically stand for 
curved quotes.  So a more typical interpretation nowadays would be that 
in that font, 0x27 and 0x60 hijacked the glyphs for curved quotes.  
Although you prefer the older style (and that is of course your 
privilege), your console was displaying curved single quotes just fine 
in the typical way that most people expect nowadays on computer displays.

> So far, we've got one data point, me

No, we've got lots of data points.  Many people use Emacs 24.5 and 
later, it displays curved quotes in ordinary use even when users don't 
type them, and it's not a problem in typical practice.

> I think whatever happens, messing around with fonts would be needed 
> for lots of console users

No, it'll work fine for most Linux console users, as most GNU/Linux 
distributions have console fonts that don't have the aliasing problem.  
Debian-based distributions are fine, as are Fedora-based distributions.  
Although you're running on one of the less-common console setups that 
does have an aliasing problem, it's not a problem that most users of 
these setups will care about, and anyway it's a problem that's easy to 
fix, for the rare users who will care.

>  How about another approach ... translate `foo-bar' to  ‘foo bar’ when 
> doing C-h f/v, and so on?

Done in commit 0fd5e6593af620863dcf90dff5d04631458e24cd dated May 28.  
However, this doesn't fix Bug#20707, as it affects only doc strings.

>
>> Code might work when running on a typical Emacs system, but might fail on an
>> Emacs system configured --without-curved-quotes, because Emacs will generate
>> different strings that will be treated differently.
> I can't see that.  There'd just be displayable characters in the two
> versions - why would it matter that they were different?

Code regularly processes such strings, not typically by 'read', more 
often by applying string or regular expression matching to them. 
Introducing this new compatibility problem would cause trouble into the 
indefinite future.  It's not worth the extra hassle.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Paul.

On Fri, Jun 12, 2015 at 04:46:09PM -0700, Paul Eggert wrote:
> On 06/12/2015 04:25 AM, Alan Mackenzie wrote:
> > No. The curly quotes had hijacked the glyphs for 0x27 and 0x60.

> Only from the point of view of someone who prefers an obsolescent 
> style.

No, from the point of view of somebody who has some feel for how history
works.  What you're suggesting is that between the 1960s, when ASCII was
formalised, and the late 1980s, people were desperately waiting for the
development of Unicode so that they could filch the glyphs from it and,
at last, have some way of representing 0x27 and 0x60 as glyphs.  That's
patently ridiculous.

> Nowadays those two glyphs in computer text typically stand for curved
> quotes.  So a more typical interpretation nowadays would be that in
> that font, 0x27 and 0x60 hijacked the glyphs for curved quotes.

It's not a matter of "interpretation".  0x27 and 0x60 were there first.
There are fonts where the glphs used for these ASCII characters are
plainly the curly quotes, but few.  I'd challenge you to argue that the
following glyph for 0x60 originated as left curly quote:

Bitmap: -------- \
        --##---- \
        --##---- \
        --##---- \
        ---##--- \
        -------- \
        -------- \
        -------- \
        -------- \
        -------- \
        -------- \
        -------- \
        -------- \
        -------- \
        -------- \
        --------


> Although you prefer the older style (and that is of course your
> privilege), your console was displaying curved single quotes just fine
> in the typical way that most people expect nowadays on computer
> displays.

You're trying to twist facts to fit in with your way of thinking.

> > So far, we've got one data point, me

> No, we've got lots of data points.

By "data points" is meant those who use Emacs on the (Linux) console.  I
repeat, the only such user who's expressed a view on your proposed change
is me.  If I'm mistaken here, I'd appreciate references to those other
console users' views.

> Many people use Emacs 24.5 and later, it displays curved quotes in
> ordinary use even when users don't type them, and it's not a problem in
> typical practice.

That's sophistry.  Curly quotes are not currently in use in (released)
Emacs, so of course there's no problem with them yet.

> > I think whatever happens, messing around with fonts would be needed 
> > for lots of console users

> No, it'll work fine for most Linux console users, as most GNU/Linux 
> distributions have console fonts that don't have the aliasing problem.  
> Debian-based distributions are fine, as are Fedora-based distributions.

There are 115 console fonts supplied in the kbd package.  Only 32 of
them have a glyph for 0x2018 (left curly quote).  Of these 32, the glyph
is shared with 0x60 in 15 fonts.  All 115 fonts have 0x60.

> Although you're running on one of the less-common console setups that 
> does have an aliasing problem, it's not a problem that most users of 
> these setups will care about, and anyway it's a problem that's easy to 
> fix, for the rare users who will care.

Pure speculation.  You're projecting your own attitudes and workflow onto
an unknown number of other users, like Andy Moreton said a couple of days
ago.

The fact is, we don't know one way or the other.

I suspect the majority of these users will care about it, but won't have
the time or the energy to fix it.  They will suffer for evermore, just as
you have been suffering the lack of curly quotes.  Fixing it is
_difficult_, not easy, for a normal user, since there is no clear entry
into the thicket of Linux documentation - a normal user isn't going to
know that the appropriate utility is setfont, or where to find font
editing software; I certainly didn't up until a few days ago, and it took
a lot of effort to find out.

As I keep saying, this conversion to curly quotes should be optional,
like other controversial new features in Emacs are.

> >  How about another approach ... translate `foo-bar' to  ‘foo bar’ when 
> > doing C-h f/v, and so on?

> Done in commit 0fd5e6593af620863dcf90dff5d04631458e24cd dated May 28.

Great.  Personally, I don't want it, though - I want to be able to _work_
in *Help* buffers, not merely have them displayed at me.  What's the flag
to turn it off called?

> However, this doesn't fix Bug#20707, as it affects only doc strings.

#20707 isn't a bug, in the narrow sense of the word, so doesn't need
fixing.  It's a change request.

Anyway, what other strings other than doc strings might want this change?
I've grepped for "\`.*'" and found lots of doc strings, and some `error'
and `message' string arguments like `%s'.  Is there anything else?

> >> Code might work when running on a typical Emacs system, but might fail on an
> >> Emacs system configured --without-curved-quotes, because Emacs will generate
> >> different strings that will be treated differently.
> > I can't see that.  There'd just be displayable characters in the two
> > versions - why would it matter that they were different?

> Code regularly processes such strings, not typically by 'read', more 
> often by applying string or regular expression matching to them.

I can't recall seeing any instance of Lisp or C code processing doc
strings, or `error' arguments in any way that would make a difference.
Can you cite a specific example?
 
> Introducing this new compatibility problem would cause trouble into the
> indefinite future.

You still haven't given a specific example of where and how such trouble
might arise.

> It's not worth the extra hassle.

This whole idea of imposing curly quotes on users is extra hassle for
users.  Making them optional would, at worst, be extra hassle only for us
maintainers.  Which is preferable?  For comparison, in Emacs 21, fringes
were imposed on GUI users, without them having a way to turn them off.  A
lot of them didn't like it and were up in arms about it.  We shouldn't be
repeating that mistake.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

Alan Mackenzie wrote:
> I'd challenge you to argue that the
> following glyph for 0x60 originated as left curly quote:

The history doesn't matter that much.  What's more important is how Emacs works 
now.  Today's displays mostly show curved quotes as curved quotes, show 
apostrophe as a straight vertical quote, and show grave accent as a straight 
slanted accent, and Emacs doesn't look good on these displays.  That's the bug 
that needs to be fixed.

> By "data points" is meant those who use Emacs on the (Linux) console.  I
> repeat, the only such user who's expressed a view on your proposed change
> is me.

I use Emacs on the Linux console occasionally.  It works adequately in the 
latest master.  So we have at least two data points.

> Curly quotes are not currently in use in (released) Emacs

Yes they are, when reading the documentation.

> What's the flag to turn it off called?

Sorry, there's no flag.  We couldn't just "turn it off", as doc strings will 
contain curved quotes and these need to be parsed regardless of user display 
preferences.  I suppose there could be an option to transliterate them to 
straight quotes before insertion into the *Help* buffer, for users who prefer 
that.  But this should be done regardless of whether the source code uses curved 
quotes.  And it shouldn't be done if the source uses escaped characters.

> what other strings other than doc strings might want this change?

Mostly diagnostics.

> I can't recall seeing any instance of Lisp or C code processing doc
> strings, or `error' arguments in any way that would make a difference.
> Can you cite a specific example?

Sure, see the latest commit to the master: commit 
8afef016e2bc413c7a4913554ea6ed2c55474de6.  There's lots more code like that.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Wolfgang Jenkner]

On Sat, Jun 06 2015, Alan Mackenzie wrote:

> On the Linux console, there are a maximum of 256 glyphs which can be
> displayed (or 512 if you're prepared to do without half of the colours),
> each of which can be assigned to an arbitrary set of unicode characters.
> This limit is a hangover from video hardware made ~30 years ago, and it
> is a shame that it still persists, even on modern software generated
> video.

There are graphical (framebuffer based, no X needed) terminal emulators
for GNU/Linux which don't have this limitation on the number of glyphs,
in particular fbterm is quite nice, see the thread around

http://permalink.gmane.org/gmane.emacs.devel/143665

There's also the newer (and perhaps not so widely available?) kmscon.

(Also, FreeBSD now provides a very capable graphical console out of the
box.)

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Alan Mackenzie]

Hello, Wolfgang.

On Sun, Jun 07, 2015 at 03:17:13PM +0200, Wolfgang Jenkner wrote:
> On Sat, Jun 06 2015, Alan Mackenzie wrote:

> > On the Linux console, there are a maximum of 256 glyphs which can be
> > displayed (or 512 if you're prepared to do without half of the colours),
> > each of which can be assigned to an arbitrary set of unicode characters.
> > This limit is a hangover from video hardware made ~30 years ago, and it
> > is a shame that it still persists, even on modern software generated
> > video.

> There are graphical (framebuffer based, no X needed) terminal emulators
> for GNU/Linux which don't have this limitation on the number of glyphs,
> in particular fbterm is quite nice, see the thread around

> http://permalink.gmane.org/gmane.emacs.devel/143665

Is fbterm still a live project?  Its home page on googlecode doesn't
show any activity after 2010.

> There's also the newer (and perhaps not so widely available?) kmscon.

I think that's an X-based program, isn't it?

> (Also, FreeBSD now provides a very capable graphical console out of the
> box.)

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/02/2015 10:07 AM, Alan Mackenzie wrote:
> You're now
> changing Emacs so that its proper working is restricted to UTF-8
> environemnts

Emacs still works in non-UTF-8 environments.  That's the point of commit 
496bfe74990d6601d3584cb900643aa77d7b7a78, which causes Emacs to display 
curved quotes using straight ASCII approximations in environments that 
can't display curved quotes.

The abovementioned patch was needed regardless of the other recent 
quote-related changes to Emacs, because the Emacs info files typically 
contain curved quotes nowadays anyway, and users in 8-bit environments 
had trouble reading them otherwise.  To some extent this is an 
inevitable result of the rest of the world moving on, and of Emacs's old 
ASCII-only tradition having to adapt.

If you prefer a font that supports only Latin-9 characters I suggest 
setting the locale to en_GB.iso885915 instead of en_GB.utf8.  That way, 
Emacs shouldn't send undisplayable characters to your screen so you 
shouldn't see all those '?'s.  Likewise with other programs, as this 
issue isn't Emacs-specific.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon,  1 Jun 2015 00:39:21 -0700
> Cc: Paul Eggert <eggert@cs.ucla.edu>
> 
> Quote with curved single quotes, ‘like this’, in diagnostics
> generated from C code.  This mostly uses C11-style UTF-8 strings,
> e.g., u8"quote ‘like this’", with a backward compatibility macro
> u8 for pre-C11 compilers.

Thanks.

I see a couple of potential issues with these changes:

  . They use UTF-8 encoded characters, and so will require a suitable
    'coding:' cookie in the affected files, or some equivalent setting
    (perhaps in .dir-locals.el?), otherwise they might not be decoded
    correctly in non-UTF-8 locales.  Doing so might remove at least
    part of the need for using the u8 qualifier, I think.

  . I think these strings will have to be decoded before they are
    passed to 'error', as we never pass any unibyte strings to Lisp
    interfaces without decoding them first.  (We never used before any
    non-ASCII characters in messages created by C sources, so this
    issue never arose until now.)  Doing so would also remove the need
    for using the u8 qualifier, I think.

  . 'error' calls 'verror', which calls 'make_string' to actually
    produce the message string.  However, 'make_string' is not
    reliable enough wrt whether it produces unibyte or multibyte
    strings, so I suggest to make sure we produce a multibyte string
    from these error messages.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Glenn Morris]

Eli Zaretskii wrote:

>     'coding:' cookie in the affected files, or some equivalent setting
>     (perhaps in .dir-locals.el?),

Specifying coding: in dir-locals (still) doesn't work (bug#7169).
Even if it starts working tomorrow, people need to be able to edit those
files with older Emacs versions.

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/01/2015 07:34 AM, Eli Zaretskii wrote:
>  They use UTF-8 encoded characters, and so will require a suitable 
> 'coding:' cookie in the affected files, or some equivalent setting 
> (perhaps in .dir-locals.el?), otherwise they might not be decoded 
> correctly in non-UTF-8 locales.

Good point, and this raises a related issue with all text files in the 
Emacs repository that aren't ASCII.  The way I've been testing this sort 
of thing is to visit a source file in a Latin-9 locale, and if it is 
correctly decoded as UTF-8 then I don't bother with adding a coding: 
cookie.  To be honest I've been hoping that use of non-UTF-8 locales 
would be dying off among Emacs developers, so that we wouldn't need to 
worry about sprinkling coding: cookies everywhere.  But if it's really 
needed I suppose someone should make a pass over the source code....

> Doing so might remove at least part of the need for using the u8 
> qualifier, I think.

The u8 prefix is for C compilers, not for Emacs, and the C compilers 
won't know about coding: cookies.

Come to think of it, though, perhaps we can dispense with u8.  As far as 
I know u8 is needed only for MS-Windows compilers when the source code 
is in UTF-16 or suchlike but you want the string to be UTF-8.  Emacs 
source code is never in UTF-16 so this shouldn't be an issue.  Getting 
rid of u8 would remove the need for uLSQM and uRSQM which would be nice.

> 'error' calls 'verror', which calls 'make_string' to actually produce 
> the message string. However, 'make_string' is not reliable enough wrt 
> whether it produces unibyte or multibyte strings

Hmm, why isn't make_string reliable enough?  If the string is validly 
encoded UTF-8 (a safe assumption here), then make_string should produce 
a unibyte string if its ASCII only, and a multibyte string otherwise, 
and either way the string value should be OK. What am I missing?

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Eli Zaretskii]

> Date: Mon, 01 Jun 2015 10:55:44 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 20707@debbugs.gnu.org
> 
> On 06/01/2015 07:34 AM, Eli Zaretskii wrote:
> >  They use UTF-8 encoded characters, and so will require a suitable 
> > 'coding:' cookie in the affected files, or some equivalent setting 
> > (perhaps in .dir-locals.el?), otherwise they might not be decoded 
> > correctly in non-UTF-8 locales.
> 
> Good point, and this raises a related issue with all text files in the 
> Emacs repository that aren't ASCII.  The way I've been testing this sort 
> of thing is to visit a source file in a Latin-9 locale, and if it is 
> correctly decoded as UTF-8 then I don't bother with adding a coding: 
> cookie.

I'm not sure testing this in a single non-UTF-8 locale is enough.

> To be honest I've been hoping that use of non-UTF-8 locales 
> would be dying off among Emacs developers, so that we wouldn't need to 
> worry about sprinkling coding: cookies everywhere.

There are no UTF-8 locales on Windows, and I don't think there are any
plans to introduce them.

Perhaps teaching .dir-locals.el to support directory-wide default
encoding is the best approach.

> > Doing so might remove at least part of the need for using the u8 
> > qualifier, I think.
> 
> The u8 prefix is for C compilers, not for Emacs, and the C compilers 
> won't know about coding: cookies.

Right, but why do we want u8 there?  Isn't it to make sure the string
ends up in UTF-8 in the binary when the source code is encoded in
something other than UTF-8?

> Come to think of it, though, perhaps we can dispense with u8.  As far as 
> I know u8 is needed only for MS-Windows compilers when the source code 
> is in UTF-16 or suchlike but you want the string to be UTF-8.

We no longer support Microsoft compilers anyway.

> > 'error' calls 'verror', which calls 'make_string' to actually produce 
> > the message string. However, 'make_string' is not reliable enough wrt 
> > whether it produces unibyte or multibyte strings
> 
> Hmm, why isn't make_string reliable enough?  If the string is validly 
> encoded UTF-8 (a safe assumption here), then make_string should produce 
> a unibyte string if its ASCII only, and a multibyte string otherwise, 
> and either way the string value should be OK. What am I missing?

The convoluted logic of deciding when to produce a multibyte string
sometimes surprised me in the past, so I tend not to trust it.  We
know what we want in this case, so why not use make_multibyte_string
directly?

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Stefan Monnier]

> Good point, and this raises a related issue with all text files in the Emacs
> repository that aren't ASCII.

Not all: *.el files are explicitly defined as "using utf-8 unless
there's evidence otherwise".  IOW the locale is only consulted if the
file is not valid utf-8.


        Stefan

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Wolfgang Jenkner]

On Tue, Jun 09 2015, Alan Mackenzie wrote:

> Is fbterm still a live project?  Its home page on googlecode doesn't
> show any activity after 2010.

There's a new fork (apparently by the archlinux package maintainer) with
some activity at

https://github.com/izmntuk/fbterm

>> There's also the newer (and perhaps not so widely available?) kmscon.
>
> I think that's an X-based program, isn't it?

No, please see

http://www.freedesktop.org/wiki/Software/kmscon/

bug#20707: Use curved quoting in C-generated errors

[Andy Moreton]

On Wed 10 Jun 2015, Paul Eggert wrote:

> Alan Mackenzie wrote:
>
>> You want to
>> promote difficult-to-type and problematic-to-display characters to the
>> status of standard "working characters".
>
> The problems aren't that serious.  Display problems are limited to obsolete
> environments that hardly anybody uses because they're so awful, and even there
> we have workarounds.

Please don't project your own experience onto the wider emacs community.
Their usage patterns and experience are almost certainly different to
yours.

> And typing problems aren't a big deal in my Emacs
> environment: for left and right single quotes I normally type a single
> keystroke, without any control or shift or meta keys.  (This is because I use
> Electric Quote mode.)  Other typing environments are also available that work
> nearly as well (using Alt-[ and Alt-] for the two characters, if your Alt key
> works).

Again, you underestimate the difficulty of typing these characters in
other environments. C-x 8 RET LEFT DOUBLE QUOTATION MARK is a pig to
type compared to having a single keystroke for a character printed on a
keycap.

Having tried Electric Quote mode briefly:
a) `electric-quote-local-mode' should be named `electric-quote-mode'
b) `electric-quote-mode' should be named `global-electric-quote-mode'
   and possibly be implemented with `define-globalized-minor-mode'
c) The mode seems to convert ` to a curly quote regardless of context,
   but it would make more sense if it only converted matched pairs
   of `' style quotation.

> I'm not expecting everyone to use these keyboard methods right away.  There
> will be a transition period, and perhaps other, better methods of dealing this
> will emerge.  However, there should be no obstacle to people who do want to
> use those methods.

I have no objection to providing optional ways to use curved quotes
according to local tastes. however you are foisting this on the entire
emacs community as a default setting without having done enough work on
the compatibility issues.

>> I have a feeling you're intending to argue for making the use of curly
>> quotes in our Lisp files standard.
>
> Yes, of course.  It should be normal to type quotes as themselves in doc
> strings.  It's basic WYSIWYG.

You seem to have confused representation and presentation. It is
reasonable to allow presentation to use curved quote characters, even if
the underlying representation is still using `' style quoting. Changing
the representation seems to bring only problems with backward
compatibility.

>> Anyway, here's another idea for making curly quotes in lisp code
>> optional: an escaped 0x27 or 0x60 in a string should be translated by the
>> reader to the appropriate ASCII or curly quote, depending on the user's
>> configuration.  So a doc string might contain this:
>>
>>      \`foo-bar\'
>
> I considered doing that, but there were problems.  First, it would make doc
> strings harder to read.  For example, this:
>
> "Setting this attribute will also set the \`:family\',
> \`:foundry\', \`:width\', \`:height\', \`:weight\', and
> \`:slant\' attributes."
>
> is harder to read than this:
>
> "Setting this attribute will also set the ‘:family’, ‘:foundry’,
> ‘:width’, ‘:height’, ‘:weight’, and ‘:slant’ attributes."
>
> Second, the new escapes would cause mental overload with similar
> already-existing uses (e.g., ?\`, "\\`").  Third, and most serious, is that
> the new escapes would mean that string literals are not constants but are
> instead expressions whose values depend on runtime context, and this would
> affect everything: how the byte-compiler works, for example.
>
> To avoid the most serious problem, I considered a simpler idea: have the Lisp
> reader treat \` and \' as curved single quotes in strings.  However, this
> still has the basic problem of being hard to read.  It is needless work to add
> a hard-to-read and nearly-ubiquitous feature merely to cater to obsolete
> platforms.  It's simpler to use quote characters to represent themselves.

It is needless work to break existing systems by introducing a
deliberate regression.

If there is any translation, it should only happen with doc strings at
the point that they are prepared for display. Leaving the underlying
representation alone and only changng how those strings are presented is
far less likely to cause problems.

    AndyM

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> -    error ("Buffer name `%s' is in use", SDATA (name));
> +    error (u8"Buffer name ‘%s’ is in use", SDATA (name));

This led, of course, to a very, very long thread that I've just skimmed.
But I think the rough consensus here was that there wasn't much
enthusiasm for this, which explains why hasn't been worked on in five
years, as far as I can see.

So it seems unlikely to me that there'll be any further progress in this
bug report, and I'm closing it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no