GNU bug report logs -
#20385
Support curved quotes in doc strings
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Mon, 20 Apr 2015 18:40:04 UTC
Severity: wishlist
Tags: patch
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20385 in the body.
You can then email your comments to 20385 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Mon, 20 Apr 2015 18:40:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 20 Apr 2015 18:40:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Emacs's traditional doc string style has been to quote symbols
`like this'. This worked well on older terminals where ` and '
were symmetric quotes, but nowadays this quoting looks odd and
it's better to use apostrophe for single-quoted ASCII text.
Add support for quoting either way, suggesting the newer style.
* doc/lispref/tips.texi (Documentation Tips): Quote symbols
'like-this' as well as `like-this'. Recommend the former style.
* etc/NEWS: Mention this.
* lisp/cedet/srecode/texi.el (srecode-texi-texify-docstring):
* lisp/emacs-lisp/checkdoc.el (checkdoc-this-string-valid-engine):
* lisp/emacs-lisp/lisp-mode.el (lisp-el-font-lock-keywords-2)
(lisp-cl-font-lock-keywords-2):
* lisp/finder.el (finder-font-lock-keywords):
* lisp/gnus/gnus-art.el (gnus-button-alist):
* lisp/help-mode.el (help-xref-symbol-regexp)
(help-xref-info-regexp, help-xref-url-regexp):
* lisp/international/mule-cmds.el (help-xref-mule-regexp-template):
* lisp/wid-edit.el (widget-documentation-link-regexp):
Parse symbols quoted 'like-this' as well as `like-this'.
---
doc/lispref/tips.texi | 27 ++++++++++++++++-----------
etc/NEWS | 4 ++++
lisp/cedet/srecode/texi.el | 2 +-
lisp/emacs-lisp/checkdoc.el | 4 ++--
lisp/emacs-lisp/lisp-mode.el | 8 ++++----
lisp/finder.el | 2 +-
lisp/gnus/gnus-art.el | 8 ++++----
lisp/help-mode.el | 6 +++---
lisp/international/mule-cmds.el | 2 +-
lisp/wid-edit.el | 2 +-
10 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index cc1f0e4..8997249 100644
--- a/doc/lispref/tips.texi
+++ b/doc/lispref/tips.texi
@@ -658,17 +658,22 @@ starting double-quote is not part of the string!
@anchor{Docstring hyperlinks}
@item
When a documentation string refers to a Lisp symbol, write it as it
-would be printed (which usually means in lower case), with a grave
-accent @samp{`} before and apostrophe @samp{'} after it. There are
+would be printed (which usually means in lower case), with a
+apostrophe @samp{'} before and after it. There are
two exceptions: write @code{t} and @code{nil} without surrounding
-punctuation. For example: @samp{CODE can be `lambda', nil, or t.}
+punctuation. For example: @samp{CODE can be 'lambda', nil, or t.}
(In this manual, we use a different convention, with single-quotes
around symbols.)
+Documentation strings can also use an older single-quoting convention,
+which quotes symbols with grave accent @samp{`} and apostrophe, rather
+than with two apostrophes: @samp{`like-this'} rather than
+@samp{'like-this'}. This older single-quoting convention is not
+recommended for new documentation.
+
@cindex hyperlinks in documentation strings
Help mode automatically creates a hyperlink when a documentation string
-uses a symbol name between grave accent and apostrophe, if the symbol
-has either a
+uses a single-quoted symbol name, if the symbol has either a
function or a variable definition. You do not need to do anything
special to make use of this feature. However, when a symbol has both a
function definition and a variable definition, and you want to refer to
@@ -710,21 +715,21 @@ followed by the word @samp{face}. In that case, only the face
documentation will be shown, even if the symbol is also defined as a
variable or as a function.
-To make a hyperlink to Info documentation, write the name of the Info
-node (or anchor) between grave accent and apostrophe, preceded by
+To make a hyperlink to Info documentation, write the single-quoted
+name of the Info node (or anchor), preceded by
@samp{info node}, @samp{Info node}, @samp{info anchor} or @samp{Info
anchor}. The Info file name defaults to @samp{emacs}. For example,
@smallexample
-See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'.
+See Info node 'Font Lock' and Info node '(elisp)Font Lock Basics'.
@end smallexample
-Finally, to create a hyperlink to URLs, write the URL between grave
-accent and apostrophe, preceded by @samp{URL}. For example,
+Finally, to create a hyperlink to URLs, write the single-quoted URL,
+preceded by @samp{URL}. For example,
@smallexample
The home page for the GNU project has more information (see URL
-`http://www.gnu.org/').
+'http://www.gnu.org/').
@end smallexample
@item
diff --git a/etc/NEWS b/etc/NEWS
index a9c0d2e..278754e 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -791,6 +791,10 @@ name. The variable `system-name' is now obsolete.
*** New macros `thread-first' and `thread-last' allow threading a form
as the first or last argument of subsequent forms.
+** Documentation strings now support single-quoting 'like-this'
+in addition to the older style `like-this'. The newer style looks
+better on most modern displays, and is recommended for new code.
+
+++
** Time-related changes:
diff --git a/lisp/cedet/srecode/texi.el b/lisp/cedet/srecode/texi.el
index 5c3f21c..d03203d 100644
--- a/lisp/cedet/srecode/texi.el
+++ b/lisp/cedet/srecode/texi.el
@@ -253,7 +253,7 @@ that class.
[ stuff ] => @code{[ stuff ]}
Key => @kbd{Key} (key is C\\-h, M\\-h, SPC, RET, TAB and the like)
... => @dots{}"
- (while (string-match "`\\([-a-zA-Z0-9<>.]+\\)'" string)
+ (while (string-match "['`]\\([-a-zA-Z0-9<>.]+\\)'" string)
(let* ((vs (substring string (match-beginning 1) (match-end 1)))
(v (intern-soft vs)))
(setq string
diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
index 777fed0..d861da9 100644
--- a/lisp/emacs-lisp/checkdoc.el
+++ b/lisp/emacs-lisp/checkdoc.el
@@ -1554,7 +1554,7 @@ mouse-[0-3]\\)\\)\\>"))
(save-excursion
(let ((case-fold-search t)
(ret nil) mb me)
- (while (and (re-search-forward "`\\(\\sw\\(\\sw\\|\\s_\\)+\\)'" e t)
+ (while (and (re-search-forward "['`]\\(\\sw\\(\\sw\\|\\s_\\)+\\)'" e t)
(not ret))
(let* ((ms1 (match-string 1))
(sym (intern-soft ms1)))
@@ -1824,7 +1824,7 @@ Replace with \"%s\"? " original replace)
nil)))
;; t and nil case
(save-excursion
- (if (re-search-forward "\\(`\\(t\\|nil\\)'\\)" e t)
+ (if (re-search-forward "\\(['`]\\(t\\|nil\\)'\\)" e t)
(if (checkdoc-autofix-ask-replace
(match-beginning 1) (match-end 1)
(format "%s should not appear in quotes. Remove? "
diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
index 26a21d5..bfdd41e 100644
--- a/lisp/emacs-lisp/lisp-mode.el
+++ b/lisp/emacs-lisp/lisp-mode.el
@@ -405,8 +405,8 @@
;; Words inside \\[] tend to be for `substitute-command-keys'.
("\\\\\\\\\\[\\(\\(?:\\sw\\|\\s_\\)+\\)\\]"
(1 font-lock-constant-face prepend))
- ;; Words inside `' tend to be symbol names.
- ("`\\(\\(?:\\sw\\|\\s_\\)\\(?:\\sw\\|\\s_\\)+\\)'"
+ ;; Words inside '' and `' tend to be symbol names.
+ ("['`]\\(\\(?:\\sw\\|\\s_\\)\\(?:\\sw\\|\\s_\\)+\\)'"
(1 font-lock-constant-face prepend))
;; Constant values.
("\\_<:\\(?:\\sw\\|\\s_\\)+\\_>" 0 font-lock-builtin-face)
@@ -454,8 +454,8 @@
;; Erroneous structures.
(,(concat "(" cl-errs-re "\\_>")
(1 font-lock-warning-face))
- ;; Words inside `' tend to be symbol names.
- ("`\\(\\(?:\\sw\\|\\s_\\)\\(?:\\sw\\|\\s_\\)+\\)'"
+ ;; Words inside '' and `' tend to be symbol names.
+ ("['`]\\(\\(?:\\sw\\|\\s_\\)\\(?:\\sw\\|\\s_\\)+\\)'"
(1 font-lock-constant-face prepend))
;; Constant values.
("\\_<:\\(?:\\sw\\|\\s_\\)+\\_>" 0 font-lock-builtin-face)
diff --git a/lisp/finder.el b/lisp/finder.el
index 47fab3c..847dccc 100644
--- a/lisp/finder.el
+++ b/lisp/finder.el
@@ -115,7 +115,7 @@ Each element has the form (KEYWORD . DESCRIPTION).")
"Syntax table used while in `finder-mode'.")
(defvar finder-font-lock-keywords
- '(("`\\([^'`]+\\)'" 1 font-lock-constant-face prepend))
+ '(("['`]\\([^'`]+\\)'" 1 font-lock-constant-face prepend))
"Font-lock keywords for Finder mode.")
(defvar finder-headmark nil
diff --git a/lisp/gnus/gnus-art.el b/lisp/gnus/gnus-art.el
index 14f9adc..4560a0e 100644
--- a/lisp/gnus/gnus-art.el
+++ b/lisp/gnus/gnus-art.el
@@ -7828,11 +7828,11 @@ positives are possible."
("/\\([a-z][-a-z0-9]+\\.el\\)\\>[^.?]"
;; Exclude [.?] for URLs in gmane.emacs.cvs
1 (>= gnus-button-emacs-level 8) gnus-button-handle-library 1)
- ("`\\([a-z][-a-z0-9]+\\.el\\)'"
+ ("['`]\\([a-z][-a-z0-9]+\\.el\\)'"
1 (>= gnus-button-emacs-level 8) gnus-button-handle-library 1)
- ("`\\([a-z][a-z0-9]+-[a-z0-9]+-[-a-z0-9]*[a-z]\\|\\(gnus\\|message\\)-[-a-z]+\\)'"
+ ("['`]\\([a-z][a-z0-9]+-[a-z0-9]+-[-a-z0-9]*[a-z]\\|\\(gnus\\|message\\)-[-a-z]+\\)'"
0 (>= gnus-button-emacs-level 8) gnus-button-handle-symbol 1)
- ("`\\([a-z][a-z0-9]+-[a-z]+\\)'"
+ ("['`]\\([a-z][a-z0-9]+-[a-z]+\\)'"
0 (>= gnus-button-emacs-level 9) gnus-button-handle-symbol 1)
("(setq[ \t\n]+\\([a-z][a-z0-9]+-[-a-z0-9]+\\)[ \t\n]+.+)"
1 (>= gnus-button-emacs-level 7) gnus-button-handle-describe-variable 1)
@@ -7842,7 +7842,7 @@ positives are possible."
0 (>= gnus-button-emacs-level 1) gnus-button-handle-describe-function 2)
("\\b\\(C-h\\|<?[Ff]1>?\\)[ \t\n]+v[ \t\n]+\\([^ \t\n]+\\)[ \t\n]+RET\\>"
0 (>= gnus-button-emacs-level 1) gnus-button-handle-describe-variable 2)
- ("`\\(\\(C-h\\|<?[Ff]1>?\\)[ \t\n]+k[ \t\n]+\\([^']+\\)\\)'"
+ ("['`]\\(\\(C-h\\|<?[Ff]1>?\\)[ \t\n]+k[ \t\n]+\\([^']+\\)\\)'"
;; Unlike the other regexps we really have to require quoting
;; here to determine where it ends.
1 (>= gnus-button-emacs-level 1) gnus-button-handle-describe-key 3)
diff --git a/lisp/help-mode.el b/lisp/help-mode.el
index d6679e9..13e5ed4 100644
--- a/lisp/help-mode.el
+++ b/lisp/help-mode.el
@@ -322,7 +322,7 @@ Commands:
"\\(source \\(?:code \\)?\\(?:of\\|for\\)\\)\\)"
"[ \t\n]+\\)?"
;; Note starting with word-syntax character:
- "`\\(\\sw\\(\\sw\\|\\s_\\)+\\)'"))
+ "['`]\\(\\sw\\(\\sw\\|\\s_\\)+\\)'"))
"Regexp matching doc string references to symbols.
The words preceding the quoted symbol can be used in doc strings to
@@ -337,11 +337,11 @@ when help commands related to multilingual environment (e.g.,
(defconst help-xref-info-regexp
- (purecopy "\\<[Ii]nfo[ \t\n]+\\(node\\|anchor\\)[ \t\n]+`\\([^']+\\)'")
+ (purecopy "\\<[Ii]nfo[ \t\n]+\\(node\\|anchor\\)[ \t\n]+['`]\\([^']+\\)'")
"Regexp matching doc string references to an Info node.")
(defconst help-xref-url-regexp
- (purecopy "\\<[Uu][Rr][Ll][ \t\n]+`\\([^']+\\)'")
+ (purecopy "\\<[Uu][Rr][Ll][ \t\n]+['`]\\([^']+\\)'")
"Regexp matching doc string references to a URL.")
;;;###autoload
diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el
index cca659f..0856995 100644
--- a/lisp/international/mule-cmds.el
+++ b/lisp/international/mule-cmds.el
@@ -177,7 +177,7 @@
"\\(charset\\)"
"\\)\\s-+\\)?"
;; Note starting with word-syntax character:
- "`\\(\\sw\\(\\sw\\|\\s_\\)+\\)'")))
+ "['`]\\(\\sw\\(\\sw\\|\\s_\\)+\\)'")))
(defun coding-system-change-eol-conversion (coding-system eol-type)
"Return a coding system which differs from CODING-SYSTEM in EOL conversion.
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index 04a900f..9e1c895 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -2855,7 +2855,7 @@ The following properties have special meanings for this widget:
:type 'boolean
:group 'widget-documentation)
-(defcustom widget-documentation-link-regexp "`\\([^\n`' ]+\\)'"
+(defcustom widget-documentation-link-regexp "['`]\\([^\n`' ]+\\)'"
"Regexp for matching potential links in documentation strings.
The first group should be the link itself."
:type 'regexp
--
2.1.0
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Mon, 20 Apr 2015 19:39:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Emacs's traditional doc string style has been to quote symbols
> `like this'. This worked well on older terminals where ` and '
> were symmetric quotes, but nowadays this quoting looks odd and
> it's better to use apostrophe for single-quoted ASCII text.
> Add support for quoting either way, suggesting the newer style.
I'm not sure I like this. Yet, I don't like the look for `...' either.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Mon, 20 Apr 2015 20:17:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Emacs's traditional doc string style has been to quote symbols
> `like this'. This worked well on older terminals where ` and '
> were symmetric quotes,
And it has worked well in GUI Emacs as well. And it still does.
And it supports simple highlighting, and simple searching, which
are very helpful to users.
This notation is not just some primitive, prehistoric way of setting
off symbols and other code. It is a thoroughly modern way of doing
that. Especially for a context that is plain text and that involves
simple (and complex) editing operations.
> but nowadays this quoting looks odd
No, it doesn't. It doesn't look more odd than it did pre-"nowadays".
> and it's better to use apostrophe for single-quoted ASCII text.
"It's better"? That's all you can say in support of this change?
No reason given?
Or was your "nowdays this quoting looks odd" to you the reason?
If so, that's a feeble reason to lose helpful and simple
highlighting, and to change a longstanding convention.
> Add support for quoting either way, suggesting the newer style.
> ... Quote symbols 'like-this' as well as `like-this'.
> Recommend the former style.
Please don't. Don't even add support for '...' quoting. It will
just get in the way. Of users. Of tools.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 00:19:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 04/20/2015 12:37 PM, Stefan Monnier wrote:
> I don't like the look for `...' either.
Yes, it's a problem.
For better looks we can use curved single quotes, e.g., instead of the current:
Indent each line via `indent-according-to-mode'.
we can use:
Indent each line via ‘indent-according-to-mode’.
Curved single quotes nest better than apostrophe pairs, look better than grave
accent + apostrophe, and avoid the "misuse" of grave accent for quoting. A
revised patch is attached.
[0001-Support-quoting-like-this-in-doc-strings.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 00:54:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> For better looks we can use curved single quotes, e.g., instead of the
> current:
> Indent each line via `indent-according-to-mode'.
> we can use:
> Indent each line via ‘indent-according-to-mode’.
>
> Curved single quotes nest better than apostrophe pairs, look better than
> grave accent + apostrophe, and avoid the "misuse" of grave accent for
> quoting. A revised patch is attached.
Again, please don't. It is much simpler to search for ` and ', which
are available directly from most keyboards, than it is to search for
‘ and ’.
Please find something else you are interested in, to improve. ;-)
There are plenty of thing to work on, to improve Emacs. Tons of
bugs reported, to start with...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 01:15:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Indent each line via ‘indent-according-to-mode’.
Yes, I like the way it looks and the way it's even less ambiguous than
`...'. So I think it's the *right* solution.
But I've resisted going this way so far because of the difficulty to
type those things.
IOW, I think we need some clever way to type them in with very little effort.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 01:32:03 GMT)
Full text and
rfc822 format available.
Message #23 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> > Indent each line via ‘indent-according-to-mode’.
>
> Yes, I like the way it looks and the way it's even less ambiguous than
> `...'. So I think it's the *right* solution. But I've resisted going
> this way so far because of the difficulty to type those things. IOW,
> I think we need some clever way to type them in with very little effort.
Typing them is one problem, for sure. Then there is the problem
of using them in Lisp (and other programming language) code.
Will Emacs Lisp start using ‘ the same way it uses `, and ’ the same
way it uses '? If not, then some of the ` marks in the manual will
change to ‘ and some not, etc. It's doable, but you would do well
to imagine the repercussions for users before going down that road.
And that's only once you've solved the "clever way to type them"
question.
I'd suggest not worrying about this problem now - it will be there
when you're done fixing other things. ;-) Things like making it
possible in Isearch to handle certain groups of chars (‘ and `,
for instance) as equivalence classes. That is a harder nut to
crack, but also one that is genuinely worthwhile cracking.
(And no, that is not related to `...' -> ‘...’. Just mentioning
it as something more important to fix, with a bigger payoff.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 01:59:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Will Emacs Lisp start using ‘ the same way it uses `, and ’ the same
> way it uses '?
Of course not.
> I'd suggest not worrying about this problem now - it will be there
> when you're done fixing other things. ;-) Things like making it
> possible in Isearch to handle certain groups of chars (‘ and `,
> for instance) as equivalence classes. That is a harder nut to
> crack, but also one that is genuinely worthwhile cracking.
Agreed.
Stefan "Anxiously waiting for your patch"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 03:47:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> we need some clever way to type them in with very little effort.
Something like smart-quotes-mode, say?
https://github.com/gareth-rees/smart-quotes
In smart-quotes-mode, if you type this:
Quoting 'like-this' should look nice.
this is the text you've entered:
Quoting ‘like-this’ should look nice.
It'd be nice if Emacs had something like that for typing doc strings, along with
the cleverer searches Drew mentioned. However, I'm leery of making nifty
features prerequisites for the most recently proposed patch, as that's a recipe
for inaction. Although the proposed patch's new functionality may be harder to
use than we'd like, progress is made a step at a time and we can add more nifty
features later.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 14:53:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 20 Apr 2015 20:45:55 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: 20385 <at> debbugs.gnu.org
>
> Stefan Monnier wrote:
> > we need some clever way to type them in with very little effort.
>
> Something like smart-quotes-mode, say?
>
> https://github.com/gareth-rees/smart-quotes
The solution that mode suggests for spell-checking will not work well
with modern spellers (aspell and hunspell), because they don't have
the curly apostrophe/quote character in their *.aff files' rules, like
they do with the ASCII apostrophe.
So if we want this to become our default, we need changes in
ispell.el, to replace ’ with ' before we sent it to the speller. Or
maybe recommend users to install *.aff files that already support ’,
assuming such dictionaries exist.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 18:07:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> So if we want this to become our default, we need changes in
> ispell.el, to replace ’ with ' before we sent it to the speller. Or
> maybe recommend users to install *.aff files that already support ’,
> assuming such dictionaries exist.
Another approach would be to keep `...' in the files, but use
redisplay/font-lock tricks to display them ‘like-this’.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 18:26:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 20385 <at> debbugs.gnu.org
> Date: Tue, 21 Apr 2015 14:04:59 -0400
>
> > So if we want this to become our default, we need changes in
> > ispell.el, to replace ’ with ' before we sent it to the speller. Or
> > maybe recommend users to install *.aff files that already support ’,
> > assuming such dictionaries exist.
>
> Another approach would be to keep `...' in the files, but use
> redisplay/font-lock tricks to display them ‘like-this’.
Which tricks did you have in mind? Overlays?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 18:37:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 20385 <at> debbugs.gnu.org (full text, mbox):
>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
[…]
> But I've resisted going this way so far because of the difficulty to
> type those things. IOW, I think we need some clever way to type them
> in with very little effort.
Apart from the already suggested smart-quotes-mode, there’s this
bit I personally use. (See also bug#16082.)
(eval-after-load 'iso-transl
'(iso-transl-define-keys
'(("\"[" . [?“]) ("\"]" . [?”])
("'[" . [?‘]) ("']" . [?’]))))
key binding
――― ―――――――
A-' [ ‘
A-' ] ’
A-" [ “
A-" ] ”
C-x 8 ' [ ‘
C-x 8 ' ] ’
C-x 8 " [ “
C-x 8 " ] ”
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 18:43:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> From: Ivan Shmakov <ivan <at> siamics.net>
> Date: Tue, 21 Apr 2015 18:35:53 +0000
>
> Apart from the already suggested smart-quotes-mode, there’s this
> bit I personally use. (See also bug#16082.)
>
> (eval-after-load 'iso-transl
> '(iso-transl-define-keys
> '(("\"[" . [?“]) ("\"]" . [?”])
> ("'[" . [?‘]) ("']" . [?’]))))
>
> key binding
> ――― ―――――――
> A-' [ ‘
> A-' ] ’
> A-" [ “
> A-" ] ”
> C-x 8 ' [ ‘
> C-x 8 ' ] ’
> C-x 8 " [ “
> C-x 8 " ] ”
Why not do what texinfo.el does to insert ``..'' when you press " ?
Isn't that simpler and easier on the user?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 18:45:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier writes:
>> So if we want this to become our default, we need changes in
>> ispell.el, to replace ’ with ' before we sent it to the speller. Or
>> maybe recommend users to install *.aff files that already support ’,
>> assuming such dictionaries exist.
>
> Another approach would be to keep `...' in the files, but use
> redisplay/font-lock tricks to display them ‘like-this’.
I don't see the need for such a change. Is the character ` that ugly?
The way it currently is looks fine to me (and reminds me of the usage of
backquotes in Markdown).
Nico
--
Nicolas Petton
http://nicolas-petton.fr
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 19:35:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Which tricks did you have in mind? Overlays?
`display' properties.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 19:38:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 20385 <at> debbugs.gnu.org (full text, mbox):
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>>> From: Ivan Shmakov Date: Tue, 21 Apr 2015 18:35:53 +0000
[…]
>> C-x 8 " [ “
>> C-x 8 " ] ”
> Why not do what texinfo.el does to insert ``..'' when you press " ?
> Isn't that simpler and easier on the user?
Personally, I prefer for these characters to be available all
around Emacs, so even if there’re simpler means to enter them in
some modes, I’d still need 'iso-transl (or the likes of it)
elsewhere.
Otherwise, given that texinfo-insert-quote seems to properly
handle “code sample” vs. “prose” contexts, – yes, this may come
to be a good enough solution for the problem at hand.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 19:51:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu, 20385 <at> debbugs.gnu.org
> Date: Tue, 21 Apr 2015 15:34:04 -0400
>
> > Which tricks did you have in mind? Overlays?
>
> `display' properties.
Sounds gross.
Moreover, AFAIU people who want to see ‘this’ actually _want_ to see
the u+2018 etc. characters in the file/buffer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 19:53:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> From: Ivan Shmakov <ivan <at> siamics.net>
> Date: Tue, 21 Apr 2015 19:37:48 +0000
>
> >>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>>>> From: Ivan Shmakov Date: Tue, 21 Apr 2015 18:35:53 +0000
>
> […]
>
> >> C-x 8 " [ “
> >> C-x 8 " ] ”
>
> > Why not do what texinfo.el does to insert ``..'' when you press " ?
> > Isn't that simpler and easier on the user?
>
> Personally, I prefer for these characters to be available all
> around Emacs, so even if there’re simpler means to enter them in
> some modes, I’d still need 'iso-transl (or the likes of it)
> elsewhere.
I wasn't necessarily talking about "some modes". You can make this
customization global, can't you?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 20:03:03 GMT)
Full text and
rfc822 format available.
Message #62 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/21/2015 10:50 PM, Eli Zaretskii wrote:
> Moreover, AFAIU people who want to see ‘this’ actually _want_ to see
> the u+2018 etc. characters in the file/buffer.
That's no problem: fontify the source files like that, too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 21 Apr 2015 20:31:03 GMT)
Full text and
rfc822 format available.
Message #65 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> I don't see the need for such a change. Is the character ` that ugly?
The need is not terribly high, no.
But yes, `...' is ugly. It used to be pretty back in the XFree86<4.0
days, when they were symmetric, but now they're pretty ugly.
> The way it currently is looks fine to me (and reminds me of the usage of
> backquotes in Markdown).
I've lived with it for 20 years and could live with it another
20 years. But if someone can provide a good replacement, I'll
accept it.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 22 Apr 2015 00:50:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> But yes, `...' is ugly. It used to be pretty back in the XFree86<4.0
> days, when they were symmetric
And before that, some character-based video display terminals displayed `...'
nicely. There was good technical justification for this, as the 1965 draft
definition of ASCII said 0x27 was the code for an opening single quotation mark.
However, standardization headed in a different direction long ago and nowadays
`...' is ugly everywhere. For more of the history, please see:
Kuhn M. ASCII and Unicode quotation marks (2007).
http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 22 Apr 2015 07:01:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 21 Apr 2015 23:01:55 +0300
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 20385 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
>
> On 04/21/2015 10:50 PM, Eli Zaretskii wrote:
>
> > Moreover, AFAIU people who want to see ‘this’ actually _want_ to see
> > the u+2018 etc. characters in the file/buffer.
>
> That's no problem: fontify the source files like that, too.
No, they want the characters to be in the file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 22 Apr 2015 13:53:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 20385 <at> debbugs.gnu.org (full text, mbox):
I will add that one increasingly important use of `...' is that
doc gets copied and pasted to other, non-Emacs environments.
You might think that `...' is "ugly" (and that is the ONLY
reason that's been given so far for changing it), but it has
the distinct advantage that it is a unique way of quoting
that separates itself from both strings ("...") and ordinary
text quoting (curly quotes, double and single).
If you post doc pieces into a context such as Stack Exchange,
for example, you need only change the ' in `...' to `, to
have that new context also, like Emacs, treat the quoted
sexp specially - not a ordinary quoted text. That is, SE
uses `...` instead of `...', but it does the same thing
Emacs does, to make the result stand out as code and not as
just any old quoted text.
If you change `...' to ordinary curly quoting, you lose
distinguishing what it quotes as code.
Just one more consideration, another reason why the proposed
change is a bad idea, IMHO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 22 Apr 2015 14:00:05 GMT)
Full text and
rfc822 format available.
Message #77 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Drew Adams writes:
> I will add that one increasingly important use of `...' is that
> doc gets copied and pasted to other, non-Emacs environments.
>
> You might think that `...' is "ugly" (and that is the ONLY
> reason that's been given so far for changing it), but it has
> the distinct advantage that it is a unique way of quoting
> that separates itself from both strings ("...") and ordinary
> text quoting (curly quotes, double and single).
>
> If you post doc pieces into a context such as Stack Exchange,
> for example, you need only change the ' in `...' to `, to
> have that new context also, like Emacs, treat the quoted
> sexp specially - not a ordinary quoted text. That is, SE
> uses `...` instead of `...', but it does the same thing
> Emacs does, to make the result stand out as code and not as
> just any old quoted text.
>
> If you change `...' to ordinary curly quoting, you lose
> distinguishing what it quotes as code.
>
> Just one more consideration, another reason why the proposed
> change is a bad idea, IMHO.
I agree with you.
Maybe a compromise could be to add as an alternative syntax `...` (just
like SE or Markdown)? It would then fix the unbalanced quotes issue.
Nico
--
Nicolas Petton
http://nicolas-petton.fr
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 22 Apr 2015 14:54:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> > I will add that one increasingly important use of `...' is that
> > doc gets copied and pasted to other, non-Emacs environments.
> >
> > You might think that `...' is "ugly" (and that is the ONLY
> > reason that's been given so far for changing it), but it has
> > the distinct advantage that it is a unique way of quoting
> > that separates itself from both strings ("...") and ordinary
> > text quoting (curly quotes, double and single).
> >
> > If you post doc pieces into a context such as Stack Exchange,
> > for example, you need only change the ' in `...' to `, to
> > have that new context also, like Emacs, treat the quoted
> > sexp specially - not a ordinary quoted text. That is, SE
> > uses `...` instead of `...', but it does the same thing
> > Emacs does, to make the result stand out as code and not as
> > just any old quoted text.
> >
> > If you change `...' to ordinary curly quoting, you lose
> > distinguishing what it quotes as code.
> >
> > Just one more consideration, another reason why the proposed
> > change is a bad idea, IMHO.
>
> I agree with you.
>
> Maybe a compromise could be to add as an alternative syntax `...`
> (just like SE or Markdown)? It would then fix the unbalanced quotes issue.
1. `...` is not as simple to parse (e.g. using regexps) for Emacs
highlighting etc.
2. But I also realize that I might not have been as clear in that post
as I should have been. It's not only about the (increasing) need
to be able to copy doc and paste it to other, non-Emacs environments.
The more important point is that Emacs uses `...' as a different
kind of quoting from ordinary text quoting. It is Emacs's way of
quoting code that is inline (i.e., within ordinary text).
In other doc systems one might use wrap such inline code with, say,
and XML element: <CodeInLine>(forward-char 3)</CodeInLine>. For
technical doc related to programming, there is typically *some* way
to set off inline code bits, to indicate that they are code, whether
they are keywords or pieces of programs. Emacs's way has been `...'.
And IMHO, it is a very good way. Very simple, and amenable to very
simple regexp identification and thus highlighting & retrieval.
If Emacs at some point decides to switch to another code-quoting
mechanism, that's one thing. But what it definitely should NOT do,
IMO, is to lose code quoting - lose talking about code from a meta
level, and just quote code bits normally, so they become confused
with ordinary text quoting.
That was really the point I was trying to make in my last point.
`...' is for code. Changing that to '...' loses the ability to
distinguish code from anything else being quoted normally.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 22 Apr 2015 23:37:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Drew Adams wrote:
> If Emacs at some point decides to switch to another code-quoting
> mechanism, that's one thing. But what it definitely should NOT do,
> IMO, is to lose code quoting
Yes, that makes sense. The latest iteration of the proposal does that, by
suggesting that doc strings use curved single quotes ‘like-this’ to quote code.
This mechanism is already used in the Emacs 24.5 info files, and it works well
there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 22 Apr 2015 23:38:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> So if we want this to become our default, we need changes in
> ispell.el, to replace ’ with ' before we sent it to the speller.
Although a change like that might make sense, it appears to go beyond what's
needed for doc strings. I was thinking of something more modest: change Emacs
so that if you're editing an Elisp or C string, then when you type `like-this'
it's by default changed to ‘like-this’. This would not need to happen
everywhere, but it would be the default when editing Emacs source code because
we'd put the appropriate setting into .dir-locals.el.
Or were you thinking about spell-checking doc strings? If so, I don't see how
changing the quoting style affects how the spell-checker works. It wouldn't
affect the way I spell-check code, anyway. Could you give an example?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 00:24:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert writes:
> Drew Adams wrote:
>> If Emacs at some point decides to switch to another code-quoting
>> mechanism, that's one thing. But what it definitely should NOT do,
>> IMO, is to lose code quoting
>
> Yes, that makes sense. The latest iteration of the proposal does that, by
> suggesting that doc strings use curved single quotes ‘like-this’ to quote code.
> This mechanism is already used in the Emacs 24.5 info files, and it works well
> there.
I don't understand how this would better than using backquotes
`like-this` (or even simply keeping it `like-this'):
- Isn't the curved single quote character *really* hard to type? (I
don't think I even know how to type it on my keyboard).
- Also, aren't curved single quotes only used to display code quotation
in compiled info files, not in .texinfo sources (by this I mean that
nobody actually has to type curved quotes)?
Nico
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 02:20:04 GMT)
Full text and
rfc822 format available.
Message #92 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> > If Emacs at some point decides to switch to another code-quoting
> > mechanism, that's one thing. But what it definitely should NOT
> > do, IMO, is to lose code quoting
>
> Yes, that makes sense. The latest iteration of the proposal does
> that, by suggesting that doc strings use curved single quotes
> ‘like-this’ to quote code. This mechanism is already used in the
> Emacs 24.5 info files, and it works well there.
Huh? You say that you agree, that what I say makes sense. And then
you say that ‘...’ is a solution! That's precisely what I'm saying
does *not* work. If you paste that into any context where curly
quoting is used for ordinary text (which - nowadays, as you would say -
means most ordinary-text contexts) then you lose the special quoting
of code.
Whether curly quotes are single or double is irrelevant: both are
used in ordinary situations to quote ordinary text. Neither is
something special for quoting code.
See http://en.wikipedia.org/wiki/Quotation_mark. Note, in particular
(in case this was something you were confused about), that British
and American usages tends to be reversed wrt which curly quotes,
single or double, are used at the first level:
In American English, double quotes are used normally (the "primary"
style). If quote marks are used inside another pair of quote marks,
then single quotes are used as the "secondary" style. For example:
"Didn't she say 'I like red best' when asked her favorite wine?"
he wondered to himself.
If another set of quotes is nested, double quotes are used again,
and they continue to alternate as necessary (though this is rarely
done). British English tends to have the opposite convention –
single quotes are primary, and double quotes are secondary.
Different varieties of English have different rules regarding
whether neighboring punctuation should be written inside or
outside the quotation marks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 06:31:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 22 Apr 2015 16:37:14 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 20385 <at> debbugs.gnu.org
>
> Eli Zaretskii wrote:
>
> > So if we want this to become our default, we need changes in
> > ispell.el, to replace ’ with ' before we sent it to the speller.
>
> Although a change like that might make sense, it appears to go beyond what's
> needed for doc strings.
The suggestion to which I responded was to use
https://github.com/gareth-rees/smart-quotes, which is a minor mode
that is not limited to doc strings. Moreover, it is not limited to
quoting, AFAIU, it will also replace lone apostrophes with ’.
> I was thinking of something more modest: change Emacs
> so that if you're editing an Elisp or C string, then when you type `like-this'
> it's by default changed to ‘like-this’.
I don't think you describe smart-quotes, you describe some other
similar feature. I was talking about smart-quotes, and especially
about making it default in text modes.
> Or were you thinking about spell-checking doc strings?
If you are considering a feature similar to smart-quotes, especially
if it's not limited to quoting, then yes, spell-checking doc strings
will hit the same problem.
> If so, I don't see how changing the quoting style affects how the
> spell-checker works. It wouldn't affect the way I spell-check code,
> anyway. Could you give an example?
If this is limited to quoting, I don't think it will affect
spell-checking. But that's not what I was talking about.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 06:46:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Nicolas Petton wrote:
> I don't understand how this would better than using backquotes
> `like-this`
Quoting `like-this` still looks ugly, and still misuses grave accent in a way
that's confusing for people not accustomed to the style. It's also harder to
parse unambiguously than a matching pair of distinct quote characters.
> - Isn't the curved single quote character *really* hard to type?
Yes, and Stefan raised that point too. It should be reasonably easy to fix this
(though I haven't coded it up yet).
> - aren't curved single quotes only used to display code quotation
> in compiled info files, not in .texinfo sources
Yes, and partly because of this info-look.el now handles curved single quotes.
These sorts of changes are inevitable (and shouldn't be that hard) when
accommodating Emacs to common quoting styles.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 06:46:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Drew Adams wrote:
> British
> and American usages tends to be reversed wrt which curly quotes,
> single or double, are used at the first level:
Sure, and the tradition in many GNU projects is to use American-style quoting
for regular English text, and British-style quoting for code. For example, the
Emacs 24.5 manual's info files quote ordinary text like this:
Emacs occupies a “graphical window”
and quote code like this:
A description of an imaginary variable, ‘electric-future-map’.
Changing doc strings to look like the latter will better implement the
longstanding style for documentation in GNU projects. It's what quoting `like
this' was originally intended to do (and *did* do, with circa-1965 draft ASCII).
It's an eminently reasonable way to quote code in documentation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 09:15:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert writes:
> Nicolas Petton wrote:
>> I don't understand how this would better than using backquotes
>> `like-this`
>
> Quoting `like-this` still looks ugly
I guess that's just a matter of taste then. I think it's perfectly
fine, and FWIW it's also a very common way to quote code nowadays.
>> - Isn't the curved single quote character *really* hard to type?
>
> Yes, and Stefan raised that point too. It should be reasonably easy to fix this
> (though I haven't coded it up yet).
How? By inserting curved quotes when the user types a single quote (or
another character) in a string in Elisp code? Wouldn't that be a big
issue in other modes (or even outside of Emacs)?
Nico
--
Nicolas Petton
http://nicolas-petton.fr
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 10:23:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Nicolas Petton wrote:
> inserting curved quotes when the user types a single quote (or
> another character) in a string in Elisp code? Wouldn't that be a big
> issue in other modes (or even outside of Emacs)?
I don't see why it would need to affect other modes, or affect programs other
than Emacs. The idea is to to make it easier for Elisp programmers to put
curved single quotes into doc strings. Of course there is a more-general
problem of making it easier to use curved quotes in arbitrary contexts
(including contexts outside Emacs), but that problem needn't be solved here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 11:16:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert writes:
> Nicolas Petton wrote:
>> inserting curved quotes when the user types a single quote (or
>> another character) in a string in Elisp code? Wouldn't that be a big
>> issue in other modes (or even outside of Emacs)?
>
> I don't see why it would need to affect other modes, or affect
> programs other than Emacs. The idea is to to make it easier for Elisp
> programmers to put curved single quotes into doc strings.
It's not about affecting other modes, but the fact that quoting code in
elisp docstrings would only be reasonably doable from Emacs' elisp mode,
since curved quotes aren't easy to type. That could be a problem in
cases like answering elisp question on SE, in an email, etc.
> Of course there is a more-general problem of making it easier to use
> curved quotes in arbitrary contexts (including contexts outside
> Emacs), but that problem needn't be solved here.
I don't think it's worth it to make it unnecessarily hard to write
elisp docstrings anywhere else than in emacs-lisp-mode in Emacs.
It might look like I insist, but something `like-this` looks more than
ok to me:
- it is a really common practice nowadays and most people understand
what it means. Many projects use Markdown in their README for
example;
- it doesn't require to use a special character (understand characters
that one cannot easily type on a QWERTY keyboard);
- it fixes the "unbalanced" quotes issue that you raised as well as
using a curved single quote.
But again, I don't see the need for a change at all, and I have never
seen how quoted code looked like in older terminals.
Cheers,
Nico
--
Nicolas Petton
http://nicolas-petton.fr
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 12:12:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 20385 <at> debbugs.gnu.org (full text, mbox):
In article <mailman.1406.1429745828.904.bug-gnu-emacs <at> gnu.org> you wrote:
> Drew Adams wrote:
>> If Emacs at some point decides to switch to another code-quoting
>> mechanism, that's one thing. But what it definitely should NOT do,
>> IMO, is to lose code quoting
> Yes, that makes sense. The latest iteration of the proposal does that, by
> suggesting that doc strings use curved single quotes ?like-this? to quote code.
> This mechanism is already used in the Emacs 24.5 info files, and it works well
> there.
It doesn't work at all well in my terminal (a Linux virtual tty).
Whatever these characters are, they are displayed as inverse question
marks. I'm not in favour of proliferating these characters over our code
as well. How do you type them? How do you search for them?
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 12:28:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 20385 <at> debbugs.gnu.org (full text, mbox):
In article <mailman.1407.1429745888.904.bug-gnu-emacs <at> gnu.org> you wrote:
> Eli Zaretskii wrote:
>> So if we want this to become our default, we need changes in
>> ispell.el, to replace ? with ' before we sent it to the speller.
> Although a change like that might make sense, it appears to go beyond what's
> needed for doc strings. I was thinking of something more modest: change Emacs
> so that if you're editing an Elisp or C string, then when you type `like-this'
> it's by default changed to ?like-this?.
No. Please don't do this. I hate it when proprietary programs pull this
trick. If you type a self-inserting character, that is what you should get.
Not all uses of ` and ' in strings are for quoting.
Also there are complicated repercussions for searching and matching, and
probably quite a few other things, too.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 12:36:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: 23 Apr 2015 12:11:09 -0000
> From: Alan Mackenzie <acm <at> muc.de>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>
>
> > This mechanism is already used in the Emacs 24.5 info files, and it works well
> > there.
>
> It doesn't work at all well in my terminal (a Linux virtual tty).
> Whatever these characters are, they are displayed as inverse question
> marks.
In Emacs or in the stand-alone Info reader?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 12:46:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Hello, Eli.
On Thu, Apr 23, 2015 at 03:35:15PM +0300, Eli Zaretskii wrote:
> > Date: 23 Apr 2015 12:11:09 -0000
> > From: Alan Mackenzie <acm <at> muc.de>
> > Cc: Paul Eggert <eggert <at> cs.ucla.edu>
> > > This mechanism is already used in the Emacs 24.5 info files, and it works well
> > > there.
> > It doesn't work at all well in my terminal (a Linux virtual tty).
> > Whatever these characters are, they are displayed as inverse question
> > marks.
> In Emacs or in the stand-alone Info reader?
In Emacs. I haven't yet tried it in the stand-alone Info reader.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 13:07:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 23 Apr 2015 12:45:03 +0000
> Cc: 20385 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> From: Alan Mackenzie <acm <at> muc.de>
>
> > > It doesn't work at all well in my terminal (a Linux virtual tty).
> > > Whatever these characters are, they are displayed as inverse question
> > > marks.
>
> > In Emacs or in the stand-alone Info reader?
>
> In Emacs.
We can easily fix that, e.g. by using a display table in Info and
*Help* buffers.
> I haven't yet tried it in the stand-alone Info reader.
The next version of Texinfo's Info reader will use ASCII replacements
on text terminals that cannot display these (and other) characters.
Of course, the search issue still remains, you will have to use
"C-x 8 RET", unless we provide commands to insert these characters
directly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 14:52:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> > British and American usages tends to be reversed wrt which curly
> > quotes, single or double, are used at the first level:
>
> Sure, and the tradition in many GNU projects is to use American-
> style quoting for regular English text, and British-style quoting
> for code. For example, the Emacs 24.5 manual's info files quote
> ordinary text like this:
> Emacs occupies a “graphical window”
> and quote code like this:
> A description of an imaginary variable, ‘electric-future-map’.
>
> Changing doc strings to look like the latter will better implement
> the longstanding style for documentation in GNU projects. It's what
> quoting `like this' was originally intended to do (and *did* do,
> with circa-1965 draft ASCII). It's an eminently reasonable way to
> quote code in documentation.
Sorry, but I disagree, whether or not you can claim that it has
been some kind of GNU convention. It is foolhardy. Both double
and single curly quotes are used for _ordinary text_ out there in
the real wide world.
Emacs is in that wide world, and increasingly so. Emacs is a very
general tool, being usable for all sorts of editing and other
activities. And that includes editing ordinary text. And ordinary
text that often has embedded code terms.
Sacrificing being able to use two levels of quoting for ordinary
text in favor of stealing one of them for code quoting, just so
that we can wave our hands and say that we respect some old GNU
convention, is quite short-sighted. Coming from someone who touts
his proposed change as bringing up to "nowadays" and "modern" ways,
I should be surprised. But I'm not.
In short, Emacs should have all three: single and double curly
quotes for their usual uses with ordinary text, and some reasonable
and distinctive way to quote code that is embedded in ordinary text.
If this were HTML or XML (or even JSON) then we would not be trying
to sacrifice one of the first two for the third. We would simply
adopt an unmistakable tag for code quoting.
My vote is (clearly) to keep `...' for quoting code in Info,
doc strings, Emacs-Lisp mode,... It is simple, easy-to-use,
and versatile, and it has proven itself for at least 4 decades.
So far, we have heard exactly ONE (weak) argument against it:
you find it ugly. I'd say prettify it in your own environment,
if it really bothers you, but otherwise leave it alone. Let's
not sacrifice the usefulness of this proven convention for
someone's purely cosmetic concerns.
Or was there another argument in favor of your proposed change
that I missed? I've asked several times now, but have gotten
no reply to the question.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 15:33:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 20385 <at> debbugs.gnu.org (full text, mbox):
I said this, which is not clear:
> If this were HTML or XML (or even JSON) then we would not be trying
> to sacrifice one of the first two for the third. We would simply
> adopt an unmistakable tag for code quoting.
No doubt we do have a similarly unmistakable tag for code quoting,
in TexInfo.
That tag is transformed to `...' in Emacs Info. If it were transformed
to ‘...’ instead then we would lose the distinction between single-quoted
ordinary text and quoted code. That's all.
And of course in help (e.g. `C-h f') and in Emacs-Lisp comments and doc
strings, there is no TexInfo representation.
Users should be able to search for a code term foo and not also hit
ordinary text occurrences of foo. That is approximately possible
today. And it is simple today to (reasonably, if imperfectly) tell
font-lock to highlight `...' occurrences (as it would be for ‘...’).
In some XML-based editors that provide a WSIWYG view, users can
search specially for a given element (e.g. <CodeInline>) or one with
a given attribute value, while remaining in WYSIWYG. But that is
a separate search capability from regexp or simple text search in
the same editors. In Emacs you can easily search for `...' occurrences
and pretty much find what you are looking for.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 17:12:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/23/2015 07:51 AM, Drew Adams wrote:
> Sacrificing being able to use two levels of quoting for ordinary
> text in favor of stealing one of them for code quoting
That's not what the Emacs info files do. They prefer American English
conventions for ordinary text, including quoting “like this” for
ordinary top-level text. And they prefer single quoting at the top
level ‘like-this’ for quoting code. There's no ambiguity in practice,
as ordinary quoted text does not quote code in the manuals. Emacs doc
strings are similar, so there won't be any ambiguity in practice there
either.
> No doubt we do have a similarly unmistakable tag for code quoting,
> in TexInfo.
Yes, it's @code{whatever}.
> That tag is transformed to `...' in Emacs Info.
No, @code{foo} is transformed to ‘foo’.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 17:33:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/23/2015 04:15 AM, Nicolas Petton wrote:
> quoting code in
> elisp docstrings would only be reasonably doable from Emacs' elisp mode,
No, they're reasonably doable from any editor that supports smart
quoting. Although Emacs doesn't have this option, it's common
elsewhere, and it shouldn't be that hard to add it to Emacs.
As for quoting `like this` that still doesn't sound like a good idea.
Do we really want to switch to Markdown (or something like it) for doc
strings? That would be a much bigger project, and would be work that
nobody's prepared to do, and its overall costs could well exceed its
benefits.
Finally, from this thread it's clear that some folks like quoting `like
this' and I suppose there's no harm in continuing to support it, so in
my next iteration of this patch I plan to remove commentary to the
effect that this usage is obsolescent and may not be supported in the
future. So, people who prefer quoting `like this' (e.g., because it's
easier with their non-Emacs text editors), will still be free to do that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 18:24:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Finally, from this thread it's clear that some folks like quoting
> `like this' and I suppose there's no harm in continuing to support it,
> so in my next iteration of this patch I plan to remove commentary to the
> effect that this usage is obsolescent and may not be supported in
> the future. So, people who prefer quoting `like this' (e.g., because
> it's easier with their non-Emacs text editors), will still be free to do
> that.
1. What exactly do you mean by "people who prefer...will still be free
to do that"? Is this choice only at the end-user level? Can a
library make such a choice (to be possibly overridden by a user choice)?
2. Does your proposed change affect only Info? I think that, at the
very least by default, users should have the same experience wrt such
code quoting for Info, doc strings, and Emacs-Lisp (doc strings and
comments). They should not (at least not by default) see `foobar'
in a doc string and Emacs-Lisp mode, and ‘foobar’ in Info.
IOW, a user should be able to make her choice clear wrt such quoting:
* everywhere, at once (i.e. Info, doc strings, Emacs-Lisp mode)
* each individual place, separately
3. To repeat myself: I really feel like you are jumping the gun on this
kind of thing. We should not offer anything like this, even as a
choice, unless and until Emacs can deal with it properly (a) in all
respects: input, search, font-lock,... and (b) everywhere.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 19:39:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/23/2015 11:23 AM, Drew Adams wrote:
> 1. What exactly do you mean by "people who prefer...will still be free
> to do that"? Is this choice only at the end-user level? Can a
> library make such a choice (to be possibly overridden by a user choice)?
I mean that Lisp code can use either style in its doc strings, and Emacs
will work either way. End users will see what's in the doc string; I'm
not proposing any on-the-fly reformatting (other than what's already
there, for limited old displays), as I doubt whether the extra
complexity would be worth the hassle in the long run.
> 2. Does your proposed change affect only Info?
The proposed change doesn't affect info. Info files in the Emacs
distribution already use curved single quotes. Texinfo files will
continue to use quotes `like this', to indicate curved single quotes in
Emacs's info files. Similarly, quoting ``like this'' in a Texinfo file
will continue to generate curved double quotes in Emacs's info files.
> users should have the same experience wrt such
> code quoting for Info, doc strings, and Emacs-Lisp (doc strings and
> comments).
Yes, that's the longer term proposal for Emacs's files, using curved
single quotes. The current patch is one step in that direction. Under
this approach, users who prefer to quote `like this' will still be able
to do that in their own doc strings and manuals.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 19:43:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/23/2015 05:27 AM, Alan Mackenzie wrote:
> I hate it when proprietary programs pull this
> trick.
If we do anything like smartquotes, it should be an option that you can
turn off, and there should be a more-traditional-but-still-easy way to
insert curved single quotes. For the latter, perhaps we could have M-(
insert "‘’" when in a string or comment. M-( is already documented to
have a precondition that point is not in a string or comment, so this
would be an upward-compatible extension. Or perhaps you could suggest
better bindings. This sort of thing might be good enough that we
wouldn't need smartquotes after all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 19:48:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert writes:
> On 04/23/2015 04:15 AM, Nicolas Petton wrote:
>> quoting code in
>> elisp docstrings would only be reasonably doable from Emacs' elisp mode,
>
> No, they're reasonably doable from any editor that supports smart
> quoting. Although Emacs doesn't have this option, it's common
> elsewhere, and it shouldn't be that hard to add it to Emacs.
>
> As for quoting `like this` that still doesn't sound like a good idea.
> Do we really want to switch to Markdown (or something like it) for doc
> strings? That would be a much bigger project, and would be work that
> nobody's prepared to do, and its overall costs could well exceed its
> benefits.
I never suggested adding support for Markdown, I gave Markdown as an
example of `...` being used to quote code.
Nico
--
Nicolas Petton
http://nicolas-petton.fr
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 19:56:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/22/2015 10:00 AM, Eli Zaretskii wrote:
>> > Moreover, AFAIU people who want to see ‘this’ actually _want_ to see
>>> the u+2018 etc. characters in the file/buffer.
>>
>> That's no problem: fontify the source files like that, too.
>
> No, they want the characters to be in the file.
Who are those people, and why do they want that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 19:58:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/23/2015 08:32 PM, Paul Eggert wrote:
> Finally, from this thread it's clear that some folks like quoting `like
> this' and I suppose there's no harm in continuing to support it, so in
> my next iteration of this patch I plan to remove commentary to the
> effect that this usage is obsolescent and may not be supported in the
> future. So, people who prefer quoting `like this' (e.g., because it's
> easier with their non-Emacs text editors), will still be free to do that.
Please, let's not have multiple standards for this trivial thing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 20:04:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 23 Apr 2015 22:55:28 +0300
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 20385 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
>
> On 04/22/2015 10:00 AM, Eli Zaretskii wrote:
>
> >> > Moreover, AFAIU people who want to see ‘this’ actually _want_ to see
> >>> the u+2018 etc. characters in the file/buffer.
> >>
> >> That's no problem: fontify the source files like that, too.
> >
> > No, they want the characters to be in the file.
>
> Who are those people, and why do they want that?
Those who follow Markus Kuhn's advice, read here:
http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 20:08:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Info files in the Emacs distribution already use curved single
> quotes.
I sure hope not. That's not the case in the Windows binary builds
I was able to download. But there is no Windows build for the latest
release. That will certainly be a step backward, if what you say
is true.
> > users should have the same experience wrt such
> > code quoting for Info, doc strings, and Emacs-Lisp (doc
> > strings and comments).
>
> Yes, that's the longer term proposal for Emacs's files, using curved
> single quotes.
You mean that it is one of your longer-term proposals, I assume.
AFAIK, there is no such longer-term plan published by GNU for
Emacs's files.
Whatever is planned by GNU, I hope it allows users to at least
choose the reliable, conventional system we've enjoyed for 40 years.
> The current patch is one step in that direction.
> Under this approach, users who prefer to quote `like this' will
> still be able to do that in their own doc strings and manuals.
1. You didn't answer my question about libraries being able to
choose (possibly overridden by a user).
2. This sop is not at all sufficient: "able to do that in their
*own* doc strings and manuals". Might as well say that you will
allow folks to do what they like in their own fork of Emacs.
3. You have still given *no* argument in favor of anything you've
proposed here. We've seen only the pseudo-argument that you find
the Emacs way "ugly".
IMHO, this self-styled beautification proposal should be
considered a non-starter.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 20:14:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 23 Apr 2015 13:07:14 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 20385 <at> debbugs.gnu.org
>
> > Info files in the Emacs distribution already use curved single
> > quotes.
>
> I sure hope not. That's not the case in the Windows binary builds
> I was able to download. But there is no Windows build for the latest
> release. That will certainly be a step backward, if what you say
> is true.
This depends on the version of Texinfo used to generate the Info
files. With the latest version, what Paul says is true.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 20:14:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> > Who are those people, and why do they want that?
>
> Those who follow Markus Kuhn's advice, read here:
> http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
...where the *only* argument given is, again, "it looked rather ugly".
That is the only "why do they want that" that we have heard, so far.
And of course Mr. Kuhn is not specifically talking about an environment
such as Emacs, where you do more with text than just read it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 20:16:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> > > Info files in the Emacs distribution already use curved single
> > > quotes.
> >
> > I sure hope not. That's not the case in the Windows binary builds
> > I was able to download. But there is no Windows build for the
> > latest release. That will certainly be a step backward, if what
> > you say is true.
>
> This depends on the version of Texinfo used to generate the Info
> files. With the latest version, what Paul says is true.
Yes, but I thought you were keeping an eye out, Eli ;-), and making
sure that at least the Windows Emacs builds used an older version.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 23 Apr 2015 23:25:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/23/2015 01:07 PM, Drew Adams wrote:
> 1. You didn't answer my question about libraries being able to
> choose (possibly overridden by a user).
Sorry if the answer was unclear. Under the current proposal, a library
of Emacs Lisp code can choose either style, by using the style in its
doc strings. By default, the user will see the library's style. So
yes, libraries can choose. As Eli mentioned, there's a mechanism in
Emacs to display Unicode characters using approximations on less-capable
displays, and in that sense the user will be able override a library
that prefers curved quotes.
> Might as well say that you will
> allow folks to do what they like in their own fork of Emacs.
No, not at all. Libraries that want to remain easily-editable in older
versions of Emacs can continue to quote `like this'; their users and
developers won't need to fork Emacs.
> 3. You have still given*no* argument in favor of anything you've
> proposed here. We've seen only the pseudo-argument that you find
> the Emacs way "ugly".
It's not a pseudo argument. Appearance matters, and the older style is
off-putting on today's displays. This is why the GNU coding standards
recommend against quoting `like this'. See:
http://www.gnu.org/prep/standards/html_node/Quote-Characters.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 00:25:01 GMT)
Full text and
rfc822 format available.
Message #176 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> > This sop is not at all sufficient: "able to do that in their
> > *own* doc strings and manuals". Might as well say that you will
> > allow folks to do what they like in their own fork of Emacs.
>
> No, not at all. Libraries that want to remain easily-editable in
> older versions of Emacs can continue to quote `like this'; their
> users and developers won't need to fork Emacs.
So if someone wants to avoid your change then they have a choice:
fork Emacs or use an older Emacs version. Wunderbar.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 03:05:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 04/23/2015 11:03 PM, Eli Zaretskii wrote:
>> Who are those people, and why do they want that?
>
> Those who follow Markus Kuhn's advice, read here:
>
> http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
I think that's typographical advice, and not necessarily applicable to
text editors.
It's pretty common to use slightly awkward (but easy to type and
unambiguous) markup in source code, and then convert it to something
nicer in generated documentation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 04:48:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Drew Adams wrote:
> So if someone wants to avoid your change then they have a choice:
> fork Emacs or use an older Emacs version.
Not at all. People will still be able to use and develop libraries that quote
`like this' if they want, even if they are using a newer Emacs version.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 06:12:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 23 Apr 2015 13:13:30 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 20385 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
>
> > > Who are those people, and why do they want that?
> >
> > Those who follow Markus Kuhn's advice, read here:
> > http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
>
> ...where the *only* argument given is, again, "it looked rather ugly".
> That is the only "why do they want that" that we have heard, so far.
You are missing the point: this paper wants those "rather ugly"
characters to disappear from text content, and not everybody out there
uses Emacs for editing and reading that. So an Emacs-only solution
that just _shows_ the nice characters, leaving the underlying text
with `..' is not what that paper wants, or preaches for.
> And of course Mr. Kuhn is not specifically talking about an environment
> such as Emacs, where you do more with text than just read it.
He doesn't talk about Emacs at all. He's talking about the world at
large. People who want to follow him want the old quoting characters
to never be used at all for quoting purposes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 06:13:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 23 Apr 2015 13:15:46 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: eggert <at> cs.ucla.edu, nicolas <at> petton.fr, 20385 <at> debbugs.gnu.org
>
> > > > Info files in the Emacs distribution already use curved single
> > > > quotes.
> > >
> > > I sure hope not. That's not the case in the Windows binary builds
> > > I was able to download. But there is no Windows build for the
> > > latest release. That will certainly be a step backward, if what
> > > you say is true.
> >
> > This depends on the version of Texinfo used to generate the Info
> > files. With the latest version, what Paul says is true.
>
> Yes, but I thought you were keeping an eye out, Eli ;-), and making
> sure that at least the Windows Emacs builds used an older version.
I have no such power on work done by others.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 06:47:01 GMT)
Full text and
rfc822 format available.
Message #191 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 24 Apr 2015 06:04:18 +0300
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 20385 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
>
> On 04/23/2015 11:03 PM, Eli Zaretskii wrote:
>
> >> Who are those people, and why do they want that?
> >
> > Those who follow Markus Kuhn's advice, read here:
> >
> > http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
>
> I think that's typographical advice, and not necessarily applicable to
> text editors.
Nevertheless, many people want Texinfo, Emacs, and GNU in general to
follow that advice.
> It's pretty common to use slightly awkward (but easy to type and
> unambiguous) markup in source code, and then convert it to something
> nicer in generated documentation.
I personally have no problem with the traditional `..' quoting style,
I'm just trying to explain why IMO display-time tricks will not
necessarily pacify at least some of those who want the ‘..’ style.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 13:44:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
In reply to those worried about how to search for these characters:
If this gets implemented I can finish up the character folding search I was
writing a few months ago. That means searching for regular quotes would
also match curly quotes, just like searching for lowercase strings also
matches upper-case ones (if you have that enabled).
Despite this, I'm completely neutral on whether this should be done or not.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 14:12:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> > > Those who follow Markus Kuhn's advice, read here:
> > > http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
> >
> > ...where the *only* argument given is, again, "it looked rather
> > ugly". That is the only "why do they want that" that we have
> > heard, so far.
>
> You are missing the point: this paper wants those "rather ugly"
> characters to disappear from text content, and not everybody out
> there uses Emacs for editing and reading that.
No, I didn't miss the fact that the paper is not about Emacs etc.
The only _reason given_ in that paper for dropping use of `...'
quoting (anywhere, everywhere) is what I quoted: "it looked rather
ugly".
> So an Emacs-only solution that just _shows_ the nice characters,
> leaving the underlying text with `..' is not what that paper
> wants, or preaches for.
Agreed, but that has nothing to do with what I said. He goes
beyond wanting nice appearance, yes. He wants the content to
reflect the appearance, yes. But the only reason he gave for
any change was the "rather ugly" appearance.
> > And of course Mr. Kuhn is not specifically talking about an
> > environment such as Emacs, where you do more with text than
> > just read it.
>
> He doesn't talk about Emacs at all.
You are repeating my point. He is not talking about Emacs or
anything similar to Emacs. Except that he seems to be talking
generally: As you say, "the old quoting characters" should
"never be used" anywhere "for quoting purposes".
That includes Emacs. But he does not speak to the uses of
`...' in a context like Emacs. He wants all contexts to change,
but he makes no argument that takes a context like Emacs into
account.
> He's talking about the world at large. People who want to
> follow him want the old quoting characters to never be used
> at all for quoting purposes.
Maybe so. But the argument given is far too weak to apply to
Emacs. That "rather ugly" reason might be sufficient for some
people for some contexts. It is not a strong argument for a
context like Emacs.
In the context of Emacs we should hear something more in favor
of such a change. So far, we haven't.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 24 Apr 2015 14:41:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 24 Apr 2015 07:11:24 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: dgutov <at> yandex.ru, 20385 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
>
> > > > Those who follow Markus Kuhn's advice, read here:
> > > > http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
> > >
> > > ...where the *only* argument given is, again, "it looked rather
> > > ugly". That is the only "why do they want that" that we have
> > > heard, so far.
> >
> > You are missing the point: this paper wants those "rather ugly"
> > characters to disappear from text content, and not everybody out
> > there uses Emacs for editing and reading that.
>
> No, I didn't miss the fact that the paper is not about Emacs etc.
> The only _reason given_ in that paper for dropping use of `...'
> quoting (anywhere, everywhere) is what I quoted: "it looked rather
> ugly".
What other reasons can there be for replacing one character with
another?
> > He doesn't talk about Emacs at all.
>
> You are repeating my point. He is not talking about Emacs or
> anything similar to Emacs. Except that he seems to be talking
> generally: As you say, "the old quoting characters" should
> "never be used" anywhere "for quoting purposes".
>
> That includes Emacs. But he does not speak to the uses of
> `...' in a context like Emacs. He wants all contexts to change,
> but he makes no argument that takes a context like Emacs into
> account.
He doesn't care. Read his other articles, and you will see.
> > He's talking about the world at large. People who want to
> > follow him want the old quoting characters to never be used
> > at all for quoting purposes.
>
> Maybe so. But the argument given is far too weak to apply to
> Emacs. That "rather ugly" reason might be sufficient for some
> people for some contexts. It is not a strong argument for a
> context like Emacs.
For you, but you are biased.
Changed bug title to 'Support curved quotes in doc strings' from '[PROPOSED PATCH] Support quoting 'like this' in doc strings'
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org.
(Wed, 13 May 2015 07:07:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 13 May 2015 07:32:03 GMT)
Full text and
rfc822 format available.
Message #205 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan's comment "How does it interact with electric-pair-mode?" in
<http://bugs.gnu.org/20545#11> prompted me to go back to the patch proposed for
Bug#20385 and to get it to work with electric-pair-mode as well. The revised
patch is attached. Most of the new revisions are to
lisp/progmodes/elisp-mode.el. They also add support for C-M-i completion in the
presence of curved quotes, and tweak some wording in the documentation.
I haven't installed this as I am still mulling over similar revisions to the
patch proposed for Bug#20545 (this is to make it easier to type curved quotes in
doc strings).
[0001-Support-curved-quotes-in-doc-strings.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 13 May 2015 12:17:02 GMT)
Full text and
rfc822 format available.
Message #208 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/13/2015 10:30 AM, Paul Eggert wrote:
> I haven't installed this as I am still mulling over similar revisions to
> the patch proposed for Bug#20545 (this is to make it easier to type
> curved quotes in doc strings).
FWIW, this looks bad in Thunderbird's attachment preview. It's most
likely the email client's fault, but still.
Why don't we want to use straight apostrophes in the source files again?
And prettify them with font-lock? Or keep the current quoting, and
likewise prettify it with font-lock?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 13 May 2015 15:14:02 GMT)
Full text and
rfc822 format available.
Message #211 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dmitry Gutov wrote:
> Why don't we want to use straight apostrophes in the source files again
‘again’? Emacs has been using asymmetric quotes in doc strings forever. Or are
you referring to the original Bug#20385 proposal of straight apostrophes?
Stefan wasn't sure he liked that idea, and preferred curved quotes. I'd be
happy either way, myself; the point is that those grave accents have got to go.
> Or keep the current quoting, and likewise prettify it with font-lock?
That's been proposed, but nobody has taken the time to do it. Plus, it'd be One
More Thing; it's simpler if doc strings are plain strings and are not little
subsets of Markdown or whatever.
> this looks bad in Thunderbird's attachment preview
It looks OK when I use Thunderbird 31.6.0 in Ubuntu 15.04 in an American English
locale (first attachment). It's not a thing of beauty, admittedly, but it's
legible enough. It looks much nicer under emacs -Q, which is what counts
(second attachment).
[Screenshot from 2015-05-13 07:56:47.png (image/png, attachment)]
[Screenshot from 2015-05-13 08:08:51.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 13 May 2015 22:34:02 GMT)
Full text and
rfc822 format available.
Message #214 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/13/2015 06:13 PM, Paul Eggert wrote:
> ‘again’? Emacs has been using asymmetric quotes in doc strings
> forever.
I mean that the suggestion was voiced but never sufficiently addressed.
> Or are you referring to the original Bug#20385 proposal of
> straight apostrophes? Stefan wasn't sure he liked that idea, and
> preferred curved quotes. I'd be happy either way, myself; the point is
> that those grave accents have got to go.
The suggestion to use font-lock was Stefan's as well.
> That's been proposed, but nobody has taken the time to do it. Plus,
> it'd be One More Thing; it's simpler if doc strings are plain strings
> and are not little subsets of Markdown or whatever.
That's trivial, if there's agreement to do it. I don't really understand
the motivation for the original proposal (to switch away from `...'), so
it's not clear to me if font-locking would satisfy it.
Also, will going from `...' to '...' be beneficial enough, provided
font-lock displays both as curly single quotes? The downsides to this
are obvious (changing habits, re-training contributors).
"Plain" unicode strings are not that plain, especially if it still takes
4 keypresses to type the character, and I also need to explain to
contributors how to do that.
> It looks OK when I use Thunderbird 31.6.0 in Ubuntu 15.04 in an American
> English locale (first attachment). It's not a thing of beauty,
> admittedly, but it's legible enough. It looks much nicer under emacs
> -Q, which is what counts (second attachment).
That's not a question of aesthetics.
For some reason still unclear to me (I have English locale and language
set everywhere I can see), it displays a group of cyrillic characters
(тАШ) instead of the fancy quotes. Which will complicate reading small
patches somewhat (ones I wouldn't open in an external program otherwise).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 03:25:03 GMT)
Full text and
rfc822 format available.
Message #217 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov wrote:
> I don't really understand the
> motivation for the original proposal (to switch away from `...'), so it's not
> clear to me if font-locking would satisfy it.
The main motivation is that English text shouldn't use grave accent to quote.
It looked good decades ago but the underlying encodings changed and now it is
klunky and offputting. (It's not as bad as the 1950s syntax 16HTHIS IS A STRING
but that's a low bar....) Yes, it was a GNU tradition for many years, but other
GNU packages (GCC, coreutils, etc.) have largely shifted away from it and it's
time Emacs made it more convenient to use the more-standard convention of curved
quotes.
I haven't tried font locking. As I understand it, though, font locking would
address the problem only in doc strings. For example, it wouldn't address
Emacs's diagnostic messages, which also need to get fixed. In contrast, the
sorts of solutions I'm proposing should help support curved quotes nearly
everywhere.
> "Plain" unicode strings are not that plain, especially if it still takes 4
> keypresses to type the character, and I also need to explain to contributors how
> to do that.
The patch proposed in Bug#20545 largely addresses this problem. Contributors
can use the same keypresses as before. If your contributors type this:
The value may be `buffered', `retained', or `non-retained'.
the following characters are put into their doc string:
The value may be ‘buffered’, ‘retained’, or ‘non-retained’.
They won't have to do anything special to get this behavior; just use the
revised Emacs on its own source code.
> For some reason still unclear to me (I have English locale and language set
> everywhere I can see), it displays a group of cyrillic characters (тАШ) instead
> of the fancy quotes. Which will complicate reading small patches somewhat (ones
> I wouldn't open in an external program otherwise).
I reproduced that problem in Thunderbird by visiting "View > Character Encoding
> Auto-Detect" and selecting "Russian". To fix it, I selected "(off)" instead
of "Russian".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 07:12:02 GMT)
Full text and
rfc822 format available.
Message #220 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> Dmitry Gutov <dgutov <at> yandex.ru> writes:
[Moving to emacs-devel@ as the issue at hand is not exactly
related to #20385.]
[…]
> For some reason still unclear to me (I have English locale and
> language set everywhere I can see), it displays a group of cyrillic
> characters (тАШ) instead of the fancy quotes. Which will complicate
> reading small patches somewhat (ones I wouldn't open in an external
> program otherwise).
As I’ve pointed earlier [1], Thunderbird (on the /sending/ side)
for some reason chooses /not/ to file the ‘charset’
Content-Type: field for text/x-patch MIME parts. In the absence
of the explicitly-stated encoding, the receiving side may resort
to guessing, or (if the buffer model so allows, and Emacs’
/does/) may simply leave the content undecoded (as in:
raw-text.)
I presume this issue (the one of /not/ including the ‘charset’)
is specific to Thunderbird. As an example, please look at a
fragment of the original patch thus MIMEd from Gnus.
[1] news:878ud0k8qh.fsf_-_ <at> violet.siamics.net
http://debbugs.gnu.org/20499#108
--
FSF associate member #7257 http://am-1.org/~ivan/ … 3013 B6A0 230E 334A
[0001-Support-curved-quotes-in-doc-strings.patch (text/x-patch, inline)]
From eb392195ffdb108228c981f92ca8b5766afdcff9 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Wed, 13 May 2015 00:10:00 -0700
Subject: [PATCH] Support curved quotes in doc strings
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Emacs's traditional doc string style has been to quote symbols
`like this'. This worked well on now-obsolete terminals where
` and ' were symmetric quotes, but nowadays curved quotes
‘like this’ look better. Support quoting the new way too.
(Bug#20385)
* doc/lispref/tips.texi (Documentation Tips): Symbols can be quoted
‘like-this’ as well as `like-this'.
* etc/NEWS: Mention this.
* lisp/cedet/srecode/texi.el (srecode-texi-texify-docstring):
* lisp/emacs-lisp/checkdoc.el (checkdoc-this-string-valid-engine):
* lisp/emacs-lisp/lisp-mode.el (lisp-el-font-lock-keywords-2)
(lisp-cl-font-lock-keywords-2):
* lisp/finder.el (finder-font-lock-keywords):
* lisp/gnus/gnus-art.el (gnus-button-alist):
* lisp/help-mode.el (help-xref-symbol-regexp)
(help-xref-info-regexp, help-xref-url-regexp):
* lisp/international/mule-cmds.el (help-xref-mule-regexp-template):
* lisp/progmodes/elisp-mode.el (emacs-lisp-mode):
Add "‘" and "’" to electric-pair-text-pairs.
(elisp--form-quoted-p): Also allow "‘" as a quoting char.
(elisp-completion-at-point, elisp--preceding-sexp):
Also treat "‘" and "’" as quoting chars.
* lisp/wid-edit.el (widget-documentation-link-regexp):
Parse symbols quoted ‘like-this’ as well as `like-this'.
---
doc/lispref/tips.texi | 33 ++++++++++++++++++---------------
etc/NEWS | 4 ++++
lisp/cedet/srecode/texi.el | 2 +-
lisp/emacs-lisp/checkdoc.el | 5 +++--
lisp/emacs-lisp/lisp-mode.el | 8 ++++----
lisp/finder.el | 2 +-
lisp/gnus/gnus-art.el | 8 ++++----
lisp/help-mode.el | 7 ++++---
lisp/international/mule-cmds.el | 2 +-
lisp/progmodes/elisp-mode.el | 24 +++++++++++++-----------
lisp/wid-edit.el | 2 +-
11 files changed, 54 insertions(+), 43 deletions(-)
diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index cc1f0e4..912d746 100644
…
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index 0a95783..dac3b1e 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -2863,7 +2863,7 @@ The following properties have special meanings for this widget:
:type 'boolean
:group 'widget-documentation)
-(defcustom widget-documentation-link-regexp "`\\([^\n`' ]+\\)'"
+(defcustom widget-documentation-link-regexp "[`‘]\\([^\n `'‘’]+\\)['’]"
"Regexp for matching potential links in documentation strings.
The first group should be the link itself."
:type 'regexp
--
2.1.0
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 07:21:03 GMT)
Full text and
rfc822 format available.
Message #223 received at 20385 <at> debbugs.gnu.org (full text, mbox):
>>>>> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>>>>> On 05/13/2015 06:13 PM, Paul Eggert wrote:
[…]
>> That's been proposed, but nobody has taken the time to do it. Plus,
>> it'd be One More Thing; it's simpler if doc strings are plain
>> strings and are not little subsets of Markdown or whatever.
> That's trivial, if there's agreement to do it. I don't really
> understand the motivation for the original proposal (to switch away
> from `...'), so it's not clear to me if font-locking would satisfy
> it.
That’s simple: the ` character is not a quotation mark at all.
In fact, it’s the spacing variant of the very same diacritical
mark as is shown above e in è.
The rationale was that one can encode ‘è’ as ‘e\010`’ if there’s
no “native” è character in the target (ASCII-based) encoding.
Just like one may encode “bold” and “underline”; consider, say:
$ printf 'b\b_o\b_l\b_d\b_ u\bun\bnd\bde\ber\brl\bli\bin\bne\be\n' | less
The very same trick that up to this day is used by man(1).
[…]
--
FSF associate member #7257 http://am-1.org/~ivan/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 08:29:01 GMT)
Full text and
rfc822 format available.
Message #226 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Ivan Shmakov writes:
> As I’ve pointed earlier [1], Thunderbird (on the /sending/ side)
> for some reason chooses /not/ to file the ‘charset’
File a bug on Thunderbird, then. Absence of a charset parameter means
charset=US-ASCII, and Thunderbird should not be emitting US-ASCII MIME
parts with non-ASCII characters present. Not even if the MTAs agree
to use SMTP8.
> In the absence of the explicitly-stated encoding, the
> receiving side may resort to guessing,
A conformant receiver SHOULD NOT guess, unless the user has given it
explicit permission to do that (of course, then anything is OK). From
RFC 2046:
4.1.2. Charset Parameter
A critical parameter that may be specified in the Content-Type
field for "text/plain" data is the character set. This is
specified with a "charset" parameter, as in:
Content-type: text/plain; charset=iso-8859-1
Unlike some other parameter values, the values of the charset
parameter are NOT case sensitive. The default character set, which
must be assumed in the absence of a charset parameter, is US-ASCII.
Note that technically speaking the MUST in this section only applies
to text/plain, and not to any other text content-type. However, given
that the section says
The specification for any future subtypes of "text" must specify
whether or not they will also utilize a "charset" parameter, and
may possibly restrict its values as well. For other subtypes of
"text" than "text/plain", the semantics of the "charset" parameter
should be defined to be identical to those specified here for
"text/plain", i.e., the body consists entirely of characters in the
given charset.
Pretty clearly the intent is that the behavior of text/plain is to be
the default for other text content-types, unless *explicitly* stated
in the content-type spec. See also section
4.1.4. Unrecognized Subtypes
Unrecognized subtypes of "text" should be treated as subtype
"plain" as long as the MIME implementation knows how to handle the
charset.
This only makes sense when charset is unspecified if charset is
assumed to be US-ASCII.
> I presume this issue (the one of /not/ including the ‘charset’)
> is specific to Thunderbird. As an example, please look at a
> fragment of the original patch thus MIMEd from Gnus.
File a bug on Gnus, too. :-)
Of course Emacs should do what its user asks, but the default should
be to assume US-ASCII if there is no charset parameter, and to bitch
(not guess) if non-ASCII octets are seen.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 10:50:03 GMT)
Full text and
rfc822 format available.
Message #229 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/14/2015 06:24 AM, Paul Eggert wrote:
> The main motivation is that English text shouldn't use grave accent to
> quote. It looked good decades ago but the underlying encodings changed
> and now it is klunky and offputting. (It's not as bad as the 1950s
> syntax 16HTHIS IS A STRING but that's a low bar....) Yes, it was a GNU
> tradition for many years, but other GNU packages (GCC, coreutils, etc.)
> have largely shifted away from it and it's time Emacs made it more
> convenient to use the more-standard convention of curved quotes.
The other GNU packages have transitioned to using the straight
apostrophes though, didn't they?
> I haven't tried font locking. As I understand it, though, font locking
> would address the problem only in doc strings. For example, it wouldn't
> address Emacs's diagnostic messages, which also need to get fixed. In
> contrast, the sorts of solutions I'm proposing should help support
> curved quotes nearly everywhere.
The diagnostic messages can be treated differently (use fancy quotes,
since we know this text will appear to the user as-is), or whatever code
outputs diagnostics could convert the ASCII quotes to the fancy ones
on-the-fly.
> The patch proposed in Bug#20545 largely addresses this problem.
> Contributors can use the same keypresses as before. If your
> contributors type this:
Ah, sorry, that's better. I was under the impression, from a related
discussion, that we'll need to type something like `C-x 8 ''.
> I reproduced that problem in Thunderbird by visiting "View > Character
> Encoding > Auto-Detect" and selecting "Russian". To fix it, I selected
> "(off)" instead of "Russian".
Thank you. Indeed, that is it. As a Russian speaker, though, I'm not
going to turn it off.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 14:56:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> From: Ivan Shmakov <ivan <at> siamics.net>
> Date: Thu, 14 May 2015 07:20:17 +0000
>
> the ` character is not a quotation mark at all.
> In fact, it’s the spacing variant of the very same diacritical
> mark as is shown above e in è.
Any references for this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 20:07:01 GMT)
Full text and
rfc822 format available.
Message #235 received at 20385 <at> debbugs.gnu.org (full text, mbox):
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>>> From: Ivan Shmakov Date: Thu, 14 May 2015 07:20:17 +0000
>> The ` character is not a quotation mark at all. In fact, it’s the
>> spacing variant of the very same diacritical mark as is shown above
>> e in è.
> Any references for this?
You mean, other than UnicodeData.txt and its derivatives?
To quote NamesList.txt, for instance:
0060 GRAVE ACCENT
* this is a spacing character
x (modifier letter grave accent - 02CB)
x (combining grave accent - 0300)
x (reversed prime - 2035)
00B4 ACUTE ACCENT
* this is a spacing character
x (modifier letter prime - 02B9)
x (modifier letter acute accent - 02CA)
x (combining acute accent - 0301)
x (prime - 2032)
# 0020 0301
0300 COMBINING GRAVE ACCENT
= Greek varia
x (grave accent - 0060)
x (modifier letter grave accent - 02CB)
0301 COMBINING ACUTE ACCENT
= stress mark
= Greek oxia, tonos
x (apostrophe - 0027)
x (acute accent - 00B4)
x (modifier letter prime - 02B9)
x (modifier letter acute accent - 02CA)
x (greek tonos - 0384)
I presume that if U+0060 was /not/ be meant to be a spacing
grave accent – there would be some other code point for that
purpose, just like there /is/ such a code point (U+00B4) for a
spacing /acute/ accent.
Given that standards are intended to document existing practice,
I’d expect Unicode to note that ‘`’ may be used as a quotation
mark in legacy applications. I’d be surprised to find it
/recommending/ such use, though.
Also, while I have no copy of USAS X3.4-1968 at hand, RFC 20
(which, AIUI, was intended to be a copy of it itself) has the
following note:
6/0 ` Grave Accent [2, 3] (Opening Single Quotation
Mark)
[…]
2 The use of the symbols in 2/2, 2/7, 2/12, 5/14, /6/0, and 7/14
as diacritical marks is described in Appendix A, A5.2
Alas, the appendices are not included in RFC 20. Still, ECMA-6
(which also names 6/0 GRAVE ACCENT) reads:
B.2.3
Composite graphic characters and repertoire
ECMA-6 permits the construction of composite graphic characters by
using the control characters BACKSPACE and CARRIAGE RETURN to image
two or more graphic characters at the same character position.
--
FSF associate member #7257 http://am-1.org/~ivan/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 20:13:01 GMT)
Full text and
rfc822 format available.
Message #238 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> From: Ivan Shmakov <ivan <at> siamics.net>
> Date: Thu, 14 May 2015 20:05:53 +0000
>
> >>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>>>> From: Ivan Shmakov Date: Thu, 14 May 2015 07:20:17 +0000
>
> >> The ` character is not a quotation mark at all. In fact, it’s the
> >> spacing variant of the very same diacritical mark as is shown above
> >> e in è.
>
> > Any references for this?
>
> You mean, other than UnicodeData.txt and its derivatives?
> To quote NamesList.txt, for instance:
>
> 0060 GRAVE ACCENT
> * this is a spacing character
> x (modifier letter grave accent - 02CB)
> x (combining grave accent - 0300)
> x (reversed prime - 2035)
Where does it say that it can be combined with some base character as
a diacritical?
I see no decomposition in UnicodeData.txt that has 0060 as its part.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 14 May 2015 20:32:02 GMT)
Full text and
rfc822 format available.
Message #241 received at 20385 <at> debbugs.gnu.org (full text, mbox):
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>>> From: Ivan Shmakov Date: Thu, 14 May 2015 20:05:53 +0000
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>>> From: Ivan Shmakov Date: Thu, 14 May 2015 07:20:17 +0000
>>>> The ` character is not a quotation mark at all. In fact, it’s the
>>>> spacing variant of the very same diacritical mark as is shown
>>>> above e in è.
>>> Any references for this?
>> You mean, other than UnicodeData.txt and its derivatives? To quote
>> NamesList.txt, for instance:
>> 0060 GRAVE ACCENT
>> * this is a spacing character
[…]
> Where does it say that it can be combined with some base character as
> a diacritical?
Where does it say that X can be combined with X to form a bold
X? Yet man(1) (or, rather, Nroff) uses that since time
immemorial, and it still works with less(1) at the least.
Obviously, that part of ASCII didn’t propagate to Unicode.
That still hardly is a reason to use U+0060 (or any other
spacing accent character) as a substitute to a quotation mark.
[…]
--
FSF associate member #7257 http://am-1.org/~ivan/ … 3013 B6A0 230E 334A
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 15 May 2015 07:50:03 GMT)
Full text and
rfc822 format available.
Message #244 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov wrote:
> The other GNU packages have transitioned to using the straight apostrophes
> though, didn't they?
No, in locales where UTF-8 is allowed these packages typically use curved
quotes. Here are GCC and coreutils in my (UTF-8) locale:
$ echo @ >t.c
$ gcc t.c
t.c:1:1: error: stray ‘@’ in program
$ mv xzzy sfasdf
mv: cannot stat ‘xzzy’: No such file or directory
The packages do use straight apostrophes in locales that lack curved quotes, but
such locales are becoming less popular with time.
> The diagnostic messages can be treated differently (use fancy quotes, since we
> know this text will appear to the user as-is)
Sure, but that's more complicated as it'd mean two ways to generate curved
quotes. Another way to put it: we'd still need an easy way for users to type
curved quotes in strings and once we have that (as per the Bug#20545 patch) then
why not prefer the same easy way to type curved quotes in doc strings?
> As a Russian speaker, though, I'm not going to
> turn it off.
Completely understandable. I suppose you can turn it off for the odd message
where that's useful -- a bit awkward, but better than nothing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 15 May 2015 17:25:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/15/2015 10:49 AM, Paul Eggert wrote:
> No, in locales where UTF-8 is allowed these packages typically use
> curved quotes. Here are GCC and coreutils in my (UTF-8) locale:
On the other hand, you'll be able to dynamically determine which quotes
to use, depending e.g. on the locale.
> $ echo @ >t.c
> $ gcc t.c
> t.c:1:1: error: stray ‘@’ in program
It still doesn't have the fancy quotes directly in the source code: they
seem to be generated dynamically, similarly to the suggestion above:
https://github.com/gcc-mirror/gcc/blob/06fa1266fac43778983b3925ad048748297db38c/gcc/c-family/c-lex.c#L526
> Sure, but that's more complicated as it'd mean two ways to generate
> curved quotes.
Neither of those should be particularly hard to implement.
> Another way to put it: we'd still need an easy way for
> users to type curved quotes in strings and once we have that (as per the
> Bug#20545 patch)
I don't see why we'd still need that, but the patch seems generally
useful either way.
> then why not prefer the same easy way to type curved
> quotes in doc strings?
Two reasons. Neither of them is big, but the improvement from the
transition to different quoting method is not huge either.
- Using unicode for markup is a complication (e.g. with certain mail
clients, but some other instances might come up).
- I don't like having two standards for quoting. And if quotes are
agumented with font-lock, all the existing Elisp out there will be
displayed with modern quotes automatically.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 15 May 2015 18:55:02 GMT)
Full text and
rfc822 format available.
Message #250 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/15/2015 10:24 AM, Dmitry Gutov wrote:
> It still doesn't have the fancy quotes directly in the source code:
> they seem to be generated dynamically
Yes, GCC uses "%< %>" in format strings to represent curved quotes, and
Coreutils has a function 'quote (X)' that returns X surrounded by curved
quotes. However, these are both awkward compared to just using quotes.
GCC and Coreutils use these awkward constructs because they can't assume
decent support for Unicode. Emacs doesn't have this constraint, so it
can do better.
> On the other hand, you'll be able to dynamically determine which
> quotes to use, depending e.g. on the locale.
That's an independent issue: it can be done no matter what quoting
regime the source code uses. But it's probably not worth doing
separately. Once we're worried about different locales, we'll need to
translate the strings to Russian (or whatever) and at that point we can
translate the quotes to use «Russian style». (And yes, Emacs should do
this, just as GCC and Coreutils do -- but one thing at a time.)
> Neither of those should be particularly hard to implement.
I'm not that worried about the cost of implementation now. I'm worried
about the long-term cost of having a quoting regime that requires
documentation and explanation. It's simpler and easier to explain if
the doc string looks the same in the UI as it does while you're editing
it. For example, you can easily cut and paste from the UI into the doc
string source when composing a new doc string, which is something that
doesn't work well for either GCC or Coreutils.
> - Using unicode for markup is a complication (e.g. with certain mail
> clients, but some other instances might come up).
It's a complication we already have, as we already use UTF-8 in a few
doc strings. For example, the documentation for prettify-symbols-mode
uses UTF-8 curved double-quotes. This usage will naturally grow in
time. Yes, there will be some email glitches but they'll be easy to
iron out as we gain experience.
> - I don't like having two standards for quoting.
Nor do I. This is a transition process, with the long-term goal of
quoting via quotes rather than via grave accent and apostrophe. It's not
practical to do this transition all at once, hence the transition
period. But in the long run there'll be just one standard way to quote
(even if Emacs supports the obsolete way indefinitely).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 15 May 2015 19:10:03 GMT)
Full text and
rfc822 format available.
Message #253 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/15/2015 09:54 PM, Paul Eggert wrote:
> That's an independent issue: it can be done no matter what quoting
> regime the source code uses.
Terrific. Then there's no need to worry too much about the diagnostic
messages.
> I'm not that worried about the cost of implementation now. I'm worried
> about the long-term cost of having a quoting regime that requires
> documentation and explanation.
What's there to explain? Quoting will work as before, it'll only be
displayed differently (and users could even opt out of that).
> It's simpler and easier to explain if
> the doc string looks the same in the UI as it does while you're editing
> it.
My "lambda"s have been rendered in Greek for quite a while. We even have
a minor mode for things like this now.
> For example, you can easily cut and paste from the UI into the doc
> string source when composing a new doc string, which is something that
> doesn't work well for either GCC or Coreutils.
Why wouldn't that work in Emacs either way?
The only place that seems like it'll have this problem is the Info
buffers, but they have a lot of other markup that looks differently in
the source anyway.
>> - Using unicode for markup is a complication (e.g. with certain mail
>> clients, but some other instances might come up).
>
> It's a complication we already have, as we already use UTF-8 in a few
> doc strings. For example, the documentation for prettify-symbols-mode
> uses UTF-8 curved double-quotes.
Does it? I can't find that.
But either way, allowing unicode in sources (why we do, obviously) and
using unicode characters as ubiquitous markup are two very different things.
> Nor do I. This is a transition process, with the long-term goal of
> quoting via quotes rather than via grave accent and apostrophe.
If we use rendering via font-lock, there will be no transition process.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 15 May 2015 21:15:02 GMT)
Full text and
rfc822 format available.
Message #256 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/15/2015 12:09 PM, Dmitry Gutov wrote:
> Then there's no need to worry too much about the diagnostic messages.
>
No, that doesn't follow. For example, suppose that the display supports
curved quotes (the typical case) but we use some other format in the
source code. Then, cutting from diagnostic output and pasting into the
source code won't be intuitive and won't work without some Rube Goldberg
conversion.
In contrast, if we use curved quotes in the source, cutting and pasting
will work naturally. It's true that here if the display doesn't support
curved quotes (the atypical case) then cutting and pasting may not work
-- but that's not a problem we need to worry about, since it's rare
nowadays particularly among developers.
> What's there to explain? Quoting will work as before, it'll only be
> displayed differently (and users could even opt out of that).
That will all require explanation, indefinitely. And this won't be as
easy as one might think, particularly if opt-out is common.
>> For example, you can easily cut and paste from the UI into the doc
>> string source when composing a new doc string, which is something that
>> doesn't work well for either GCC or Coreutils.
>
> Why wouldn't that work in Emacs either way?
I suppose it might work in some cases (killing and yanking within a
single GUI Emacs, say) but not in others (cutting from one Emacs running
remotely under gnome-terminal and pasting into another in a different
locale). The other cases are common enough that they will be a
continuing hassle.
> The only place that seems like it'll have this problem is the Info buffers
This sounds backwards. Even now, one can cut curved quotes from an Info
file and paste them into a .texi file and it will work, on a typical
system with proper UTF-8 support (and assuming the latest Emacs on the
master branch and Texinfo 5). (Just to be clear, I'm not proposing that
we switch to this .texi style now -- it's not needed for proper use of
grave accent and apostrophe in our documentation, and so it's a separate
thing that can be deferred for many years.)
>> For example, the documentation for prettify-symbols-mode
>> uses UTF-8 curved double-quotes.
>
> Does it? I can't find that.
Sorry, I meant tildify-space. (I mixed up functions:
prettify-symbols-mode uses a different Unicode character, namely ≤.)
> But either way, allowing unicode in sources (why we do, obviously) and
> using unicode characters as ubiquitous markup are two very different
> things.
Yes, they are different in terms of degree. The existing minor uses of
UTF-8 in doc strings are merely evidence that UTF-8 works in doc
strings. Had these uses been there 20 years or go, or even 10, we would
have had significant problems in practice; but nowadays, UTF-8 is not a
problem.
> If we use rendering via font-lock, there will be no transition process.
I'm not so sure, given the cutting-and-pasting issues mentioned above.
But even if you're right there would still be a tradeoff: would we want
a trivial transition now to a complex and klunky approach long-term, or
a nontrivial transition now to a simple and intuitive approach
long-term? Let's strive for simplicity.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 15 May 2015 21:49:02 GMT)
Full text and
rfc822 format available.
Message #259 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/16/2015 12:13 AM, Paul Eggert wrote:
> In contrast, if we use curved quotes in the source, cutting and pasting
> will work naturally. It's true that here if the display doesn't support
> curved quotes (the atypical case) then cutting and pasting may not work
> -- but that's not a problem we need to worry about, since it's rare
> nowadays particularly among developers.
What if the locale mandates the use of some other kind of quotes? Then
copying and pasting won't work anyway.
In any case, I've never had a need to copy a diagnostic message with the
intention to paste it into the source code. Web search or bug report?
Sure, but never that.
> That will all require explanation, indefinitely. And this won't be as
> easy as one might think, particularly if opt-out is common.
I've never noticed turning lambda into λ while rendering to be a
significant problem among users, as long as copy and paste works.
> I suppose it might work in some cases (killing and yanking within a
> single GUI Emacs, say) but not in others (cutting from one Emacs running
> remotely under gnome-terminal and pasting into another in a different
> locale). The other cases are common enough that they will be a
> continuing hassle.
Again, if there are different locales involved, and you intend to honor
their different quotings, copying and pasting won't work anyway.
Actually, it's a decent argument against using *any particular locale's*
quoting, in order not to confuse casual contributors, who'd have to know
that *these* fancy quotes will be localized, but *those* - won't.
> This sounds backwards. Even now, one can cut curved quotes from an Info
> file and paste them into a .texi file and it will work, on a typical
> system with proper UTF-8 support (and assuming the latest Emacs on the
> master branch and Texinfo 5).
Maybe you could paste quotes, but not any other kind of formatting. So
nobody will be too surprised that you can't, in general, paste quotes too.
> Sorry, I meant tildify-space. (I mixed up functions:
> prettify-symbols-mode uses a different Unicode character, namely ≤.)
Yes, it does - as a part of content, not markup.
And you can notice that if we delimited docstrings with curly quotes
instead of the straight quotation marks, tildify-space wouldn't have
been able to use them exactly this way inside the docstring.
> Had these uses been there 20 years or go, or even 10, we would
> have had significant problems in practice; but nowadays, UTF-8 is not a
> problem.
I know of no serious markup language that utilizes unicode, even now.
> I'm not so sure, given the cutting-and-pasting issues mentioned above.
> But even if you're right there would still be a tradeoff: would we want
> a trivial transition now to a complex and klunky approach long-term, or
> a nontrivial transition now to a simple and intuitive approach
> long-term? Let's strive for simplicity.
Guess I don't see it as clunky. Using ASCII in markup and rendering in
to something fancier later is fairly common approach.
And the benefits are marginal either way. We have bigger difficulties
(how to delimit code blocks in docstrings and comments, for instance),
but here we are discussing changing something that has been working fine
for years.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 15 May 2015 23:53:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov wrote:
> What if the locale mandates the use of some other kind of quotes? Then copying
> and pasting won't work anyway.
Yes it will. It'll work fine. If a documentation string is in (say) Hungarian,
a user will be able to paste quoted Hungarian text into it, and the text will
carry its Hungarian quotation marks along. It'll be just like documentation in
English and with English quotes.
> I've never had a need to copy a diagnostic message with the
> intention to paste it into the source code.
Shrug. I've done it. And vice versa. And there are other examples. The point
is that it's simpler and nicer if cutting and pasting Just Works.
> Actually, it's a decent argument against using *any particular locale's*
> quoting, in order not to confuse casual contributors, who'd have to know that
> *these* fancy quotes will be localized, but *those* - won't.
No, there's normally no need to localize those curved quotes, not if the text is
English and uses English quoting. The only time one would need to localize is
for obsolete displays lacking curved quotes, which casual contributors are
unlikely to be using nowadays anyway.
> Maybe you could paste quotes, but not any other kind of formatting.
First, that's not true: many other kinds of formatting (though obviously not
all) can also be cut and pasted from info into .texi files. Second, even if it
were true it'd be OK. One improvement at a time. Quotes are such a common kind
of formatting that simplifying their cutting and pasting is worth doing even if
we can't simplify all forms of formatting.
> And you can notice that if we delimited docstrings with curly quotes instead of
> the straight quotation marks, tildify-space wouldn't have been able to use them
> exactly this way inside the docstring.
That's not a significant problem, as it applies to any convention that uses only
paired quotes. For example, the current documentation for
skeleton-pair-insert-maybe says "These are (), [], {}, <> and `' ...", and the
reader needs to infer that those instances of ` and ' are not quotes, but are
characters. This sort of thing happens every now and then in documentation, and
it's no big deal.
> I know of no serious markup language that utilizes unicode, even now.
Texinfo does. Unicode curved quotes are part of the markup. They affect
spacing among other things.
> I don't see it as clunky
That's the main point of disagreement here. Although Emacs old-timers are used
to quoting `like this', to newbies it's a weird and offputting relic from
ancient history.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Sat, 16 May 2015 00:09:02 GMT)
Full text and
rfc822 format available.
Message #265 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/16/2015 02:52 AM, Paul Eggert wrote:
> Yes it will. It'll work fine. If a documentation string is in (say)
> Hungarian, a user will be able to paste quoted Hungarian text into it,
> and the text will carry its Hungarian quotation marks along. It'll be
> just like documentation in English and with English quotes.
I see. But will elisp-completion-at-point detect that point is inside
the Hungarian quotes now? Will we have to enumerate every possible kind
of quote in its implementation?
> The point is that it's simpler and nicer if cutting and pasting Just Works.
Ok, we can say it's the main benefit. I think it's not of the utmost
importance, though.
> No, there's normally no need to localize those curved quotes, not if the
> text is English and uses English quoting. The only time one would need
> to localize is for obsolete displays lacking curved quotes, which casual
> contributors are unlikely to be using nowadays anyway.
And that localization code will have to deal with every kind of quote, then?
> Texinfo does. Unicode curved quotes are part of the markup. They
> affect spacing among other things.
Okay, that's... weird. Any other examples, such as ones that newcomers
to Emacs might be familiar with?
>> I don't see it as clunky
>
> That's the main point of disagreement here. Although Emacs old-timers
> are used to quoting `like this', to newbies it's a weird and offputting
> relic from ancient history.
That's neither here nor there. Like you said, they'd still be typing `
and ', but in your case those will be converted into actual quote
characters on the fly, and in mine, only rendered as such.
The end result, visually, would be the same.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Sat, 16 May 2015 00:12:02 GMT)
Full text and
rfc822 format available.
Message #268 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/16/2015 02:52 AM, Paul Eggert wrote:
> Although Emacs old-timers
> are used to quoting `like this', to newbies it's a weird and offputting
> relic from ancient history.
And as long as we're discussing newbies, how about switching to
Markdown-style quoting, then? Two backticks for inline code reference, a
pair of triple backticks for a code block.
That's definitely going to be familiar.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Sat, 16 May 2015 01:24:02 GMT)
Full text and
rfc822 format available.
Message #271 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Our Esteemed Spokesman for Generation Z spake thus:
> Although Emacs old-timers are used to quoting `like this', to
> newbies it's a weird and offputting relic from ancient history.
Ooooo. Please show your research that led to that conclusion.
Just how did you measure the feelings and reactions of our
newbie population? Did you poll newbie Emacs users, for
example? What were the results? How did you analyze them?
How did you compare the feelings of weirdness and
offputtingness our newbies expressed about `...' with those
they expressed about other aspects of Emacs, and about Emacs
in general? How does their reaction to `...' compare with
their reaction to `M-x', `C-u C-x =', Lisp, and all the rest?
Where's the beef?
- Decrepit soixante-huitards would like to know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Sat, 16 May 2015 01:49:04 GMT)
Full text and
rfc822 format available.
Message #274 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov wrote:
> how about switching to Markdown-style quoting, then?
> That's definitely going to be familiar.
Familiar to those who know Markdown, yes. However, English quoting is more
familiar to English writers, and far more people know English than know both
English and Markdown.
> will elisp-completion-at-point detect that point is inside the Hungarian quotes
It could easily do so, in a Hungarian locale. The characters are programmable.
> that's... weird.
It's not weird. It's ordinary English markup. It's "weird" only to Emacs and
TeX users accustomed to oddball quoting `like this' that exists mostly because
of a historical accident.
> The end result, visually, would be the same.
We don't care only about what appears in Emacs after one types C-h. Emacs is
more than just a documentation viewer; it's a tool for editing documentation,
and to those of us who write documentation (or who view Elisp source code, etc.,
etc.) what we see on the screen when we're editing is important. (Otherwise
we'd probably be editing SGML by hand, eeeyyyucckkk.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Sat, 16 May 2015 06:22:01 GMT)
Full text and
rfc822 format available.
Message #277 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Drew Adams wrote:
> How does their reaction to `...' compare with
> their reaction to `M-x', `C-u C-x =', Lisp, and all the rest?
They think Lisp is pretty cool, that control-meta-whatever is a pain, and that
quoting `like this' is something a hidebound greybeard would do.
Although I don't have any formal research, I do have some experience. Over the
past decade my assistants and I have introduced Emacs to an average of about one
new user per day. Most were age 20 or less. Many stop using Emacs soon after
they learn it. I'd like to help improve the retention rate.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Sat, 16 May 2015 07:37:02 GMT)
Full text and
rfc822 format available.
Message #280 received at 20385 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 15 May 2015 23:20:54 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> Although I don't have any formal research, I do have some experience. Over the
> past decade my assistants and I have introduced Emacs to an average of about one
> new user per day. Most were age 20 or less. Many stop using Emacs soon after
> they learn it. I'd like to help improve the retention rate.
I'm not an "old-timer" who objects what you are trying to do, but do
you _really_ think, after all those years, that changing the quoting
style will affect the retention rate in any way?
Let's face it: we make this change (and others like it) because we
think it's right, not because we believe someone will like Emacs more
who didn't before.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Sat, 16 May 2015 08:28:02 GMT)
Full text and
rfc822 format available.
Message #283 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/16/2015 04:48 AM, Paul Eggert wrote:
> Familiar to those who know Markdown, yes. However, English quoting is
> more familiar to English writers, and far more people know English than
> know both English and Markdown.
How many of them are used to seeing a fancy quote after typing a backtick?
On the other hand, I've noticed that users familiar with Markdown
consider the `' situation normal, if they treat it like markup (not
punctuation).
> It could easily do so, in a Hungarian locale. The characters are
> programmable.
We can do virtually anything. But it's a complication.
> It's not weird. It's ordinary English markup.
No, it's punctuation, not markup. There's no markup in English.
>> The end result, visually, would be the same.
>
> We don't care only about what appears in Emacs after one types C-h.
I'm not talking about that.
> what we see on the screen when we're
> editing is important. (Otherwise we'd probably be editing SGML by hand,
> eeeyyyucckkk.)
Indeed, you will see the fancy quotes on the screen while editing source
files, even if something else will get saved to disk. font-lock is handy
that way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Sat, 16 May 2015 09:52:02 GMT)
Full text and
rfc822 format available.
Message #286 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Familiar to those who know Markdown, yes. However, English quoting is
> more familiar to English writers, and far more people know English than
> know both English and Markdown.
The majority of English writers don't know about English quoting.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Tue, 19 May 2015 23:28:02 GMT)
Full text and
rfc822 format available.
Message #289 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/16/2015 01:27 AM, Dmitry Gutov wrote:
> Indeed, you will see the fancy quotes on the screen while editing
> source files, even if something else will get saved to disk. font-lock
> is handy that way.
OK, I tried that, but it didn't work for me. The attached patch works
much of the time, but it causes annoying glitches on the screen (for an
example see attached, created by "emacs -Q" and 'C-h b'; note the red
color glitch after the double-quote). Fiddling with the regexp doesn't
help matters. I'm afraid that font locking is so poorly documented (see
Bug#20613) that I can't tell whether the color glitch is a bug in Emacs
or in this patch's change to Emacs.
Even if I ignore the glitches, I found it disconcerting that the "wrong"
characters were used to display text characters (or, from another point
of view, that the buffer's contents were "wrong" compared to what was on
the screen). So I'm inclined to do something less tricky, e.g., simply
replace characters in the *Help* buffer before displaying the buffer. I
plan to look into that next.
[fontlockquote.txt (text/plain, attachment)]
[Screenshot from 2015-05-19 15:26:13.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Wed, 20 May 2015 02:23:02 GMT)
Full text and
rfc822 format available.
Message #292 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/20/2015 02:27 AM, Paul Eggert wrote:
> OK, I tried that, but it didn't work for me. The attached patch works
> much of the time, but it causes annoying glitches on the screen (for an
> example see attached, created by "emacs -Q" and 'C-h b'; note the red
> color glitch after the double-quote).
That's how a string is highlighted. :) You can press C-u C-x = to see
which face is used there.
So apparently, font-lock-add-keywords turns on font-lock-mode, and since
it's never set up in help-mode otherwise, syntactic fontification is
used (and " is a string delimiter in the standard syntax table). Adding
this (t is the key) before the call resolves that:
(setq font-lock-defaults '(nil t))
But in a major mode, I think you're expected to apply all font-lock
settings via setting font-lock-defaults, not by using
font-lock-add-keywords (the format of keywords is the same).
> Even if I ignore the glitches, I found it disconcerting that the "wrong"
> characters were used to display text characters (or, from another point
> of view, that the buffer's contents were "wrong" compared to what was on
> the screen).
That shouldn't matter much in a read-only buffer...
> So I'm inclined to do something less tricky, e.g., simply
> replace characters in the *Help* buffer before displaying the buffer. I
> plan to look into that next.
...but indeed, this approach could be the simpler one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 21 May 2015 07:23:02 GMT)
Full text and
rfc822 format available.
Message #295 received at 20385 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dmitry Gutov wrote:
> ...but indeed, this approach could be the simpler one.
I hacked at this a bit, and found that the simpler approach also was better at
not curving quotes that shouldn't be curved. For example, describe-variable
should curve the quotes in the doc string, but not in the contents of the
variable. I'm sure this could all be done with font locking but it's simpler to
just edit the characters. And I found a reasonably simple way to put it in,
namely, to modify substitute-command-keys so that it substitutes quotes as well,
with a simple rule that can be done in one pass with only auxiliary boolean flag.
Revised patches are attached. The first one changes substitute-command-keys.
The second one changes the rest of the infrastructure to match; it contains the
bulk of the previously-proposed changes. And the third one updates a few doc
strings, mostly so that ` isn't turned into ‘ when it's really intended to be a
grave accent.
[0001-substitute-command-keys-now-curves-quotes.txt (text/plain, attachment)]
[0002-Support-curved-quotes-in-doc-strings.txt (text/plain, attachment)]
[0003-Fix-minor-quoting-problems-in-doc-strings.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 21 May 2015 10:02:02 GMT)
Full text and
rfc822 format available.
Message #298 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/21/2015 10:21 AM, Paul Eggert wrote:
> And I found a
> reasonably simple way to put it in, namely, to modify
> substitute-command-keys so that it substitutes quotes as well, with a
> simple rule that can be done in one pass with only auxiliary boolean flag.
I'd make it a new function (the name doesn't fit), and pass the
docstring contents through it, before giving them to
substitute-command-keys.
And if you write it in Lisp, you could incorporate the special handling
of quasiquotes relatively easily.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Thu, 21 May 2015 15:00:08 GMT)
Full text and
rfc822 format available.
Message #301 received at 20385 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov wrote:
> I'd make it a new function (the name doesn't fit), and pass the docstring
> contents through it, before giving them to substitute-command-keys.
I originally wrote it that way, but it was harder for me to read. (Also slower,
though that doesn't matter these days.) I couldn't find anybody that would want
to call one function but not the other. Plus, having them be separate functions
introduces more opportunity for error, e.g., it wouldn't be correct to call the
new function after calling substitute-command-keys. So I figured we might as
well leave them combined.
How about if we rename substitute-command-keys to describe it better?
substitute-doc-string, perhaps?
> And if you write it in Lisp, you could incorporate the special handling of
> quasiquotes relatively easily.
Yes, I originally wrote it in Lisp too, but found that it was too tempting to
implement complicated heuristics that would have been a pain to document. (I
even defended some of those heuristics in previous emails -- sorry!) Doing it
in C forced me to come up with something really simple and easy to explain. I'd
rather keep the simple rules now, even if we go back to Lisp (but why bother?).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20385; Package
emacs.
(Fri, 22 May 2015 03:42:02 GMT)
Full text and
rfc822 format available.
Message #304 received at 20385 <at> debbugs.gnu.org (full text, mbox):
On 05/21/2015 05:58 PM, Paul Eggert wrote:
> I originally wrote it that way, but it was harder for me to read.
Two functions each doing less work is harder to read than one?
> (Also slower, though that doesn't matter these days.)
Still matters, but for larger inputs. Calling the quote substitution
function before the keymaps-and-keys one should be fast enough, though.
> How about if we rename substitute-command-keys to describe it better?
> substitute-doc-string, perhaps?
format-doc-string? Anyway, a rename with an obsolete-alias should work, too.
> Yes, I originally wrote it in Lisp too, but found that it was too
> tempting to implement complicated heuristics that would have been a pain
> to document.
It's up to you. I think the handling of quasiquotes isn't hard to
explain in writing, but in the end those snippets of code would be
better surrounded with quotes after rendering, and then the quasiquote
would simply need to be escaped.
> I'd rather keep the simple rules
> now, even if we go back to Lisp (but why bother?).
Having an Elisp implementation might be helpful if we want to apply a
similar transformation via font-lock rules in the source buffers (I
believe you expressed that interest). There will be some difference due
to escaping, but some part might be reusable.
bug closed, send any further explanations to
20385 <at> debbugs.gnu.org and Paul Eggert <eggert <at> cs.ucla.edu>
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org.
(Sat, 30 May 2015 19:16:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 28 Jun 2015 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.