Re: [Emacs-diffs] emacs-25 3e14bad: Document new features of Prettify Mode

Re: [Emacs-diffs] emacs-25 3e14bad: Document new features of Prettify Mode

[John Wiegley]

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

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>     Document the new bindings of <UP> and <DOWN> in the minibuffer
>     Document new features of Ido
>     Document the change in interactive shell mode
>     Document new features of package.el
>     Update and document new features of xterm support
>     Document new features of Prettify Mode
>     Document multi-mode indentation facilities
>     Document 'vc-refresh-state'

Eli, much respect.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: [Emacs-diffs] emacs-25 3e14bad: Document new features of Prettify Mode

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Mon, 14 Dec 2015 17:36:28 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >     Document the new bindings of <UP> and <DOWN> in the minibuffer
> >     Document new features of Ido
> >     Document the change in interactive shell mode
> >     Document new features of package.el
> >     Update and document new features of xterm support
> >     Document new features of Prettify Mode
> >     Document multi-mode indentation facilities
> >     Document 'vc-refresh-state'
> 
> Eli, much respect.

Thanks, I'm still only 35% into NEWS, and no one else seems to care.

Re: [Emacs-diffs] emacs-25 3e14bad: Document new features of Prettify Mode

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, I'm still only 35% into NEWS, and no one else seems to care.

Would anyone else like to help out Eli with documenting the new features that
will be coming into 25.1?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [Emacs-diffs] emacs-25 3e14bad: Document new features of Prettify Mode

[Shakthi Kannan]

Hi Eli,

--- On Tue, Dec 15, 2015 at 11:40 AM, John Wiegley <jwiegley@gmail.com> wrote:
| Would anyone else like to help out Eli with documenting the new features that
| will be coming into 25.1?
\--

I shall pick this up.

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Documenting NEWS features for 25.1 (was: [Emacs-diffs] emacs-25 3e14bad: Document new features of Prettify Mode)

[John Wiegley]

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

>>>>> Shakthi Kannan <shakthimaan@gmail.com> writes:

> I shall pick this up.

Eli, would you be willing to identify the list of features in NEWS still
needing work? I'm going to speak to more developers at an Emacs user's group
meeting in about an hour, and will mention to them also that you need help in
this area.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Documenting NEWS features for 25.1 (was: [Emacs-diffs] emacs-25 3e14bad: Document new features of Prettify Mode)

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Emacs developers <emacs-devel@gnu.org>
> Date: Tue, 15 Dec 2015 09:58:56 -0800
> 
> >>>>> Shakthi Kannan <shakthimaan@gmail.com> writes:
> 
> > I shall pick this up.
> 
> Eli, would you be willing to identify the list of features in NEWS still
> needing work?

Each entry that is not already marked needs either to be documented,
or a decision should be made that it doesn't need to be.  See the
beginning of NEWS for the legend.

I'd prefer that people who never did this kind of job before in Emacs
ask here each time whether a certain entry should be reflected in
documentation or not, and then documenting those that should.

Please note that the doc strings of the code corresponding to each
entry should also be reviewed, to see if they are clear enough and
complete.  Bonus points for trying the feature and reporting any
unusual findings.

> I'm going to speak to more developers at an Emacs user's group
> meeting in about an hour, and will mention to them also that you
> need help in this area.

Thanks.

Re: Documenting NEWS features for 25.1 (was: [Emacs-diffs] emacs-25 3e14bad: Document new features of Prettify Mode)

[Shakthi Kannan]

Eli,

--- On Wed, Dec 16, 2015 at 12:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
| I'd prefer that people who never did this kind of job before in Emacs
| ask here each time whether a certain entry should be reflected in
| documentation or not, and then documenting those that should.
\--

For "Document the change in interactive shell mode", I already see a
commit "4b0e4213740ef32938063e1dd79f8462112ca33c" with the same
subject in emacs-25 branch. So, this is done? Which among the
following needs to be documented?

     Document the new bindings of <UP> and <DOWN> in the minibuffer
     Document new features of Ido
     Document the change in interactive shell mode
     Document new features of package.el
     Update and document new features of xterm support
     Document new features of Prettify Mode
     Document multi-mode indentation facilities
     Document 'vc-refresh-state'

Would it be possible to use a TODO list in the NEWS file to indicate
which parts need to be documented, and are in a pending state?

Thanks!

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: Documenting NEWS features for 25.1

[John Wiegley]

>>>>> Shakthi Kannan <shakthimaan@gmail.com> writes:

>  Which among the following needs to be documented?
[...]

The list I gave there was what Eli had documented just yesterday!

> Would it be possible to use a TODO list in the NEWS file to indicate which
> parts need to be documented, and are in a pending state?

Check the NEWS file itself. I believe that entries lacking a +++ or --- marker
need attention. For each of those, ask here about what is needed to proceed.
That should generate the TODO list that you're looking for.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Documenting NEWS features for 25.1

[Shakthi Kannan]

Hi,

--- On Wed, Dec 16, 2015 at 12:14 PM, John Wiegley <jwiegley@gmail.com> wrote:
| Check the NEWS file itself. I believe that entries lacking a +++ or --- marker
| need attention. For each of those, ask here about what is needed to proceed.
| That should generate the TODO list that you're looking for.
\--

Got it.  Can I write one for the following, and send a patch to this thread?

** Lisp mode
*** Strings after `:documentation' are highlighted as docstrings.

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: Documenting NEWS features for 25.1

[Eli Zaretskii]

> Date: Wed, 16 Dec 2015 13:29:13 +0530
> From: Shakthi Kannan <shakthimaan@gmail.com>
> 
> Got it.  Can I write one for the following, and send a patch to this thread?
> 
> ** Lisp mode
> *** Strings after `:documentation' are highlighted as docstrings.

Yes, thanks.

Please send patches to bug-gnu-emacs@gnu.org, though.

Re: Documenting NEWS features for 25.1

[Shakthi Kannan]

Eli,

---
| *** Strings after `:documentation' are highlighted as docstrings.
\--

Is there a sample function that demonstrates the above that I can test
and verify?

(defun test nil
    "echo Hello, World!"
  (message "Hello, World"))

Where does :documentation fit in the above example?

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: Documenting NEWS features for 25.1

[Eli Zaretskii]

> Date: Wed, 16 Dec 2015 16:06:34 +0530
> From: Shakthi Kannan <shakthimaan@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Eli,
> 
> ---
> | *** Strings after `:documentation' are highlighted as docstrings.
> \--
> 
> Is there a sample function that demonstrates the above that I can test
> and verify?
> 
> (defun test nil
>     "echo Hello, World!"
>   (message "Hello, World"))
> 
> Where does :documentation fit in the above example?

I don't know, sorry.

Some NEWS entries turn out to be small research projects.  What I
usually do is use "git annotate" on NEWS to find what commit added the
entry, then look at the commit itself, and if necessary also at
discussions or bug reports it points to (or any related discussions on
the 2 mailing lists around the date of the commit).

If none of this gets you the answer, I guess contacting the author of
the commit is yet another way to find out.

Thanks.

Re: Documenting NEWS features for 25.1

[Shakthi Kannan]

Hi,

--- On Wed, Dec 16, 2015 at 4:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
| Some NEWS entries turn out to be small research projects.  What I
| usually do is use "git annotate" on NEWS to find what commit added the
| entry, then look at the commit itself, and if necessary also at
| discussions or bug reports it points to (or any related discussions on
| the 2 mailing lists around the date of the commit).
\--

Got it. Thanks! Found the bug:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9130

Will send the patch soon.

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: Documenting NEWS features for 25.1

[Shakthi Kannan]

Hi Eli,

For the entry in etc/NEWS that contains:

    **** Macro `calendar-for-loop'.

I found that this macro has been removed in lisp/calendar/calendar.el
in commit ("3f65970414538063e38ada2a47cb4ef4f35b630e") and has been
mentioned in ChangeLog.17 by "2014-10-06 Glenn Morris <rgm@gnu.org>".
Can the news entry be the following?

=== BEGIN ===

---
**** Macro `calendar-for-loop'.
The calendar-for-loop macro in lisp/calendar/calendar.el has been made obsolete.

=== END ===

SK

--
Shakthi Kannan
http://www.shakthimaan.com

Re: Documenting NEWS features for 25.1

[Eli Zaretskii]

> Date: Mon, 21 Dec 2015 22:39:15 +0530
> From: Shakthi Kannan <shakthimaan@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> For the entry in etc/NEWS that contains:
> 
>     **** Macro `calendar-for-loop'.
> 
> I found that this macro has been removed in lisp/calendar/calendar.el
> in commit ("3f65970414538063e38ada2a47cb4ef4f35b630e") and has been
> mentioned in ChangeLog.17 by "2014-10-06 Glenn Morris <rgm@gnu.org>".
> Can the news entry be the following?
> 
> === BEGIN ===
> 
> ---
> **** Macro `calendar-for-loop'.
> The calendar-for-loop macro in lisp/calendar/calendar.el has been made obsolete.
> 
> === END ===

There's a header above that which says:

  *** Many items obsolete since at least version 23.1 have been removed.

And it is already marked with "---", which covers this entry as well.
So I think this entry (and all its siblings) is already taken care of.

Thanks.

Re: Documenting NEWS features for 25.1

[Shakthi Kannan]

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

Hi,

NEWS entry:

  ** New ERT function `ert-summarize-tests-batch-and-exit'.

I have verified the function by creating a sample test.el file whose
contents are as follows:

  (ert-deftest example-test ()
    (should (= (+ 9 2) 11)))

I was able to run the test, and capture the output using:

  $ emacs -batch -l ert -l test.el -f ert-run-tests-batch > test.log

I compiled emacs-25, and ran the following to produce the expected
summary result as shown below:

  $ ./src/emacs -batch -l ert -f ert-summarize-tests-batch-and-exit test.log

SUMMARY OF TEST RESULTS
-----------------------
Files examined: 1
Ran 1 tests, 1 results as expected

Is the attached documentation change fine? I can then send you an actual patch.

Regards,

SK

--
Shakthi Kannan
http://www.shakthimaan.com

[-- Attachment #2: ert-summarize.patch --]
[-- Type: text/x-patch, Size: 1270 bytes --]

diff --git a/doc/misc/ert.texi b/doc/misc/ert.texi
index 35d315c..d29c1d8 100644
--- a/doc/misc/ert.texi
+++ b/doc/misc/ert.texi
@@ -283,6 +283,15 @@ Running Tests in Batch Mode
 failed or if anything else went wrong.  It will also print progress
 messages and error diagnostics to standard output.
 
+You can also redirect the above output to a log file, say
+@code{output.log}, and use the
+@code{ert-summarize-tests-batch-and-exit} function to produce a neat
+summary as shown below:
+
+@example
+emacs -batch -l ert -f ert-summarize-tests-batch-and-exit output.log
+@end example
+
 If ERT is not part of your Emacs distribution, you may need to use
 @code{-L /path/to/ert/} so that Emacs can find it.  You may need
 additional @code{-L} flags to ensure that @code{my-tests.el} and all the
diff --git a/etc/NEWS b/etc/NEWS
index 19c9858..f1ba79f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -696,7 +696,11 @@ The remainder were:
 
 **** The nil and list forms of `diary-display-function'.
 
++++
 ** New ERT function `ert-summarize-tests-batch-and-exit'.
+If the output of ERT tests in batch mode execution can be saved to a
+log file, then it can be passed as an argument to the above function
+to produce a neat summary.
 
 ** New js.el option `js-indent-first-init'.
 

Re: Documenting NEWS features for 25.1

[Eli Zaretskii]

> Date: Thu, 24 Dec 2015 22:19:33 +0530
> From: Shakthi Kannan <shakthimaan@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Is the attached documentation change fine?

Yes, with one minor comment:

> +You can also redirect the above output to a log file, say
> +@code{output.log}, and use the
   ^^^^^^^^^^^^^^^^^
Please use the @file markup for file names, not @code.

Other than that, LGTM.  Thanks!

Re: Documenting NEWS features for 25.1

[Shakthi Kannan]

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

Hi,

Attached is a patch for "Document TeX mode custom variable and
prettify symbols".

Please let me know if this is fine or if you need changes, and I can
then submit it to bug-gnu-emacs.

Thanks!

SK

--
Shakthi Kannan
http://www.shakthimaan.com

[-- Attachment #2: 0001-Document-TeX-mode-custom-variable-and-prettify-symbo.patch --]
[-- Type: text/x-patch, Size: 3834 bytes --]

From 5d3f64033b73022553f30e842a564924bf00a456 Mon Sep 17 00:00:00 2001
From: Shakthi Kannan <author@shakthimaan.com>
Date: Mon, 28 Dec 2015 22:49:53 +0530
Subject: [PATCH] Document TeX mode custom variable and prettify symbols

---
 doc/emacs/programs.texi | 18 ++++++++++--------
 doc/emacs/text.texi     |  8 +++++++-
 etc/NEWS                |  2 ++
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/doc/emacs/programs.texi b/doc/emacs/programs.texi
index 8423b70..f485983 100644
--- a/doc/emacs/programs.texi
+++ b/doc/emacs/programs.texi
@@ -1530,14 +1530,16 @@ Misc for Programs
   Prettify Symbols mode is a buffer-local minor mode that replaces
 certain strings with more attractive versions for display purposes.
 For example, in Emacs Lisp mode, it replaces the string @samp{lambda}
-with the Greek lambda character @samp{λ}.  You may wish to use this in
-non-programming modes as well.  You can customize the mode by adding
-more entries to @code{prettify-symbols-alist}.  More elaborate
-customization is available via customizing
-@code{prettify-symbols-compose-predicate} if its default value
-@code{prettify-symbols-default-compose-p} is not appropriate.  There
-is also a global version, @code{global-prettify-symbols-mode}, which
-enables the mode in all buffers that support it.
+with the Greek lambda character @samp{λ}. In a TeX buffer, it will
+replace @samp{\alpha} ... @samp{\omega} and other math macros with
+their unicode characters. You may wish to use this in non-programming
+modes as well.  You can customize the mode by adding more entries to
+@code{prettify-symbols-alist}.  More elaborate customization is
+available via customizing @code{prettify-symbols-compose-predicate} if
+its default value @code{prettify-symbols-default-compose-p} is not
+appropriate.  There is also a global version,
+@code{global-prettify-symbols-mode}, which enables the mode in all
+buffers that support it.
 
   The symbol at point can be shown in its original form.  This is
 controlled by the variable @code{prettify-symbols-unprettify-at-point}:
diff --git a/doc/emacs/text.texi b/doc/emacs/text.texi
index bab660e..c91b26c 100644
--- a/doc/emacs/text.texi
+++ b/doc/emacs/text.texi
@@ -1717,6 +1717,7 @@ TeX Print
 @vindex latex-run-command
 @vindex tex-dvi-view-command
 @vindex tex-dvi-print-command
+@vindex tex-print-file-extension
   The buffer's @TeX{} variant determines what shell command @kbd{C-c
 C-b} actually runs.  In Plain @TeX{} mode, it is specified by the
 variable @code{tex-run-command}, which defaults to @code{"tex"}.  In
@@ -1725,7 +1726,12 @@ TeX Print
 to view the @file{.dvi} output is determined by the variable
 @code{tex-dvi-view-command}, regardless of the @TeX{} variant.  The
 shell command that @kbd{C-c C-p} runs to print the output is
-determined by the variable @code{tex-dvi-print-command}.
+determined by the variable @code{tex-dvi-print-command}. The variable
+@code{tex-print-file-extension} can be set to the required file
+extension for viewing and printing Tex-compiled files. For example,
+you can set it to @code{".pdf"}, and update
+@code{tex-dvi-view-command} and @code{tex-dvi-print-command}
+accordingly.
 
   Normally, Emacs automatically appends the output file name to the
 shell command strings described in the preceding paragraph.  For
diff --git a/etc/NEWS b/etc/NEWS
index 1aeab35..76d6df2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -879,9 +879,11 @@ name patterns (e.g. all "FOR_DOXYGEN_ONLY_*") to be excluded.
 
 ** TeX mode
 
++++
 *** New custom variable `tex-print-file-extension' to help users who
 use PDF instead of DVI.
 
++++
 *** TeX mode now supports Prettify Symbols mode.  When enabling
 `prettify-symbols-mode' in a tex-mode buffer, \alpha ... \omega, and
 many other math macros are displayed using unicode characters.
-- 
2.1.4

Re: Documenting NEWS features for 25.1

[Eli Zaretskii]

> Date: Mon, 28 Dec 2015 22:55:50 +0530
> From: Shakthi Kannan <shakthimaan@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Attached is a patch for "Document TeX mode custom variable and
> prettify symbols".

Thanks.  A few comments below.

> +with the Greek lambda character @samp{λ}. In a TeX buffer, it will
                                           ^^     ^^^
Two spaces between sentences, please (we use the US English
conventions).

Also, please use @TeX{} for "TeX", the result looks prettier in the
printed manual and in PDF.

> +replace @samp{\alpha} ... @samp{\omega} and other math macros with
                         ^^^
Please use @dots{} for "...", the result looks prettier in print.

> +their unicode characters. You may wish to use this in non-programming
         ^^^^^^^           ^^
"Unicode", capitalized.  And 2 spaces after the sentence again.

> @@ -1725,7 +1726,12 @@ TeX Print
>  to view the @file{.dvi} output is determined by the variable
>  @code{tex-dvi-view-command}, regardless of the @TeX{} variant.  The
>  shell command that @kbd{C-c C-p} runs to print the output is
> -determined by the variable @code{tex-dvi-print-command}.
> +determined by the variable @code{tex-dvi-print-command}. The variable
                                                          ^^
Two spaces.

> +@code{tex-print-file-extension} can be set to the required file
> +extension for viewing and printing Tex-compiled files. For example,
                                      ^^^               ^^
@TeX{} and 2 spaces.

> +you can set it to @code{".pdf"}, and update

The correct markup for file names and their parts is @file{.pdf} (no
quotes are necessary, as @file will supply them).

Thanks again for working on this.

Spaces after periods (was: Documenting NEWS features for 25.1)

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> +with the Greek lambda character @samp{λ}. In a TeX buffer, it will
>                                            ^^     ^^^
> Two spaces between sentences, please (we use the US English
> conventions).

I almost hate to say this, but I'm not sure this is the English convention
anymore. A quick Google shows many, many sites that indicate that the modern
convention is now one space, and none that recommend two spaces. I've even
changed to one space in my e-mails, even, after being a long holdout for the
two space rule.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Spaces after periods

[David Kastrup]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> +with the Greek lambda character @samp{λ}. In a TeX buffer, it will
>>                                            ^^     ^^^
>> Two spaces between sentences, please (we use the US English
>> conventions).
>
> I almost hate to say this, but I'm not sure this is the English
> convention anymore.

It is the Emacs convention, however, making it possible for Emacs to
distinguish abbreviations from sentence ends when wrapping lines.  It is
modelled after the conventions for _typewriters_.  Typewriting fonts are
monospace, and as a text editor rather than a word processor, typical
Emacs usage involves quite a bit of monospace fonts.

> A quick Google shows many, many sites that indicate that the modern
> convention is now one space, and none that recommend two spaces.

I suspect that it's more of a "trust your word processor to figure out
the proper spacing" thing.

> I've even changed to one space in my e-mails, even, after being a long
> holdout for the two space rule.

Well, Emacs does not wrap lines nicely with single spaces.  You can, of
course, customize sentence-end-double-space.  But then Emacs can no
longer distinguish sentence ends from abbreviations reliably.

-- 
David Kastrup

Re: Spaces after periods (was: Documenting NEWS features for 25.1)

[Nikolai Weibull]

On Tue, Dec 29, 2015 at 6:05 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> +with the Greek lambda character @samp{λ}. In a TeX buffer, it will
>>                                            ^^     ^^^
>> Two spaces between sentences, please (we use the US English
>> conventions).
>
> I almost hate to say this, but I'm not sure this is the English convention
> anymore. A quick Google shows many, many sites that indicate that the modern
> convention is now one space, and none that recommend two spaces. I've even
> changed to one space in my e-mails, even, after being a long holdout for the
> two space rule.

I haven’t seen a style guide that says anything other than that one
space is preferred.  However, I thought the general rule was to use
two spaces to make it easy for software (oh, the continued irony of it
all) to distinguish sentence-ending periods from other periods.

Also, any typesetting software that doesn’t fold multiple spaces into
one isn’t a typesetting software.  Microsoft Word isn’t a typesetting
software.  TeX is a typesetting software, so using multiple spaces
shouldn’t affect the output at all.  (Perhaps Texinfo is different?)
Though, TeX, as far as I recall, favors adding space after a period
when justifying a paragraph.

Re: Spaces after periods (was: Documenting NEWS features for 25.1)

[Ingo Lohmar]

On Tue, Dec 29 2015 18:32 (+0100), Nikolai Weibull wrote:

> On Tue, Dec 29, 2015 at 6:05 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> +with the Greek lambda character @samp{λ}. In a TeX buffer, it will
>>>                                            ^^     ^^^
>>> Two spaces between sentences, please (we use the US English
>>> conventions).
>>
>> I almost hate to say this, but I'm not sure this is the English convention
>> anymore. A quick Google shows many, many sites that indicate that the modern
>> convention is now one space, and none that recommend two spaces. I've even
>> changed to one space in my e-mails, even, after being a long holdout for the
>> two space rule.
>
> I haven’t seen a style guide that says anything other than that one
> space is preferred.  However, I thought the general rule was to use
> two spaces to make it easy for software (oh, the continued irony of it
> all) to distinguish sentence-ending periods from other periods.
>
> Also, any typesetting software that doesn’t fold multiple spaces into
> one isn’t a typesetting software.  Microsoft Word isn’t a typesetting
> software.  TeX is a typesetting software, so using multiple spaces
> shouldn’t affect the output at all.  (Perhaps Texinfo is different?)
> Though, TeX, as far as I recall, favors adding space after a period
> when justifying a paragraph.

The "modern" rule of using a single space applies to systems that
distinguish sentence-end punctuation in a different way.  And any book
typesetter worth his salt will make sure, one way or another, that the
visual space between sentences is larger than between words (in the same
line).

The two-space rule (as mentioned above) originates in typewriter use,
where the writer is reponsible for the visual appearance as well.  The
relevant point is that on such devices there is no distinction between
how to write the text and how it displays.

In software, the analogue is (to my knowledge) a word processor like MS
Word (WYSIWYG), while TeX (as a typesetting software) *does* make a
strong distinction.

In my opinion, plain-text formats in general (assuming that they are
written for the most part as one displayed char per one typed key) fit
into the former category, that's why the two-space convention is very
sensible.

There is no a priori reason why the visual distinction could not be
applied by a (TeX-like) processing step, in Info manuals or elsewhere.
But without such a mechanism in place, I hope Emacs sticks to the
two-space rule.

Re: Spaces after periods (was: Documenting NEWS features for 25.1)

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Shakthi Kannan <shakthimaan@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 29 Dec 2015 09:05:18 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> +with the Greek lambda character @samp{λ}. In a TeX buffer, it will
> >                                            ^^     ^^^
> > Two spaces between sentences, please (we use the US English
> > conventions).
> 
> I almost hate to say this, but I'm not sure this is the English convention
> anymore.

The GNU Coding Standards still say it is.

Re: Spaces after periods (was: Documenting NEWS features for 25.1)

[Marcin Borkowski]

On 2015-12-29, at 18:32, Nikolai Weibull <now@disu.se> wrote:

> On Tue, Dec 29, 2015 at 6:05 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> +with the Greek lambda character @samp{λ}. In a TeX buffer, it will
>>>                                            ^^     ^^^
>>> Two spaces between sentences, please (we use the US English
>>> conventions).
>>
>> I almost hate to say this, but I'm not sure this is the English convention
>> anymore. A quick Google shows many, many sites that indicate that the modern
>> convention is now one space, and none that recommend two spaces. I've even
>> changed to one space in my e-mails, even, after being a long holdout for the
>> two space rule.

http://tvtropes.org/pmwiki/pmwiki.php/Main/BigNo

> I haven’t seen a style guide that says anything other than that one
> space is preferred.  However, I thought the general rule was to use
> two spaces to make it easy for software (oh, the continued irony of it
> all) to distinguish sentence-ending periods from other periods.

Don't really see the irony: this is just plain difficult for a machine.
(I also use two spaces, btw.)

> Also, any typesetting software that doesn’t fold multiple spaces into
> one isn’t a typesetting software.  Microsoft Word isn’t a typesetting
> software.  TeX is a typesetting software, so using multiple spaces
> shouldn’t affect the output at all.  (Perhaps Texinfo is different?)
> Though, TeX, as far as I recall, favors adding space after a period
> when justifying a paragraph.

To be more precise, it does it by default, but it can be turned off (by
\frenchspacing).  Also, in TeX, not only are the spaces after periods
larger, but they also grow "faster" when justifying text (as you said).
See "space factor" in The TeXbook, if you are curious about the
details.  (Interestingly enough, this mechanism can be hackedto achieve
some other goals, too.)

OTOH, Bringhurst criticizes the above style very harshly.

OYAH, https://xkcd.com/1285/ . ;-)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Spaces after periods

[John Wiegley]

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

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> I almost hate to say this, but I'm not sure this is the English convention
>> anymore.

> The GNU Coding Standards still say it is.

Thank you for such a brief and definitive answer. Two spaces it is, then,
until the GNU Coding Standard has changed.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Spaces after periods (was: Documenting NEWS features for 25.1)

[Nikolai Weibull]

On Tue, Dec 29, 2015 at 8:05 PM, Marcin Borkowski <mbork@mbork.pl> wrote:

> On 2015-12-29, at 18:32, Nikolai Weibull <now@disu.se> wrote:

>> I haven’t seen a style guide that says anything other than that one
>> space is preferred.  However, I thought the general rule was to use
>> two spaces to make it easy for software (oh, the continued irony of it
>> all) to distinguish sentence-ending periods from other periods.

> Don't really see the irony: this is just plain difficult for a machine.
> (I also use two spaces, btw.)

It was a reference to the thread regarding apostrophe choices, where
the fact that the Unicode Consortium chose U+2019 as the apostrophe
character for similar reasons. was discussed  Just because something’s
difficult doesn’t mean we shouldn’t try to push it towards the
computer’s set of responsibilities.  Natural language processing is of
course an exceedingly difficult problem to solve, so I, as you,
continue to use two spaces.

>> Also, any typesetting software that doesn’t fold multiple spaces into
>> one isn’t a typesetting software.  Microsoft Word isn’t a typesetting
>> software.  TeX is a typesetting software, so using multiple spaces
>> shouldn’t affect the output at all.  (Perhaps Texinfo is different?)
>> Though, TeX, as far as I recall, favors adding space after a period
>> when justifying a paragraph.

> To be more precise, it does it by default, but it can be turned off (by
> \frenchspacing).  Also, in TeX, not only are the spaces after periods
> larger, but they also grow "faster" when justifying text (as you said).
> See "space factor" in The TeXbook, if you are curious about the
> details.  (Interestingly enough, this mechanism can be hackedto achieve
> some other goals, too.)

> OTOH, Bringhurst criticizes the above style very harshly.

Yes, Bringhurst is very particular in many questions relating to typesetting.

> OYAH, https://xkcd.com/1285/ . ;-)

:-)

Re: Documenting NEWS features for 25.1

[Shakthi Kannan]

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

Hi,

--- On Tue, Dec 29, 2015 at 10:29 PM, Eli Zaretskii <eliz@gnu.org> wrote:
| Thanks.  A few comments below.
\--

I have made the following changes, and re-attached the patch:

* Two spaces between sentences.
* Used @TeX{}.
* Use @dots{} for "...".
* "Unicode" is capitalized.
* Used @file{.pdf}

Regards,

SK

--
Shakthi Kannan
http://www.shakthimaan.com

[-- Attachment #2: 0001-Document-TeX-mode-custom-variable-and-prettify-symbo.patch --]
[-- Type: text/x-patch, Size: 3846 bytes --]

From f71133addf24182b7e88ebc374b635d30632df36 Mon Sep 17 00:00:00 2001
From: Shakthi Kannan <author@shakthimaan.com>
Date: Wed, 30 Dec 2015 11:07:57 +0530
Subject: [PATCH] Document TeX mode custom variable and prettify symbols

---
 doc/emacs/programs.texi | 18 ++++++++++--------
 doc/emacs/text.texi     |  8 +++++++-
 etc/NEWS                |  2 ++
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/doc/emacs/programs.texi b/doc/emacs/programs.texi
index 8423b70..83695b1 100644
--- a/doc/emacs/programs.texi
+++ b/doc/emacs/programs.texi
@@ -1530,14 +1530,16 @@ Misc for Programs
   Prettify Symbols mode is a buffer-local minor mode that replaces
 certain strings with more attractive versions for display purposes.
 For example, in Emacs Lisp mode, it replaces the string @samp{lambda}
-with the Greek lambda character @samp{λ}.  You may wish to use this in
-non-programming modes as well.  You can customize the mode by adding
-more entries to @code{prettify-symbols-alist}.  More elaborate
-customization is available via customizing
-@code{prettify-symbols-compose-predicate} if its default value
-@code{prettify-symbols-default-compose-p} is not appropriate.  There
-is also a global version, @code{global-prettify-symbols-mode}, which
-enables the mode in all buffers that support it.
+with the Greek lambda character @samp{λ}.  In a @TeX{} buffer, it will
+replace @samp{\alpha} @dots{} @samp{\omega} and other math macros with
+their Unicode characters.  You may wish to use this in non-programming
+modes as well.  You can customize the mode by adding more entries to
+@code{prettify-symbols-alist}.  More elaborate customization is
+available via customizing @code{prettify-symbols-compose-predicate} if
+its default value @code{prettify-symbols-default-compose-p} is not
+appropriate.  There is also a global version,
+@code{global-prettify-symbols-mode}, which enables the mode in all
+buffers that support it.
 
   The symbol at point can be shown in its original form.  This is
 controlled by the variable @code{prettify-symbols-unprettify-at-point}:
diff --git a/doc/emacs/text.texi b/doc/emacs/text.texi
index bab660e..d18c3c7 100644
--- a/doc/emacs/text.texi
+++ b/doc/emacs/text.texi
@@ -1717,6 +1717,7 @@ TeX Print
 @vindex latex-run-command
 @vindex tex-dvi-view-command
 @vindex tex-dvi-print-command
+@vindex tex-print-file-extension
   The buffer's @TeX{} variant determines what shell command @kbd{C-c
 C-b} actually runs.  In Plain @TeX{} mode, it is specified by the
 variable @code{tex-run-command}, which defaults to @code{"tex"}.  In
@@ -1725,7 +1726,12 @@ TeX Print
 to view the @file{.dvi} output is determined by the variable
 @code{tex-dvi-view-command}, regardless of the @TeX{} variant.  The
 shell command that @kbd{C-c C-p} runs to print the output is
-determined by the variable @code{tex-dvi-print-command}.
+determined by the variable @code{tex-dvi-print-command}.  The variable
+@code{tex-print-file-extension} can be set to the required file
+extension for viewing and printing @Tex{}-compiled files.  For
+example, you can set it to @file{.pdf}, and update
+@code{tex-dvi-view-command} and @code{tex-dvi-print-command}
+accordingly.
 
   Normally, Emacs automatically appends the output file name to the
 shell command strings described in the preceding paragraph.  For
diff --git a/etc/NEWS b/etc/NEWS
index 1aeab35..76d6df2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -879,9 +879,11 @@ name patterns (e.g. all "FOR_DOXYGEN_ONLY_*") to be excluded.
 
 ** TeX mode
 
++++
 *** New custom variable `tex-print-file-extension' to help users who
 use PDF instead of DVI.
 
++++
 *** TeX mode now supports Prettify Symbols mode.  When enabling
 `prettify-symbols-mode' in a tex-mode buffer, \alpha ... \omega, and
 many other math macros are displayed using unicode characters.
-- 
2.1.4

Re: Spaces after periods

[Random832]

Nikolai Weibull <now@disu.se> writes:
> On Tue, Dec 29, 2015 at 6:05 PM, John Wiegley <jwiegley@gmail.com> wrote:
>> I almost hate to say this, but I'm not sure this is the English
>> convention anymore. A quick Google shows many, many sites that
>> indicate that the modern convention is now one space, and none that
>> recommend two spaces. I've even changed to one space in my e-mails,
>> even, after being a long holdout for the two space rule.
>
> I haven’t seen a style guide that says anything other than that one
> space is preferred.  However, I thought the general rule was to use
> two spaces to make it easy for software (oh, the continued irony of it
> all) to distinguish sentence-ending periods from other periods.

In Python (where two spaces is also the standard), AIUI the justifi-
cation is typographical: The two-space rule was invented for monospace
fonts, and code (and most default Emacs fonts) is still in monospace
fonts.  To the extent that it's obsolete, the reason it is obsolete is
because proportional fonts are common now and it's not typographically
appropriate for proportional fonts.

Re: Spaces after periods

[Nikolai Weibull]

On Wed, Dec 30, 2015 at 8:46 AM, Random832 <random832@fastmail.com> wrote:
> Nikolai Weibull <now@disu.se> writes:
>> On Tue, Dec 29, 2015 at 6:05 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>> I almost hate to say this, but I'm not sure this is the English
>>> convention anymore. A quick Google shows many, many sites that
>>> indicate that the modern convention is now one space, and none that
>>> recommend two spaces. I've even changed to one space in my e-mails,
>>> even, after being a long holdout for the two space rule.
>>
>> I haven’t seen a style guide that says anything other than that one
>> space is preferred.  However, I thought the general rule was to use
>> two spaces to make it easy for software (oh, the continued irony of it
>> all) to distinguish sentence-ending periods from other periods.
>
> In Python (where two spaces is also the standard), AIUI the justifi-
> cation is typographical: The two-space rule was invented for monospace
> fonts, and code (and most default Emacs fonts) is still in monospace
> fonts.  To the extent that it's obsolete, the reason it is obsolete is
> because proportional fonts are common now and it's not typographically
> appropriate for proportional fonts.

I’m fully aware of the lineage and it extends further back into
history than typewriters – it’s not (solely) a result of monopace
fonts (or, rather, typewriters).  My point was to point out that my
understanding of its continued use was to make it easier for, for
example, Emacs to find sentence-ending periods for, for example,
kill-paragraph.

Re: Documenting NEWS features for 25.1

[Eli Zaretskii]

> Date: Wed, 30 Dec 2015 11:10:22 +0530
> From: Shakthi Kannan <shakthimaan@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> I have made the following changes, and re-attached the patch:
> 
> * Two spaces between sentences.
> * Used @TeX{}.
> * Use @dots{} for "...".
> * "Unicode" is capitalized.
> * Used @file{.pdf}

Thanks, pushed.

Please in the future include ChangeLog-style commit log message, and
also make sure to build the documentation you change (your patch had
one typo -- @Tex{} instead of @TeX{} -- which prevented the manual
from building).

Re: Documenting NEWS features for 25.1

[Shakthi Kannan]

Hi,

--- On Wed, Dec 30, 2015 at 11:19 PM, Eli Zaretskii <eliz@gnu.org> wrote:
| Thanks, pushed.
|
| Please in the future include ChangeLog-style commit log message
|  ...
| also make sure to build the documentation you change (your patch had
| one typo -- @Tex{} instead of @TeX{}
\--

Will remember in future.

Thanks again for patiently reviewing my patches.

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com