bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
Hello,

I gathered few mistakes in the manual and 3 proposals for it, in one
report, because they are small (maybe except 2nd and 3rd proposal) and
sending them one by one would be spam-ish.  I found them in GNU Emacs
25.2.1 (i686-w64-mingw32) of 2017-04-24 and PDFs updated for 25.2 and
26.2.

* INFO
====================

1.  In INFO 11.7 Disabling Transient Mark Mode:
- ‘M-x transient-mark-mode’, or with the ‘Active Region Highlighting’ menu
+ ‘M-x transient-mark-mode’, or with the ‘Highlight Active Region’ menu
This is correct name of menu item.

2.  In INFO 13.2 Saving Text in Registers:
- activating it.  With a numeric argument, it instead puts point before
+ activating it.  With a prefix argument, it instead puts point before
Help window of 'insert-register' has prefix arg.

3.  In INFO 13.3 Saving Rectangles in Registers:
-      (‘copy-rectangle-to-register’).  With numeric argument, delete it
+      (‘copy-rectangle-to-register’).  With prefix argument, delete it
Help window of 'copy-rectangle-to-register' has prefix arg.

4.  In INFO 14.2 Recentering:
in paragraph starting with "You can also give ‘C-l’ a prefix
argument.", expressions:
    - "recenters point" should be "recenters line"
    - "puts point" (3 occurrences) should rather be "moves current
    line", because point is moved this way by 'M-r'
    ('move-to-window-line-top-bottom') and also in help window for
    'recenter-top-bottom' we have "move current line".

5.  In INFO 14.19 How Text Is Displayed:
- have an integer value between 1 and 1000, inclusive.  Note that how the
+ have an integer value between 1 and 1000, inclusive.  Note how the
I think "that" is unnecessary, "Note that how the tab character
(...)", will change into "Note how the tab character (...)".  Although
I'm not sure of it, maybe current form is correct?

* PDF
====================

1.  In PDF 4.1 Inserting Text:
in paragraph starting with "A few common Unicode characters can be
inserted (...)" (near word "respectively"), "left double quotation
mark" (curved) is displayed as "backslash" and "right double quotation
mark" (curved) is displayed as "straight double quotes".  In INFO it
looks ok.

2.  In PDF 4.1 Inserting Text:
in paragraph starting with "In some contexts, if you type a quotation
(...)", display of quotes is messed up, quotes surrounding Nth
occurrence of "like this" should be:
    - 1st - "grave accent" and "apostrophe",
    - 2nd - is ok,
    - 3rd - 2x "grave accent" and 2x "apostrophe",
    - 4th - "left double quotation mark" (curved) and "right double
      quotation mark" (curved)
Or just look into INFO, it's ok there.

3.  In PDF 11.19 How Text Is Displayed:
in last paragraph, first line, "left double quotation mark" (curved)
is displayed as "backslash" and "right double quotation mark" (curved)
is displayed as "straight double quotes".  In INFO it looks ok.

* Small proposals
====================

1.  Emphasize a word
In both INFO(7.10 Numeric arguments) and PDF(4.10 Numeric Arguments),
in last paragraph, there is a word "before", I suggest to emphasize
this word (or maybe make it slanted, up to you).  It will have
stronger (visual) connection to slanted "prefix argument".

2.  Header style should be changed.
It shows page number in right upper corner on every page, but it
should show it in right upper corner for odd (right-side) pages and in
left upper corner for even (left-side) pages - just like in normal
book.

3.  Add numbers to sections (& subsect.) for bookmark/navigation pane.
When you open it in any PDF reader with manual loaded, it only shows
names of sections, and without numbers it's difficult to navigate.

---
S. U.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
Few more for INFO...
====================

6.  In INFO 15.1.1 Basics of Incremental Search:
- ‘<ESC> <ESC> <ESC>’ (‘isearch-cancel’) or ‘C-g C-g’ (‘isearch-abort’).
+ ‘<ESC> <ESC> <ESC>’ (‘isearch-cancel’) or ‘C-g’ (‘isearch-abort’).
Because `view-lossage' and `describe-bindings' and the last paragraph
of 15.1.4 say: `C-g'.

7. In INFO 17.4 Executing Macros with Variations:
-    ‘C-u C-x q’, which is ‘C-x q’ with a numeric argument, performs a
+    ‘C-u C-x q’, which is ‘C-x q’ with a prefix argument, performs a
Help window of `kbd-macro-query' has prefix arg.

8. In INFO 17.5 Naming and Saving Keyboard Macros:
-    If you give ‘insert-kbd-macro’ a numeric argument, it makes
+    If you give ‘insert-kbd-macro’ a prefix argument, it makes
Help window of `insert-kbd-macro' has prefix arg.

9. In INFO 15.10.2 Regexp Replacement:
-   Repeating our example to exchange ‘x’ and ‘y’, we can thus do it also
-this way:
+   For example to exchange `x' and `y', we can do it this way:
Although I'm not sure of this, the sentence sounds like there is
another example of exchanging `x' and `y' (especially the word
``also''), but I cannot find it, therefore or I missed it, or there was
something, but it was deleted and someone forgot to update the text.

10. In both INFO and PDF:
   10.1. INFO 15.9 Lax Matching During Searching:
   - such as U+249C PARENTHESIZED LATIN SMALL LETTER A and U+2100 ACCOUNT OF
   + such as `U+249C' PARENTHESIZED LATIN SMALL LETTER A and `U+2100'
ACCOUNT OF
   AND
   - matches U+FB00 LATIN SMALL LIGATURE FF.  Character sequences that are
   + matches `U+FB00' LATIN SMALL LIGATURE FF.  Character sequences that are
   In both cases in PDF (12.9) string from `U' to the end of character
   name (except `+' and digits) is written as "small caps shape" while
   it should be: code as "typewriter family" (or verbatim?) and name as
   normal upcase letters - just like in chapter "Inserting Text".

   10.2. INFO 25.5 Quotation Marks:
   -    (1) The curved single quote characters are U+2018 LEFT SINGLE
   - QUOTATION MARK and U+2018 RIGHT SINGLE QUOTATION MARK; the curved
double
   - quotes are U+201C LEFT DOUBLE QUOTATION MARK and U+201D RIGHT DOUBLE
   - QUOTATION MARK. On text terminals which cannot display these characters
   +    (1) The curved single quote characters are `U+2018' LEFT SINGLE
   + QUOTATION MARK and `U+2018' RIGHT SINGLE QUOTATION MARK; the curved
double
   + quotes are `U+201C' LEFT DOUBLE QUOTATION MARK and `U+201D' RIGHT
DOUBLE
   + QUOTATION MARK. On text terminals which cannot display these characters
   Similar to the problem above, only this time in PDF (22.5), Unicode
   should be written as typewriter/verbatim, the name is OK - all
   uppercase.

OR... perhaps desired way was: typewriter/verbatim for the code and
small caps shape for the name?

... and for PDF...
==================

In PDF 22.5 Quotation Marks:
    In 1st paragraph, 2nd line: 1st "like this" is surrounded with single
curved quotes, while they should be single straight quotes.
    In 1st paragraph, 3rd&4th line: both "like this" are surrounded with
good quotes, but they have bad shape (normal text), while should be
typewriter/verbatim.
    In 2nd paragraph, 2nd line: there should be straight quotes
followed by their curved types, but unfortunately straight quotes are
curved as well.  Also curved have bad shape (normal text), should be
typewriter/verbatim.
    In 2nd paragraph, "value" at the end: curved quotes have bad shape
(normal text), should be typewriter/verbatim.
    In 4th paragraph, 5th line: curved quotes have bad shape (normal
text), should be typewriter/verbatim.

ALSO (addition)

In point 1 (previous message) in the same paragraph, line below, "(...)
C-x 8 [ and inserts (...)" and curved opening quote follows, which
is good, but it has shape of normal latex text, while it should has
typewriter/verbatim shape (bolder one).

... and another proposal
========================

In INFO 15.6 and PDF 12.6 Syntax of Regular Expressions:
Perhaps slanting word "special" or "special constructs" (I would opt
for first one) in...
    Regular expressions have a syntax in which a few characters are
special constructs and the rest are “ordinary”.  An ordinary character
... for (again) stronger visual connection with word "ordinary".



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Eli Zaretskii
In reply to this post by Sebastian Urban
> From: Sebastian Urban <[hidden email]>
> Date: Fri, 24 May 2019 17:59:09 +0200
>
> I gathered few mistakes in the manual and 3 proposals for it, in one
> report, because they are small (maybe except 2nd and 3rd proposal) and
> sending them one by one would be spam-ish.  I found them in GNU Emacs
> 25.2.1 (i686-w64-mingw32) of 2017-04-24 and PDFs updated for 25.2 and
> 26.2.

Thanks.  I fixed most of the issues, see below.

> 1.  In INFO 11.7 Disabling Transient Mark Mode:
> - ‘M-x transient-mark-mode’, or with the ‘Active Region Highlighting’ menu
> + ‘M-x transient-mark-mode’, or with the ‘Highlight Active Region’ menu
> This is correct name of menu item.
>
> 2.  In INFO 13.2 Saving Text in Registers:
> - activating it.  With a numeric argument, it instead puts point before
> + activating it.  With a prefix argument, it instead puts point before
> Help window of 'insert-register' has prefix arg.
>
> 3.  In INFO 13.3 Saving Rectangles in Registers:
> -      (‘copy-rectangle-to-register’).  With numeric argument, delete it
> +      (‘copy-rectangle-to-register’).  With prefix argument, delete it
> Help window of 'copy-rectangle-to-register' has prefix arg.

Fixed these.

> 4.  In INFO 14.2 Recentering:
> in paragraph starting with "You can also give ‘C-l’ a prefix
> argument.", expressions:
>     - "recenters point" should be "recenters line"
>     - "puts point" (3 occurrences) should rather be "moves current
>     line", because point is moved this way by 'M-r'
>     ('move-to-window-line-top-bottom') and also in help window for
>     'recenter-top-bottom' we have "move current line".

I used a different wording, like "move point's line to ...".

> 5.  In INFO 14.19 How Text Is Displayed:
> - have an integer value between 1 and 1000, inclusive.  Note that how the
> + have an integer value between 1 and 1000, inclusive.  Note how the
> I think "that" is unnecessary, "Note that how the tab character
> (...)", will change into "Note how the tab character (...)".  Although
> I'm not sure of it, maybe current form is correct?

The current text is correct, but it's confusing.  I reworded it.

> 1.  In PDF 4.1 Inserting Text:
> in paragraph starting with "A few common Unicode characters can be
> inserted (...)" (near word "respectively"), "left double quotation
> mark" (curved) is displayed as "backslash" and "right double quotation
> mark" (curved) is displayed as "straight double quotes".  In INFO it
> looks ok.
>
> 2.  In PDF 4.1 Inserting Text:
> in paragraph starting with "In some contexts, if you type a quotation
> (...)", display of quotes is messed up, quotes surrounding Nth
> occurrence of "like this" should be:
>     - 1st - "grave accent" and "apostrophe",
>     - 2nd - is ok,
>     - 3rd - 2x "grave accent" and 2x "apostrophe",
>     - 4th - "left double quotation mark" (curved) and "right double
>       quotation mark" (curved)
> Or just look into INFO, it's ok there.
>
> 3.  In PDF 11.19 How Text Is Displayed:
> in last paragraph, first line, "left double quotation mark" (curved)
> is displayed as "backslash" and "right double quotation mark" (curved)
> is displayed as "straight double quotes".  In INFO it looks ok.

I believe you saw these in the Emacs 25 manual.  We did a lot of fixes
regarding these special characters in preparation for Emacs 26
release, so please be sure to look in the latest version (it is best
to checkout the current emacs-26 branch and produce PDF from its
sources).  I didn't change any of the issues with quotes, as I don't
have a PDF version of the manual handy, and couldn't myself check
whether there are leftovers.

> 1.  Emphasize a word
> In both INFO(7.10 Numeric arguments) and PDF(4.10 Numeric Arguments),
> in last paragraph, there is a word "before", I suggest to emphasize
> this word (or maybe make it slanted, up to you).  It will have
> stronger (visual) connection to slanted "prefix argument".

I did that.

> 2.  Header style should be changed.
> It shows page number in right upper corner on every page, but it
> should show it in right upper corner for odd (right-side) pages and in
> left upper corner for even (left-side) pages - just like in normal
> book.
>
> 3.  Add numbers to sections (& subsect.) for bookmark/navigation pane.
> When you open it in any PDF reader with manual loaded, it only shows
> names of sections, and without numbers it's difficult to navigate.

These are beyond our control (well, unless we want to write a lot of
TeX glue in the manual): this is how Texinfo works.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Eli Zaretskii
In reply to this post by Sebastian Urban
> From: Sebastian Urban <[hidden email]>
> Date: Mon, 3 Jun 2019 00:50:55 +0200
>
> 6.  In INFO 15.1.1 Basics of Incremental Search:
> - ‘<ESC> <ESC> <ESC>’ (‘isearch-cancel’) or ‘C-g C-g’ (‘isearch-abort’).
> + ‘<ESC> <ESC> <ESC>’ (‘isearch-cancel’) or ‘C-g’ (‘isearch-abort’).
> Because `view-lossage' and `describe-bindings' and the last paragraph
> of 15.1.4 say: `C-g'.

I left this unaltered, because in some cases you do need to type C-g
twice, so doing it twice always is safer.

> 7. In INFO 17.4 Executing Macros with Variations:
> -    ‘C-u C-x q’, which is ‘C-x q’ with a numeric argument, performs a
> +    ‘C-u C-x q’, which is ‘C-x q’ with a prefix argument, performs a
> Help window of `kbd-macro-query' has prefix arg.
>
> 8. In INFO 17.5 Naming and Saving Keyboard Macros:
> -    If you give ‘insert-kbd-macro’ a numeric argument, it makes
> +    If you give ‘insert-kbd-macro’ a prefix argument, it makes
> Help window of `insert-kbd-macro' has prefix arg.

Fixed.

> 9. In INFO 15.10.2 Regexp Replacement:
> -   Repeating our example to exchange ‘x’ and ‘y’, we can thus do it also
> -this way:
> +   For example to exchange `x' and `y', we can do it this way:
> Although I'm not sure of this, the sentence sounds like there is
> another example of exchanging `x' and `y' (especially the word
> ``also''), but I cannot find it, therefore or I missed it, or there was
> something, but it was deleted and someone forgot to update the text.

There was a previous example, but it was deleted in Emacs 24.  I fixed
the wording.

> 10. In both INFO and PDF:
>    10.1. INFO 15.9 Lax Matching During Searching:
>    - such as U+249C PARENTHESIZED LATIN SMALL LETTER A and U+2100 ACCOUNT OF
>    + such as `U+249C' PARENTHESIZED LATIN SMALL LETTER A and `U+2100'
> ACCOUNT OF
>    AND
>    - matches U+FB00 LATIN SMALL LIGATURE FF.  Character sequences that are
>    + matches `U+FB00' LATIN SMALL LIGATURE FF.  Character sequences that are
>    In both cases in PDF (12.9) string from `U' to the end of character
>    name (except `+' and digits) is written as "small caps shape" while
>    it should be: code as "typewriter family" (or verbatim?) and name as
>    normal upcase letters - just like in chapter "Inserting Text".

I don't see anything wrong with the current typeface, so I left it
alone.

>    10.2. INFO 25.5 Quotation Marks:
>    -    (1) The curved single quote characters are U+2018 LEFT SINGLE
>    - QUOTATION MARK and U+2018 RIGHT SINGLE QUOTATION MARK; the curved
> double
>    - quotes are U+201C LEFT DOUBLE QUOTATION MARK and U+201D RIGHT DOUBLE
>    - QUOTATION MARK. On text terminals which cannot display these characters
>    +    (1) The curved single quote characters are `U+2018' LEFT SINGLE
>    + QUOTATION MARK and `U+2018' RIGHT SINGLE QUOTATION MARK; the curved
> double
>    + quotes are `U+201C' LEFT DOUBLE QUOTATION MARK and `U+201D' RIGHT
> DOUBLE
>    + QUOTATION MARK. On text terminals which cannot display these characters
>    Similar to the problem above, only this time in PDF (22.5), Unicode
>    should be written as typewriter/verbatim, the name is OK - all
>    uppercase.

Like earlier, I didn't change anything about the quotes, because I
think that was fixed already.  Please try the latest Texinfo sources.

> In PDF 22.5 Quotation Marks:
>     In 1st paragraph, 2nd line: 1st "like this" is surrounded with single
> curved quotes, while they should be single straight quotes.
>     In 1st paragraph, 3rd&4th line: both "like this" are surrounded with
> good quotes, but they have bad shape (normal text), while should be
> typewriter/verbatim.
>     In 2nd paragraph, 2nd line: there should be straight quotes
> followed by their curved types, but unfortunately straight quotes are
> curved as well.  Also curved have bad shape (normal text), should be
> typewriter/verbatim.
>     In 2nd paragraph, "value" at the end: curved quotes have bad shape
> (normal text), should be typewriter/verbatim.
>     In 4th paragraph, 5th line: curved quotes have bad shape (normal
> text), should be typewriter/verbatim.

Likewise.

> In point 1 (previous message) in the same paragraph, line below, "(...)
> C-x 8 [ and inserts (...)" and curved opening quote follows, which
> is good, but it has shape of normal latex text, while it should has
> typewriter/verbatim shape (bolder one).

Likewise.

> In INFO 15.6 and PDF 12.6 Syntax of Regular Expressions:
> Perhaps slanting word "special" or "special constructs" (I would opt
> for first one) in...
>     Regular expressions have a syntax in which a few characters are
> special constructs and the rest are “ordinary”.  An ordinary character
> ... for (again) stronger visual connection with word "ordinary".

Done.

Thanks again for reviewing the manual.

I'm marking this bug report done.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
Thanks for the fixes, but I don't think closing this bug was good
decision.  Even if we leave quotes behind (but we won't, right?),
Unicode code and name pairs bug will still be there.

> I believe you saw these in the Emacs 25 manual.

No, my reference is version updated for 26.2, downloaded from official
Emacs website with manuals.  For this e-mail I also looked into HTML
version.

> ... checkout the current emacs-26 branch...

Well after you said it, I did that - I downloaded basic.texi,
display.texi, search.texi, text.texi from:
http://git.savannah.gnu.org/cgit/emacs.git/tree/doc/emacs?h=emacs-26
and texinfo.tex from:
http://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc?h=emacs-26

Unfortunately I didn't make PDF out of them, but I looked into theirs
code/text.

> 1.  In PDF 4.1 Inserting Text:
> in paragraph starting with "A few common Unicode characters can be
> inserted (...)" (near word "respectively"), "left double quotation
> mark" (curved) is displayed as "backslash" and "right double quotation
> mark" (curved) is displayed as "straight double quotes".  In INFO it
> looks ok.

Well for this I have no answer...

In BASIC.TEXI (L119):
# curved quotes @t{’}, @t{“} and @t{”}, respectively.  Also, a working
While @t{...} works for
   single quotes - both curved (#x2018 & #x2019), probably including x2
   grave accent, including x2
   apostrophe, including x2
making all of them curved and in typewriter shape in PDF, it fails to
show LEFT (#x201c) and RIGHT (#x201d) DOUBLE QUOTATION MARK, and
displays instead BACKSLASH and QUOTATION MARK (#x22).  It also works
for QUOTATION MARK - @t{"}.  An ugly way to fix it would be @t{``} and
@t{''}, but I think it's not an option.

BTW This looks good in HTML version.

> ALSO (addition)
>
> In point 1 (previous message) in the same paragraph, line below, "(...)
> C-x 8 [ and inserts (...)" and curved opening quote follows, which
> is good, but it has shape of normal latex text, while it should has
> typewriter/verbatim shape (bolder one).

In BASIC.TEXI - LINE 121:
- and inserts `.  To see which characters have @kbd{C-x 8} ...
+ and inserts @t{‘}.  To see which characters have @kbd{C-x 8} ...
Just like in L115.  This bug is present in HTML version as well.

> 2.  In PDF 4.1 Inserting Text:
> in paragraph starting with "In some contexts, if you type a quotation
> (...)", display of quotes is messed up, quotes surrounding Nth
> occurrence of "like this" should be:
>    - 1st - "grave accent" and "apostrophe",
>    - 2nd - is ok,
>    - 3rd - 2x "grave accent" and 2x "apostrophe",
>    - 4th - "left double quotation mark" (curved) and "right double
>      quotation mark" (curved)
> Or just look into INFO, it's ok there.

As for 1st occurrence in BASIC.TEXI - L149:
# accent and apostrophe @t{`like this'}, it is converted to a form
It could be corrected with @kbd{`}@t{like this}@kbd{'}.  Looks good
in HTML.

As for 2nd - it also looks good in HTML.

As for 3rd occurrence in BASIC.TEXI - L151:
# commands.  Similarly, typing a quotation @t{``like this''} using
As above - @kbd{``}@t{like this}@kbd{''}...  Looks bad in HTML.

As for 4th occurrence, just like in first point - I don't know.
Looks good in HTML.

> 3.  In PDF 11.19 How Text Is Displayed:
> in last paragraph, first line, "left double quotation mark" (curved)
> is displayed as "backslash" and "right double quotation mark" (curved)
> is displayed as "straight double quotes".  In INFO it looks ok.

In DISPLAY.TEXI - L1560:
#  If the curved quotes @samp{‘}, @samp{’}, @samp{“}, and @samp{”} are
Well here we have @samp{...} instead of @t{...}, which also fails to
show “ and ”, displaying instead \ and " (just like @t{...}).  But
it looks good in HTML.

> In PDF 22.5 Quotation Marks:

First little bonus from TEXT.TEXI (L424-425):
"The funny quoting below is to make the printed version look correct.
FIXME."

>    In 1st paragraph, 2nd line: 1st "like this" is surrounded with single
> curved quotes, while they should be single straight quotes.

In TEXT.TEXI - L427:
# using straight apostrophes @t{'like this'} or double-quotes @t{"like
Similar to above example, @kbd{'}@t{like this}@kbd{'}.  Looks good in
HTML.

>    In 1st paragraph, 3rd&4th line: both "like this" are surrounded with
> good quotes, but they have bad shape (normal text), while should be
> typewriter/verbatim.

In TEXT.TEXI - L429:
# left and right single or double quotation marks `@t{like this}' or
Switch to - @t{‘like this’} - with #x2018 & #x2019.

The second "like this" is L/R double quotation marks, so again no answer.

Both look bad in HTML.

>    In 2nd paragraph, 2nd line: there should be straight quotes
> followed by their curved types, but unfortunately straight quotes are
> curved as well.  Also curved have bad shape (normal text), should be
> typewriter/verbatim.

In TEXT.TEXI - L442-443:
- type characters it optionally converts @t{`} to ‘, @t{'} to ',
- @t{``} to ``, and @t{''} to ''.  It's possible to change the
+ type characters it optionally converts @kbd{`} to @t{‘}, @kbd{'} to @t{’},
+ @kbd{``} to ??, and @kbd{''} to ??.  It's possible to change the
Of course I don't know what to put for “ and ”, so I put ?? there.
Also it looks bad in HTML.

>    In 2nd paragraph, "value" at the end: curved quotes have bad shape
> (normal text), should be typewriter/verbatim.

In TEXT.TEXI - L448:
# default value is @code{'(?@r{`} ?@r{'} ?@r{``} ?@r{''})}.
Perhaps first two could be changed to normal @t{‘} and @t{’}.  Last
two - a mystery.  Also it looks bad in HTML.

>    In 4th paragraph, 5th line: curved quotes have bad shape (normal
> text), should be typewriter/verbatim.

In TEXT.TEXI - L469:
# @t{’}, @kbd{C-x 8 @{} for ``, and @kbd{C-x 8 @}} for ''.
Again L/R double quotation mark.  Also it looks bad in HTML.

====================

Now about Unicode code & name pairs.

> I don't see anything wrong with the current typeface, so I left it
> alone.

In BASIC.TEXI - L116 we have:
    @code{U+2018} LEFT SINGLE QUOTATION MARK
In SEARCH.TEXI - L1313-1314 and L1319-1320 we have:
    @sc{u+249c parenthesized latin small letter a}
    @sc{u+2100 account of}
    @sc{u+fb00 latin small ligature ff}
In TEXT.TEXI - L430 (inside footnote) we have:
    U+2018 LEFT SINGLE QUOTATION MARK
    U+2018 RIGHT SINGLE QUOTATION MARK <--- this has wrong code!
    U+201C LEFT DOUBLE QUOTATION MARK
    U+201D RIGHT DOUBLE QUOTATION MARK
So, 3 different styles.  I think @code{...} around Unicode code and
uppercase "U" is a must.  This is how they are displayed in many other
places.  Style of name - I don't know, I would pick normal uppercase,
because of simplicity, but it's up to you.

====================

>> 6.  In INFO 15.1.1 Basics of Incremental Search:
>> - ‘<ESC> <ESC> <ESC>’ (‘isearch-cancel’) or ‘C-g C-g’ (‘isearch-abort’).
>> + ‘<ESC> <ESC> <ESC>’ (‘isearch-cancel’) or ‘C-g’ (‘isearch-abort’).
>> Because `view-lossage' and `describe-bindings' and the last paragraph
>> of 15.1.4 say: `C-g'.
>
> I left this unaltered, because in some cases you do need to type C-g
> twice, so doing it twice always is safer.

Well I think the last paragraph of 15.1.4 pointed by me explains this
behaviour.  It exactly says that sometimes C-g needs to be typed twice
to exit search.  That's why I'm sticking to my version, unless you had
other cases in mind.  And "isearch-abort" is literally binded to "C-g"
so it may rise questions.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Eli Zaretskii
> From: Sebastian Urban <[hidden email]>
> Cc: [hidden email]
> Date: Tue, 4 Jun 2019 12:48:50 +0200
>
> Thanks for the fixes, but I don't think closing this bug was good
> decision.  Even if we leave quotes behind (but we won't, right?),
> Unicode code and name pairs bug will still be there.

We can continue discussing this even though the bug is closed.  And
since this is a documentation "bug", closing it has no bearing on the
functionality of the software.

> > I believe you saw these in the Emacs 25 manual.
>
> No, my reference is version updated for 26.2, downloaded from official
> Emacs website with manuals.  For this e-mail I also looked into HTML
> version.

Thanks, this wasn't obvious to me.

> In BASIC.TEXI (L119):
> # curved quotes @t{’}, @t{“} and @t{”}, respectively.  Also, a working
> While @t{...} works for
>    single quotes - both curved (#x2018 & #x2019), probably including x2
>    grave accent, including x2
>    apostrophe, including x2
> making all of them curved and in typewriter shape in PDF, it fails to
> show LEFT (#x201c) and RIGHT (#x201d) DOUBLE QUOTATION MARK, and
> displays instead BACKSLASH and QUOTATION MARK (#x22).  It also works
> for QUOTATION MARK - @t{"}.  An ugly way to fix it would be @t{``} and
> @t{''}, but I think it's not an option.

@t{} is the best trick we have for these characters, so if it doesn't
work, someone will have to suggest a better way and verify it works in
PDF.  At the time we tried other methods, but AFAIR they were worse.

> In BASIC.TEXI - LINE 121:
> - and inserts `.  To see which characters have @kbd{C-x 8} ...
> + and inserts @t{‘}.  To see which characters have @kbd{C-x 8} ...
> Just like in L115.  This bug is present in HTML version as well.

Thanks, fixed.

> As for 1st occurrence in BASIC.TEXI - L149:
> # accent and apostrophe @t{`like this'}, it is converted to a form
> It could be corrected with @kbd{`}@t{like this}@kbd{'}.  Looks good
> in HTML.

Does @kbd{`like this'} work?  I don't want to use @t here, as this is
keyboard input.

> As for 3rd occurrence in BASIC.TEXI - L151:
> # commands.  Similarly, typing a quotation @t{``like this''} using
> As above - @kbd{``}@t{like this}@kbd{''}...  Looks bad in HTML.

Does @kbd{``like this''} work?

> In DISPLAY.TEXI - L1560:
> #  If the curved quotes @samp{‘}, @samp{’}, @samp{“}, and @samp{”} are
> Well here we have @samp{...} instead of @t{...}, which also fails to
> show “ and ”, displaying instead \ and " (just like @t{...}).  But
> it looks good in HTML.

I changed them all to use @t{}.

> In TEXT.TEXI - L427:
> # using straight apostrophes @t{'like this'} or double-quotes @t{"like
> Similar to above example, @kbd{'}@t{like this}@kbd{'}.  Looks good in
> HTML.

I don't understand why do we need to move away from @t{}.  the comment
clearly says that @t{} was found to do the job here.  What am I
missing?

> In TEXT.TEXI - L429:
> # left and right single or double quotation marks `@t{like this}' or
> Switch to - @t{‘like this’} - with #x2018 & #x2019.

Why?  `..' is converted by TeX to curve single quotes, and ``..'' to
curve double quotes.  What do you see in the PDF?

> In TEXT.TEXI - L442-443:
> - type characters it optionally converts @t{`} to ‘, @t{'} to ',
> - @t{``} to ``, and @t{''} to ''.  It's possible to change the
> + type characters it optionally converts @kbd{`} to @t{‘}, @kbd{'} to @t{’},
> + @kbd{``} to ??, and @kbd{''} to ??.  It's possible to change the
> Of course I don't know what to put for “ and ”, so I put ?? there.
> Also it looks bad in HTML.

I did what I could here.

> > I don't see anything wrong with the current typeface, so I left it
> > alone.
>
> In BASIC.TEXI - L116 we have:
>     @code{U+2018} LEFT SINGLE QUOTATION MARK
> In SEARCH.TEXI - L1313-1314 and L1319-1320 we have:
>     @sc{u+249c parenthesized latin small letter a}
>     @sc{u+2100 account of}
>     @sc{u+fb00 latin small ligature ff}
> In TEXT.TEXI - L430 (inside footnote) we have:
>     U+2018 LEFT SINGLE QUOTATION MARK
>     U+2018 RIGHT SINGLE QUOTATION MARK <--- this has wrong code!
>     U+201C LEFT DOUBLE QUOTATION MARK
>     U+201D RIGHT DOUBLE QUOTATION MARK
> So, 3 different styles.

We need to use a consistent style, that's true.

I think the @sc style is the best, because that's how the Unicode
Standard itself typesets the names in its printed version.

> I think @code{...} around Unicode code and uppercase "U" is a must.

@sc produce capital letters, so that part is OK.  As for @code, I
don't agree, and neither does the Unicode Standard.  Eventually, this
is a judgment call, so it's not a big deal that we don't agree.

> >> 6.  In INFO 15.1.1 Basics of Incremental Search:
> >> - ‘<ESC> <ESC> <ESC>’ (‘isearch-cancel’) or ‘C-g C-g’ (‘isearch-abort’).
> >> + ‘<ESC> <ESC> <ESC>’ (‘isearch-cancel’) or ‘C-g’ (‘isearch-abort’).
> >> Because `view-lossage' and `describe-bindings' and the last paragraph
> >> of 15.1.4 say: `C-g'.
> >
> > I left this unaltered, because in some cases you do need to type C-g
> > twice, so doing it twice always is safer.
>
> Well I think the last paragraph of 15.1.4 pointed by me explains this
> behaviour.  It exactly says that sometimes C-g needs to be typed twice
> to exit search.  That's why I'm sticking to my version, unless you had
> other cases in mind.  And "isearch-abort" is literally binded to "C-g"
> so it may rise questions.

This is a user manual, not a mathematical paper, it doesn't have to be
rigorously correct.  It must be useful, though, and I think the
current text is more useful because it avoids possible confusion, even
though the users may pay one more keystroke.  Okay?

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
> @t{} is the best trick we have for these characters, so if it doesn't
> work, someone will have to suggest a better way and verify it works in
> PDF.  At the time we tried other methods, but AFAIR they were worse.

Hmmm... if I use @t{“} (but without \rawbackslash \plainfrenchspacing)
or {\ttfamily “} or \texttt{“} in my 'test.tex' -> 'test.pdf' it
prints left double quotation mark correctly (i.e. in typewriter
shape), so... maybe there is something wrong with \rawbackslash or
\plainfrenchspacing or you used some older tex distribution with bug?

Also '\tt' inside @t{} as stated in "LATEX2e: An unofficial reference
manual" (November 2018) is "older version of font switching", so maybe
try newer - '\ttfamily', unless this was intentional.

As I mentioned before @t{``} and t@{''} would do the job, but I think
putting specific characters, i.e. “ and ” is intended.

> Does @kbd{`like this'} work?  I don't want to use @t here, as this is
> keyboard input.
> ...
> Does @kbd{``like this''} work?

Hmmm... I still don't know how to turn texi to pdf, so please don't
expect 100% answers, but I'm guessing it could work.  Also you forgot
about 4th occurrence there, but this is l/r double quotation mark
problem so...

>> In DISPLAY.TEXI - L1560:
>> #  If the curved quotes @samp{‘}, @samp{’}, @samp{“}, and @samp{”} are
>> Well here we have @samp{...} instead of @t{...}, which also fails to
>> show “ and ”, displaying instead \ and " (just like @t{...}).  But
>> it looks good in HTML.
>
> I changed them all to use @t{}.

Please revert this change.  I'm not sure what is the role of @samp{},
but they are everywhere in the manual.  I think they exist to
distinguish inserted (by something/someone in Emacs) characters that
are not part of the main text - they differ form @t{}, because they
add l/r single quotation marks in main (normal) text shape around
character.  With them we have problem only with l/r double quotation
mark, with @t{} problem won't be fixed and it'll cause additional
problems with some of the rest of quotes in this part of text.

Also I'm beginning to think, that our quotes should use @samp rather
than @t.  For example in "Inserting text" chapter if something inserts
thing, this thing is using @samp: user inserts ordinary graphic
character ‘a’, ‘B’, ‘3’, ‘=’, "C-q DEL" inserts ‘DEL’, "C-q 1 0 1 B"
inserts ‘AB’.  Maybe @t{} with "quotes" is mistake.

> In PDF 22.5 Quotation Marks:
> ...
> I don't understand why do we need to move away from @t{}.  the comment
> clearly says that @t{} was found to do the job here.  What am I
> missing?

Text says "using straight apostrophes" and with @t{'like this'} we'll
get curved ones (attached "pic2").  So @kbd{'like this'} should be ok.

> Why?  `..' is converted by TeX to curve single quotes, and ``..'' to
> curve double quotes.  What do you see in the PDF?

Yes, but they are in main text shape, not typewriter (again "pic2").

>> In TEXT.TEXI - L442-443:
> ...
> I did what I could here.

There will be problem of l/r double quotation mark, but it will look
better than before patch, so for now it's good.

> In TEXT.TEXI - L448:
> ...
> In TEXT.TEXI - L469:

You forgot about these, I cannot think of a solution for them.  First
one uses @code{} and I have no idea how it works, first apostrophe is
ok, so maybe just type @code{'(?‘ ?’ ?“ ?”)}?  Second one is typical
l/r double quotation mark, you could change it to @t{“} and @t{”} - it
won't fix it, but there will be some unification of bugs. :)

====================

As for Unicode, after reading your explanation and checking "The
Unicode Standard Version 12.0 – Core Specification" they seem to use
small caps for the name that is written in lowercase and main text
font for code with uppercase 'U' and letters if any in the code.

I can agree for small caps for name (lowercase!), but for code we
should go with @code{} - reason for this is that there are other
Unicode codes in the manual and they have @code{} "face", also
with main text or small caps Unicode code looks uglier (depends on
font) - letters are wider than numbers (sometimes higher), while with
typewriter (@code{}) they are equal.

So, my choice is:
@code{U+201D} @sc{right double quotation mark}

But if you really want to go with how Unicode docs do it, then:
U+201D @sc{right double quotation mark}

I made quick comparison:
\texttt{U+201D} \textsc{right double quotation mark}\\
\texttt{U+201D} \textsc{RIGHT DOUBLE QUOTATION MARK}\\
U+201D \textsc{right double quotation mark}\\
U+201D \textsc{RIGHT DOUBLE QUOTATION MARK}\\
\textsc{u+201d right double quotation mark}\\
\textsc{U+201D RIGHT DOUBLE QUOTATION MARK}
Each line corresponds to the line in "pic3".

====================

As for last part...

> This is a user manual, not a mathematical paper, it doesn't have to be
> rigorously correct.  It must be useful, though, and I think the
> current text is more useful because it avoids possible confusion, even
> though the users may pay one more keystroke.  Okay?

Well, maybe someone else will bring this up again in the future, until
then - OK.


In the meantime, I shouldn't do it but it's something similar so...

In INFO 15.10.4 (description of 'comma'):
... You can also type ‘C-x u’ to undo the replacement; this exits the
‘query-replace’,...
I just want to point out that other undo commands also work,
so maybe:
... You can also type any undo command to undo the replacement;...
or maybe combine both:
... You can also type any undo command (e.g. 'C-x u') to undo the...
Or is it nitpicking again? :)

pic3.png (34K) Download Attachment
pic2.png (78K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Eli Zaretskii
> From: Sebastian Urban <[hidden email]>
> Cc: [hidden email]
> Date: Wed, 5 Jun 2019 12:40:29 +0200
>
> > @t{} is the best trick we have for these characters, so if it doesn't
> > work, someone will have to suggest a better way and verify it works in
> > PDF.  At the time we tried other methods, but AFAIR they were worse.
>
> Hmmm... if I use @t{“} (but without \rawbackslash \plainfrenchspacing)
> or {\ttfamily “} or \texttt{“} in my 'test.tex' -> 'test.pdf' it
> prints left double quotation mark correctly (i.e. in typewriter
> shape), so... maybe there is something wrong with \rawbackslash or
> \plainfrenchspacing or you used some older tex distribution with bug?
>
> Also '\tt' inside @t{} as stated in "LATEX2e: An unofficial reference
> manual" (November 2018) is "older version of font switching", so maybe
> try newer - '\ttfamily', unless this was intentional.

Sorry, I don't understand what this means in practice.  We don't use
TeX/LaTeX in the manuals, we use Texinfo, so any raw TeX commands
could only come from texinfo.tex.  Is that where you saw \rawbackslash
etc.?  If not, where did you see them?

> As I mentioned before @t{``} and t@{''} would do the job, but I think
> putting specific characters, i.e. “ and ” is intended.

Yes, we intend to put these specific characters.

> > Does @kbd{`like this'} work?  I don't want to use @t here, as this is
> > keyboard input.
> > ...
> > Does @kbd{``like this''} work?
>
> Hmmm... I still don't know how to turn texi to pdf, so please don't
> expect 100% answers, but I'm guessing it could work.

I changed that to @kbd already, so I guess we should leave that for
now, and wait for complaints.

> Also you forgot about 4th occurrence there, but this is l/r double
> quotation mark problem so...

That's why I didn't do anything about it, yes.

> >> In DISPLAY.TEXI - L1560:
> >> #  If the curved quotes @samp{‘}, @samp{’}, @samp{“}, and @samp{”} are
> >> Well here we have @samp{...} instead of @t{...}, which also fails to
> >> show “ and ”, displaying instead \ and " (just like @t{...}).  But
> >> it looks good in HTML.
> >
> > I changed them all to use @t{}.
>
> Please revert this change.  I'm not sure what is the role of @samp{},
> but they are everywhere in the manual.

@samp is used a lot, but there's no reason to use it in the above
context.  If nothing else, it looks badly in Info, because it produces
an extra pair of quotes.  I used @t{} because it produces the best
results with quotes, AFAIR.

> I think they exist to distinguish inserted (by something/someone in
> Emacs) characters that are not part of the main text - they differ
> form @t{}, because they add l/r single quotation marks in main
> (normal) text shape around character.  With them we have problem
> only with l/r double quotation mark, with @t{} problem won't be
> fixed and it'll cause additional problems with some of the rest of
> quotes in this part of text.

Once again, I think @t produces the best results with quotes.  That
was AFAIR our conclusion from when we worked on this issue during
development of Emacs 26.1.  If you can show that the PDF which is
produced by that is incorrect, then we could try other methods, but
they all require producing PDF and examining the results, there's no
"correct" and "incorrect" method here by any other criteria.

> Also I'm beginning to think, that our quotes should use @samp rather
> than @t.  For example in "Inserting text" chapter if something inserts
> thing, this thing is using @samp: user inserts ordinary graphic
> character ‘a’, ‘B’, ‘3’, ‘=’, "C-q DEL" inserts ‘DEL’, "C-q 1 0 1 B"
> inserts ‘AB’.  Maybe @t{} with "quotes" is mistake.

That's not how I recollect this.  I think we originally did use @samp,
but moved to @t in the case of quotes because @samp gave sub-optimal
or even incorrect results.

> > In PDF 22.5 Quotation Marks:
> > ...
> > I don't understand why do we need to move away from @t{}.  the comment
> > clearly says that @t{} was found to do the job here.  What am I
> > missing?
>
> Text says "using straight apostrophes" and with @t{'like this'} we'll
> get curved ones (attached "pic2").  So @kbd{'like this'} should be ok.

I see nothing wrong with pic2, that's just how PDF renders "straight
apostrophes".  So I see no reason to move away from @t in this case.

> > Why?  `..' is converted by TeX to curve single quotes, and ``..'' to
> > curve double quotes.  What do you see in the PDF?
>
> Yes, but they are in main text shape, not typewriter (again "pic2").

I don't understand what problems you see in the shape, the text as
typeset looks OK to me.

> > In TEXT.TEXI - L448:
> > ...
> > In TEXT.TEXI - L469:
>
> You forgot about these, I cannot think of a solution for them.

I didn't forget, I just didn't know what to do, so I did nothing.

> As for Unicode, after reading your explanation and checking "The
> Unicode Standard Version 12.0 – Core Specification" they seem to use
> small caps for the name that is written in lowercase and main text
> font for code with uppercase 'U' and letters if any in the code.
>
> I can agree for small caps for name (lowercase!), but for code we
> should go with @code{} - reason for this is that there are other
> Unicode codes in the manual and they have @code{} "face", also
> with main text or small caps Unicode code looks uglier (depends on
> font) - letters are wider than numbers (sometimes higher), while with
> typewriter (@code{}) they are equal.
>
> So, my choice is:
> @code{U+201D} @sc{right double quotation mark}
>
> But if you really want to go with how Unicode docs do it, then:
> U+201D @sc{right double quotation mark}

OK, done.

> In INFO 15.10.4 (description of 'comma'):
> ... You can also type ‘C-x u’ to undo the replacement; this exits the
> ‘query-replace’,...
> I just want to point out that other undo commands also work,
> so maybe:
> ... You can also type any undo command to undo the replacement;...
> or maybe combine both:
> ... You can also type any undo command (e.g. 'C-x u') to undo the...
> Or is it nitpicking again? :)

I rearranged the words there to indicate that there other bindings of
'undo'.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
  > ...
  > could only come from texinfo.tex.  Is that where you saw \rawbackslash
  > etc.?  If not, where did you see them?

Yes in texinfo.tex, in the definition of @t{} (L2836).

Another idea is that maybe texinfo somehow doesn't recognize “ and ”
and uses ASCII approximations?

  > I changed that to @kbd already, so I guess we should leave that for
  > now, and wait for complaints.

I agree.

  > ... If you can show that the PDF which is produced by that is
  > incorrect, then we could try other methods...

More pictures, all of them are from Emacs manual for 26.2 (that's six
not five).

Pictures from chapter PDF4.1 & INFO7.1 Inserting Text: 'p1', 'p2'.

Pictures from chapter PDF11.19 & INFO14.19 How Text Is Displayed: 'p3'.

Pictures from chapter PDF22.5 & INFO25.5 Quotation Marks: see 'pic2'
from previous e-mail and 'p4', 'p5', 'p6'.

  > That's not how I recollect this.  I think we originally did use @samp,
  > but moved to @t in the case of quotes because @samp gave sub-optimal
  > or even incorrect results.

Ok, but @samp{} shows grave accent ` and apostrophe ' correctly, while
@t{} makes them curved.

  > I see nothing wrong with pic2, that's just how PDF renders "straight
  > apostrophes".  So I see no reason to move away from @t in this case.
  > ...
  > I don't understand what problems you see in the shape, the text as
  > typeset looks OK to me.

See picture 'npic2' (= pic2 + zoom in), clearly:

A. quotes on first /like this/ are curved, they must be straight,
otherwise "... typewriter convention, which quotes using straight
apostrophes..." will make no sense, because we will show incorrect
form.

B. `..' and ``..'' (second in npic2) also must be in typewriter shape
because we want to show how curved quote convention looks like, so
they are part of example and not part of main text (see picture 'p0'
for example of quote that is part of main text).


  >> But if you really want to go with how Unicode docs do it, then:
  >> U+201D @sc{right double quotation mark}
  >
  > OK, done.

Cool, except you need to correct Unicode code for right single
quotation mark form U+2018 to U+2019 (Quotation Marks chapter -
footnote).

  > I rearranged the words there to indicate that there other bindings
  > of 'undo'.

Thanks.



p1.png (9K) Download Attachment
p2.png (32K) Download Attachment
p3.png (19K) Download Attachment
p4.png (8K) Download Attachment
p5.png (8K) Download Attachment
p6.png (25K) Download Attachment
npic2.png (36K) Download Attachment
p0.png (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
 > Another idea is that maybe texinfo somehow doesn't recognize “ and ”
 > and uses ASCII approximations?

Small update.  The thing about quotes not being recognized may be good
idea, because when you compile:

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[OT4]{fontenc}
\begin{document}
{\ttfamily “like this”}
\end{document}

with OT4 or OT1 you will get \like this", but when you use 'T1' you
will get l/r double quotation marks.  So the problem may be in font
encoding.

As for straight apostrophe and grave accent someone who knows tex
should look into @kbd{} and @samp{} and @code{} to find what they
have, so they can display straight apostrophe and grave accent in
typewriter shape (i.e. not making them curved), and just apply the
code to @t{}.

I also found in MODES.TEXI - L210:
-example, it requotes text typed @t{`like this'} to text @t{‘like
+example, it requotes text typed @kbd{`like this'} to text @t{‘like
You may fix it just like you did in BASIC.TEXI.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Eli Zaretskii
In reply to this post by Sebastian Urban
> From: Sebastian Urban <[hidden email]>
> Cc: [hidden email]
> Date: Thu, 6 Jun 2019 11:49:33 +0200
>
>   > ... If you can show that the PDF which is produced by that is
>   > incorrect, then we could try other methods...
>
> More pictures, all of them are from Emacs manual for 26.2 (that's six
> not five).

OK, thanks.  Assuming that you have the latest Texinfo and the latest
texinfo.tex installed, feel free to propose specific patches for each
of the problematic places for which you have a satisfactory solution.
Then let's use those patches to fix the cases we know how, and leave
the rest for a better day.

I don't think it makes sense to continue discussing this one place at
a time, because I, for one, am losing context and need to go several
messages back to understand what is being discussed and why.

Thanks again for your efforts.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Eli Zaretskii
In reply to this post by Sebastian Urban
> Cc: [hidden email]
> From: Sebastian Urban <[hidden email]>
> Date: Thu, 6 Jun 2019 23:19:56 +0200
>
>  > Another idea is that maybe texinfo somehow doesn't recognize “ and ”
>  > and uses ASCII approximations?
>
> Small update.  The thing about quotes not being recognized may be good
> idea, because when you compile:
>
> \documentclass{article}
> \usepackage[utf8]{inputenc}
> \usepackage[OT4]{fontenc}
> \begin{document}
> {\ttfamily “like this”}
> \end{document}
>
> with OT4 or OT1 you will get \like this", but when you use 'T1' you
> will get l/r double quotation marks.  So the problem may be in font
> encoding.
>
> As for straight apostrophe and grave accent someone who knows tex
> should look into @kbd{} and @samp{} and @code{} to find what they
> have, so they can display straight apostrophe and grave accent in
> typewriter shape (i.e. not making them curved), and just apply the
> code to @t{}.

I'll leave this to someone who knows TeX.

> I also found in MODES.TEXI - L210:
> -example, it requotes text typed @t{`like this'} to text @t{‘like
> +example, it requotes text typed @kbd{`like this'} to text @t{‘like
> You may fix it just like you did in BASIC.TEXI.

Fixed, thanks.

>   >> But if you really want to go with how Unicode docs do it, then:
>   >> U+201D @sc{right double quotation mark}
>   >
>   > OK, done.
>
> Cool, except you need to correct Unicode code for right single
> quotation mark form U+2018 to U+2019 (Quotation Marks chapter -
> footnote).

Fixed.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
In reply to this post by Eli Zaretskii
> I don't think it makes sense to continue discussing this one place
> at a time, because I, for one, am losing context and need to go
> several messages back to understand what is being discussed and why.

Alright, the following bug(?) is the last one in this thread form me,
i.e. I'll consider this thread closed and if I find anything new (or
a solution to quotes) I'll send new bug report.

In KILLING.TEXI - L125-127:
  leaves @var{n} spaces before point if @var{n} is positive; if @var{n}
  is negative, it deletes newlines in addition to spaces and tabs,
-leaving @var{-n} spaces before point.  The command @code{cycle-spacing}
+leaving @var{n} spaces before point.  The command @code{cycle-spacing}

There 'n' stands just for number of spaces, so no need for negative
or positive mark.  Also documentation string in SIMPLE.EL for
'just-one-space' will need correction, because there is '-N'.

Maybe we could even abridge whole sentence to something like this:

With a positive numeric argument @var{n}, it leaves @var{n} spaces
before point; if @var{n} is negative, it also deletes newlines.

Unless it works differently than I think it does.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Eli Zaretskii
> From: Sebastian Urban <[hidden email]>
> Cc: [hidden email]
> Date: Mon, 10 Jun 2019 12:30:52 +0200
>
> In KILLING.TEXI - L125-127:
>   leaves @var{n} spaces before point if @var{n} is positive; if @var{n}
>   is negative, it deletes newlines in addition to spaces and tabs,
> -leaving @var{-n} spaces before point.  The command @code{cycle-spacing}
> +leaving @var{n} spaces before point.  The command @code{cycle-spacing}
>
> There 'n' stands just for number of spaces, so no need for negative
> or positive mark.  Also documentation string in SIMPLE.EL for
> 'just-one-space' will need correction, because there is '-N'.

I don't think I understand (and if I do, I disagree).  The text says:

  if N is negative, ... leaving -N spaces before point.

When N is negative, -N is positive, so the original text sounds
correct to me.

> With a positive numeric argument @var{n}, it leaves @var{n} spaces
> before point; if @var{n} is negative, it also deletes newlines.

This has the same problem as omitting the minus sign in your
suggestion above.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
> When N is negative, -N is positive, so the original text sounds
> correct to me.

Of course this way it's correct, but as you wrote few mails before
"This is a user manual, not a mathematical paper (...)" and this
(-1) x (-N) seems like unnecessary burden.  And without it
expressions like "... leaving -N spaces..." or (look below) "mark the
previous −N files" makes no sense.  Readers will more likely to
interpret this '-' as negation of "previous" word.  Just like D. Adams
wrote "(...) it's not obvious - it's easy to misread it.  Of course,
it's not possible to leave a negative number of spaces (...).
A careful reader will figure it out, but that might mean having to
read it more than once."

I was curious how it looks in other examples where 'N' is present,
here is the list:

1. In INFO @ 11.2 Commands to Mark Textual Objects:
A negative argument moves the mark back by N words.

2. In INFO @ 12.1.2 Killing by Lines:
With a negative argument −N, it kills N lines preceding the current
line, together with the text on the current line before point.

3. In INFO @ 14.2 Recentering:
A negative argument -N puts point N lines from the bottom of the
window.

4. In INFO @ 25.2 Sentences
... with a negative argument −N, it kills back to the beginning of the
Nth preceding sentence.

5. In INFO @ 26.2.2 Moving by Defuns:
‘C-M-a’ with a negative argument −N moves forward N times to the next
beginning of a defun.

6. In INFO @ 26.5.1 Comment Commands:
A positive argument N adds N delimiters, while a negative argument -N
removes N delimiters.
...
With a positive prefix argument N, it operates on N lines starting
with the current one; with a negative N, it affects N preceding lines.

7. In INFO @ 30.6 Dired Marks vs. Flags :
[at '* m']... (if N is negative, mark the previous −N files)...
...
[at '* u']... (if N is negative, unmark the previous −N files)...
...
[at '* <DEL>']... (if N is negative, unmark the next −N files)...

8. In INFO @ 30.7 Operating on Files:
(If N is negative, the command operates on the −N files preceding the
current line.)

--- end of examples ---

So, in 2., 3., 4., 5., 6.(1st), we have pattern of "negative argument
-N ... something N something..."

In 1. it's something similar but without '-N' just "negative
argument", also 6.(2nd) is something similar but 'N' doesn't have
minus sign.

But in 7. and 8. (and the one I already sent) we have "if N is
negative... something -N something".

So, after looking at more examples, I think the best idea would be to
go with the most used pattern, therefore:
    - add '-N' to 1.,
    - add minus sign do 6.(2nd),
    - replace - in 7., 8., and the one I sent - "if N is negative"
      with "with negative argument -N" then change '-N' to 'N' in the
      rest of each sentence.

There is also a problem of minus sign, or to simply put - lack of it
in 3. and 6.(1st) and the one I sent - there we can see "hyphen-minus"
(#x2d).  In other cases it is "minus sign" (#x2212).

If we agree on this I could send message with "In FILENAME.TEXI
L?-? change this line to this" if it helps you (I don't know how
to make normal patches, sorry).



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Eli Zaretskii
> From: Sebastian Urban <[hidden email]>
> Cc: [hidden email]
> Date: Tue, 11 Jun 2019 12:32:36 +0200
>
> So, in 2., 3., 4., 5., 6.(1st), we have pattern of "negative argument
> -N ... something N something..."
>
> In 1. it's something similar but without '-N' just "negative
> argument", also 6.(2nd) is something similar but 'N' doesn't have
> minus sign.
>
> But in 7. and 8. (and the one I already sent) we have "if N is
> negative... something -N something".
>
> So, after looking at more examples, I think the best idea would be to
> go with the most used pattern, therefore:
>     - add '-N' to 1.,
>     - add minus sign do 6.(2nd),
>     - replace - in 7., 8., and the one I sent - "if N is negative"
>       with "with negative argument -N" then change '-N' to 'N' in the
>       rest of each sentence.
>
> There is also a problem of minus sign, or to simply put - lack of it
> in 3. and 6.(1st) and the one I sent - there we can see "hyphen-minus"
> (#x2d).  In other cases it is "minus sign" (#x2212).

I fixed the inconsistencies with the minus sign vs hyphen.  As for the
few examples saying "if N is negative <do something> −N times": sorry,
I cannot see anything wrong with such wording, so I left those few
examples alone.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Sebastian Urban
> As for the few examples saying "if N is negative <do something> −N
> times": sorry, I cannot see anything wrong with such wording, so
> I left those few examples alone.

Well I don't think I can explain this more clearly, so I'm going to
put this next to 'C-g C-g' "problem", i.e. we will wait for other
opinions if they ever appear.  Until then I'll consider this thread
closed.

And of course thank you for many other fixes from this thread.



Reply | Threaded
Open this post in threaded view
|

bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals)

Drew Adams
> > As for the few examples saying "if N is negative <do something> −N
> > times": sorry, I cannot see anything wrong with such wording, so
> > I left those few examples alone.
>
> Well I don't think I can explain this more clearly, so I'm going to
> put this next to 'C-g C-g' "problem", i.e. we will wait for other
> opinions if they ever appear.  Until then I'll consider this thread
> closed.

"I cannot see anything wrong with such wording", versus
it could be improved a bit to avoid confusion like that
evidenced by this bug report.

A user reading "...-N..." CAN easily misread it.  Yes,
MISread.  There is not "anything wrong" with it, in the
sense that if you read it right you won't misunderstand
it.  But that's a low bar, and Emacs can do better.

To read it right you have to have grasped and recalled
that N is a placeholder for an integer value, and in
the context of that `-N' occurrence it is a placeholder
for a negative integer.

Understanding that that's the case, a reader will also
correctly interpret the `-' as a minus sign (not, e.g.,
as a dash or hyphen or whatever else in ordinary text).

MISunderstanding, a reader can easily not interpret the
math expression `-N' as math at all.  (And note that
it's not within `...', so it's likely not taken as Lisp
math.

If we instead use `(abs N)', that makes clear - yes, as
a reminder or a pay-attention note - that N is a number
and the result of that expression is its absolute value.
That clues a reader into the fact that N might be - in
fact is in this case - negative.

It's not about proving that the `-N' wording is guilty
or defending its innocence in a court case.  It's about
making things a little clearer.  It's about seeing it
from the point of view of someone who might misread it.