line adjustment at the end of a sentence

line adjustment at the end of a sentence

[Tom Kramer]

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

Hello emacs help -

I have had the following simple problem with emacs for over two decades, 
so I figured it was time to ask if there is a solution. The problem is: 
when a sentence ends at the end of a line, if the paragraph containing 
the sentence is adjusted by hitting Esc-Q, the last word of the sentence 
is moved to the next line, so that extra white space appears. Here is an 
example. It is set in fixed width font as I am typing. If you do not get 
it in fixed-width font, reset it in fixed-width font.

I type the following and then I use Esc-Q to reset the paragraph.

9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. Watched
Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob Brown.

The paragraph is reset automatically as follows. The word Brown has been 
moved from the
end of the second line to the beginning of a third line.

9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. Watched
Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob
Brown.

This makes no sense. The word Brown fits easily within the right fill 
column (75 in Text Fill mode). The reset paragraph looks terrible. I get 
annoyed and move Brown back to the end of the second line. I have just 
wasted fifteen seconds or so. This happens about once each working day. 
A quarter minute for 200 days a year for 20 years is 1000 minutes I have 
wasted on this dumb problem.

Is there a way to get emacs to stop doing that? Thanks.

Tom Kramer
kramer@cme.nist.gov





[-- Attachment #2: Type: text/html, Size: 2269 bytes --]

Re: line adjustment at the end of a sentence

[Eli Zaretskii]

> Date: Tue, 25 Sep 2012 08:54:50 -0400
> From: Tom Kramer <kramer@cme.nist.gov>
> 
> I have had the following simple problem with emacs for over two decades, 
> so I figured it was time to ask if there is a solution.

After 20 years, it's high time to "M-x report-emacs-bug RET", that's
how you bring problems to attention of the Emacs maintainers.  But see
below.

> I type the following and then I use Esc-Q to reset the paragraph.
> 
> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. Watched
> Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob Brown.
> 
> The paragraph is reset automatically as follows. The word Brown has been 
> moved from the
> end of the second line to the beginning of a third line.
> 
> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. Watched
> Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob
> Brown.
> 
> This makes no sense. The word Brown fits easily within the right fill 
> column (75 in Text Fill mode). The reset paragraph looks terrible. I get 
> annoyed and move Brown back to the end of the second line. I have just 
> wasted fifteen seconds or so. This happens about once each working day. 
> A quarter minute for 200 days a year for 20 years is 1000 minutes I have 
> wasted on this dumb problem.

I cannot reproduce this.  I get this:

9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. Watched
Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob Brown.

as expected.

What Emacs version did you use?  Can you show a minimal recipe to reproduce
the problem starting with "emacs -Q"?

Re: line adjustment at the end of a sentence

[Óscar Fuentes]

Tom Kramer <kramer@cme.nist.gov> writes:

[snip]

> This makes no sense. The word Brown fits easily within the right fill
> column (75 in Text Fill mode).

fill-column defaults to 70. Have you changed its value? As Eli says, can
you provide a recipe starting with emacs -Q ?

[snip]

Re: line adjustment at the end of a sentence

[Pascal J. Bourguignon]

Tom Kramer <kramer@cme.nist.gov> writes:

> Hello emacs help -
>
> I have had the following simple problem with emacs for over two
> decades, so I figured it was time to ask if there is a solution. The
> problem is: when a sentence ends at the end of a line, if the
> paragraph containing the sentence is adjusted by hitting Esc-Q, the
> last word of the sentence is moved to the next line, so that extra
> white space appears. Here is an example. It is set in fixed width font
> as I am typing. If you do not get it in fixed-width font, reset it in
> fixed-width font.
>
> I type the following and then I use Esc-Q to reset the paragraph.
>
> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. Watched
> Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob Brown.
>
> The paragraph is reset automatically as follows. The word Brown has been moved from the
> end of the second line to the beginning of a third line.
>
> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. Watched
> Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob
> Brown.
>
> This makes no sense. The word Brown fits easily within the right fill
> column (75 in Text Fill mode). The reset paragraph looks terrible. I
> get annoyed and move Brown back to the end of the second line. I have
> just wasted fifteen seconds or so. This happens about once each
> working day. A quarter minute for 200 days a year for 20 years is 1000
> minutes I have wasted on this dumb problem.
>
> Is there a way to get emacs to stop doing that? Thanks.

I don't get the same result as you either, because indeed, my
fill-column setting is not the same.  But one thing you're doing wrong,
is to put a single space after end-of-sentence dots.  Emacs considers a
sentence ends with dot space space, not on dot space.  If you add spaces
after the end of senctences, then justifying the text will give better
results.

With a single space after RTFI. :

9/19/12 Worked 9.5 hours.  Spent 1 hour misc.  Spent 0.5 hour
RTFI. Watched Mitutoyo vid of IMTS QIF demo.  Exchanged email messages
with Bob Brown.


With two spaces after RTFI.  :

9/19/12 Worked 9.5 hours.  Spent 1 hour misc.  Spent 0.5 hour RTFI.
Watched Mitutoyo vid of IMTS QIF demo.  Exchanged email messages with
Bob Brown.


You can also skip over sentences with M-e and M-a, and compare what
happens with a single space and with two spaces after end-of-sentence
dots.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

line adjustment at the end of a sentence

[Tom Kramer]

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

Hello emacs help -

I understand from Óscar Fuentes that Eli Zaretskii posted a reply to my 
earlier email on this subject suggesting that I provide a recipe for 
recreating the problem. Here is a recipe and some discussion. If anyone 
writes a reply to this email, I hope s/he will send me a copy. I am not 
on the regular mailing list for emacs help. Thanks.

1. Start emacs from a command window by typing emacs -Q test

2. Type the following, which will wrap around as you type.

9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. 
Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob 
Brown.

3. Type Esc-q The paragraph is set on three lines and looks like the 
following:

9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour
RTFI. Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages
with Bob Brown.

Note that the second line is much longer (69 characters) than the first 
(59 characters), and there is plenty of space for RTFI to fit on the 
first line.

That demonstrates the problem. To check that the problem is caused by 
the end of the line, copy the word
messages from the end of the second line to the end of the first line 
and type Esc-q again. Note that nothing
changes even though the first line is now much longer than it would have 
been if it ended with RTFI.

I am using emacs on Linux, but I have had exactly the same problem with 
other OSs.

Tom Kramer


[-- Attachment #2: Type: text/html, Size: 2337 bytes --]

Re: line adjustment at the end of a sentence

[Pascal J. Bourguignon]

Tom Kramer <kramer@cme.nist.gov> writes:

> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour
> RTFI. Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages
> with Bob Brown.
>
> Note that the second line is much longer (69 characters) than the
> first (59 characters), and there is plenty of space for RTFI to fit on
> the first line.

I explained you why it is so: because you're not ending a sentence here!
Read my other answer.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: line adjustment at the end of a sentence

[Eli Zaretskii]

> Date: Tue, 25 Sep 2012 17:25:47 -0400
> From: Tom Kramer <kramer@cme.nist.gov>
> 
> 1. Start emacs from a command window by typing emacs -Q test
> 
> 2. Type the following, which will wrap around as you type.
> 
> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. 
> Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob 
> Brown.
> 
> 3. Type Esc-q The paragraph is set on three lines and looks like the 
> following:
> 
> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour
> RTFI. Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages
> with Bob Brown.
> 
> Note that the second line is much longer (69 characters) than the first 
> (59 characters), and there is plenty of space for RTFI to fit on the 
> first line.
> 
> That demonstrates the problem.

Not reproducible here.  I get this instead:

9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI.
Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages
with Bob Brown.

which is quite reasonable.

Something else is at work here, or there's something in your recipe
that you didn't tell us.

Re: line adjustment at the end of a sentence

[Eli Zaretskii]

> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> Date: Tue, 25 Sep 2012 23:18:04 +0200
> 
> one thing you're doing wrong, is to put a single space after
> end-of-sentence dots.  Emacs considers a sentence ends with dot
> space space, not on dot space.  If you add spaces after the end of
> senctences, then justifying the text will give better results.

That's in accurate at the very least.  See also
sentence-end-double-space.

> With a single space after RTFI. :
> 
> 9/19/12 Worked 9.5 hours.  Spent 1 hour misc.  Spent 0.5 hour
> RTFI. Watched Mitutoyo vid of IMTS QIF demo.  Exchanged email messages
> with Bob Brown.
> 
> 
> With two spaces after RTFI.  :
> 
> 9/19/12 Worked 9.5 hours.  Spent 1 hour misc.  Spent 0.5 hour RTFI.
> Watched Mitutoyo vid of IMTS QIF demo.  Exchanged email messages with
> Bob Brown.

I get reasonable results with both variants.  With a single space:

9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI.
Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages
with Bob Brown.

With 2 spaces:

9/19/12 Worked 9.5 hours. Spent 1 hour misc.  Spent 0.5 hour
RTFI.  Watched Mitutoyo vid of IMTS QIF demo.  Exchanged email
messages with Bob Brown.

Re: line adjustment at the end of a sentence

[Peter Dyballa]

Am 25.09.2012 um 23:25 schrieb Tom Kramer:

> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour
> RTFI. Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages
> with Bob Brown.

I can reproduce it, also with typing RET at the end of the paragraph, in GNU Emacs 24.2.50.
I can reproduce it also in GNU EMacs 23.4 and 24.1. Here a RET just adds a new line.

--
Greetings

  Pete

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
	- Douglas Adams, »Mostly Harmless«

Re: line adjustment at the end of a sentence

[T.F. Torrey]

Hello Tom,

This same behavior caused me confusion a while back, and it took me a
bit to track it down and get my head around it.  The behavior comes from
Emacs's idea about what ends a sentence.

By default, Emacs expects two spaces after a punctuation mark ending a
sentence.  This comes from the variable sentence-end-double-space, which
has a default value of t, meaning two spaces will appear after the end
of a sentence.  If you set it to nil, you will probably get behavior
closer to what you expect.

In more detail, if I understand it correctly, by default, Emacs expects
punctuation ending sentences to be followed by two spaces or a carriage
return.  When this is the case, using a single space after an
abbreviation such as "Dr. Watson" is significant, because it isn't the
end of a sentence.  It would be wrong to fill the paragraph such that
two spaces appear between "Dr." and "Watson", so the single space must
be preserved.  The line can not be broken between "Dr." and "Watson",
because that would lose the information that it was originally a single
space, and adding text and re-filling the paragraph might put both on
the same line erroneously as two sentences as "Dr.  Watson".  So, in
your example, and in my own experience, Emacs treats the space as
unbreakable, even if the line extends beyond what looks reasonable.  It
may be a bug that it does not break the line before the "Dr." (in this
example), but it could just as easily be a deliberate design.

If you change sentence-end-double-space to nil, then the single space
between "Dr." and "Watson" is no longer significant, and Emacs will
break the line between them just fine, because reconnecting them with a
single space between would never be wrong.

As others have noted, using two spaces after periods will also work
well, and has other benefits.  Once you understand what's going on,
though, it's kind of cool.

Best regards,
Terry
-- 
T.F. Torrey

> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Date: Tue, 25 Sep 2012 23:50:37 +0200
> Subject: Re: line adjustment at the end of a sentence
> Message: 8
>
>> Date: Tue, 25 Sep 2012 17:25:47 -0400
>> From: Tom Kramer <kramer@cme.nist.gov>
>> 
>> 1. Start emacs from a command window by typing emacs -Q test
>> 
>> 2. Type the following, which will wrap around as you type.
>> 
>> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI. 
>> Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages with Bob 
>> Brown.
>> 
>> 3. Type Esc-q The paragraph is set on three lines and looks like the 
>> following:
>> 
>> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour
>> RTFI. Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages
>> with Bob Brown.
>> 
>> Note that the second line is much longer (69 characters) than the first 
>> (59 characters), and there is plenty of space for RTFI to fit on the 
>> first line.
>> 
>> That demonstrates the problem.
>
> Not reproducible here.  I get this instead:
>
> 9/19/12 Worked 9.5 hours. Spent 1 hour misc. Spent 0.5 hour RTFI.
> Watched Mitutoyo vid of IMTS QIF demo. Exchanged email messages
> with Bob Brown.
>
> which is quite reasonable.
>
> Something else is at work here, or there's something in your recipe
> that you didn't tell us.

Re: line adjustment at the end of a sentence

[Tom Kramer]

Hello Terry -

Thank you very much. I have put (setq sentence-end-double-space nil) 
into my .emacs file and restarted emacs. The problem is solved as best I 
can tell. The sample paragraph I submitted now gets set exactly the way 
I prefer. The double spaces between sentences have also always annoyed 
me, so setting sentence-end-double-space to nil gets two birds with one 
stone.

Tom Kramer

On 09/26/2012 06:56 AM, T.F. Torrey wrote:
> Hello Tom,
>
> This same behavior caused me confusion a while back, and it took me a
> bit to track it down and get my head around it.  The behavior comes from
> Emacs's idea about what ends a sentence.
>
> By default, Emacs expects two spaces after a punctuation mark ending a
> sentence.  This comes from the variable sentence-end-double-space, which
> has a default value of t, meaning two spaces will appear after the end
> of a sentence.  If you set it to nil, you will probably get behavior
> closer to what you expect.
>
> In more detail, if I understand it correctly, by default, Emacs expects
> punctuation ending sentences to be followed by two spaces or a carriage
> return.  When this is the case, using a single space after an
> abbreviation such as "Dr. Watson" is significant, because it isn't the
> end of a sentence.  It would be wrong to fill the paragraph such that
> two spaces appear between "Dr." and "Watson", so the single space must
> be preserved.  The line can not be broken between "Dr." and "Watson",
> because that would lose the information that it was originally a single
> space, and adding text and re-filling the paragraph might put both on
> the same line erroneously as two sentences as "Dr.  Watson".  So, in
> your example, and in my own experience, Emacs treats the space as
> unbreakable, even if the line extends beyond what looks reasonable.  It
> may be a bug that it does not break the line before the "Dr." (in this
> example), but it could just as easily be a deliberate design.
>
> If you change sentence-end-double-space to nil, then the single space
> between "Dr." and "Watson" is no longer significant, and Emacs will
> break the line between them just fine, because reconnecting them with a
> single space between would never be wrong.
>
> As others have noted, using two spaces after periods will also work
> well, and has other benefits.  Once you understand what's going on,
> though, it's kind of cool.
>
> Best regards,
> Terry

RE: line adjustment at the end of a sentence

[Ludwig, Mark]

> From: Tom Kramer
> Sent: Wednesday, September 26, 2012 7:01 AM
> To: T.F. Torrey
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: line adjustment at the end of a sentence
> 
> Hello Terry -
> 
> Thank you very much. I have put (setq sentence-end-double-space nil)
> into my .emacs file and restarted emacs. The problem is solved as best I
> can tell. The sample paragraph I submitted now gets set exactly the way
> I prefer. The double spaces between sentences have also always annoyed
> me, so setting sentence-end-double-space to nil gets two birds with one
> stone.
> 
> Tom Kramer

The number of spaces between English sentences has been gradually switching from two to one.  (The style guide I used in college certainly required two spaces between sentences.  I wonder if newer style guides have changed to one space between sentences.)  It's good that this is configurable in Emacs, because I'm annoyed by the use of one space, as I feel it adds further ambiguity to the written language where there is already more than enough ambiguity to make understanding challenging.  Why are you annoyed by two spaces between sentences?  I'd think one's eye would just skip right over the extra space.

With 30+ years of EMACS/Emacs experience, and a love for two spaces between sentences, I've always been impressed by the way it handles "Dr. Watson" and similar uses of a single space that is not the end of a sentence.  I suppose my love for this is because of the ease with which one can act on sentences in Emacs.  I frequently use M-k (kill-sentence) in my comments in code (usually when I want to reorder the sentences).

Cheers,
Mark

Re: line adjustment at the end of a sentence

[Yuri Khan]

On Thu, Sep 27, 2012 at 12:12 AM, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> The number of spaces between English sentences has been gradually switching from two to one.

Differentiating between end-of-sentence full stop and in-sentence
period by the number of spaces is an artifact of pre-Unicode
typography. When the only available space was the ASCII 0x20, it made
sense. Now it doesn’t, as we have the U+0020 SPACE, the U+00A0
NON-BREAKING SPACE, and the U+2009/U+200A THIN SPACE and HAIR SPACE,
respectively, as well as other fixed-width spaces.

> Why are you annoyed by two spaces between sentences?  I'd think one's eye would just skip right over the extra space.

One place where two spaces are double plus annoying is when people try
to apply this rule to the Web. As HTML by definition collapses all
runs of consecutive whitespace, they have to make one of the spaces a
non-breaking space. So it becomes either NBSP+SPACE, or SPACE+NBSP.
Now suppose the line is wrapped at this sequence. In the former case,
the NBSP will be left last on the line; if the paragraph is justified,
it will make a ragged right. In the latter case it is even worse — the
NBSP will wrap onto the second line, making a ragged left.

Today, the logical rule is to put a space where the line may be
wrapped and where justification may modify space width; a non-breaking
space where line may not be broken and width must be preserved; and
one of the fixed width spaces where line break is OK but width must be
fixed. I see no reason to selectively apply it to the Web only.

RE: line adjustment at the end of a sentence

[Drew Adams]

> The number of spaces between English sentences has been 
> gradually switching from two to one.

Dunno about that.  Mostly I think people just use plain text less and formatted
text more nowadays.

FWIW, English (at least the American variety) has typically used two spaces for
typewritten text, but some other languages (e.g., French) have used only one.
Other punctuation (e.g. `:', `;') also offers differences wrt spacing among
different languages.

> I've always been impressed by the way it handles "Dr. Watson" and
> similar uses of a single space that is not the end of a sentence.

Wrt filling, with non-nil `sentence-end-double-space', Emacs tends to treat a
single space after period somewhat like a no-break space.

There are also other sentence and spacing related user options in Emacs:
`colon-double-space', `sentence-end', `sentence-end-base',
`sentence-end-without-space', `sentence-end-without-period'.

> the ease with which one can act on sentences in Emacs.

Yup.

Re: line adjustment at the end of a sentence

[Eli Zaretskii]

> Date: Thu, 27 Sep 2012 00:44:54 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Tom Kramer <kramer@cme.nist.gov>,
> 	"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> Differentiating between end-of-sentence full stop and in-sentence
> period by the number of spaces is an artifact of pre-Unicode
> typography. When the only available space was the ASCII 0x20, it made
> sense. Now it doesn’t, as we have the U+0020 SPACE, the U+00A0
> NON-BREAKING SPACE, and the U+2009/U+200A THIN SPACE and HAIR SPACE,
> respectively, as well as other fixed-width spaces.

But in the real world, there's still a lot of text with 2 spaces
between sentences, and Emacs needs to DTRT with that.  An editor
cannot throw in the towel when it bumps into text that uses two
spaces.

Re: line adjustment at the end of a sentence

[Barry Margolin]

In article <mailman.9790.1348681903.855.help-gnu-emacs@gnu.org>,
 "Drew Adams" <drew.adams@oracle.com> wrote:

> > The number of spaces between English sentences has been 
> > gradually switching from two to one.
> 
> Dunno about that.  Mostly I think people just use plain text less and 
> formatted
> text more nowadays.

Right. The old convention was for typewriters with fixed-width fonts, 
and Emacs was designed for the same type of text processing.

I don't think it was ever applied to typeset text, and most people now 
use word processors that generate comparable output.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: line adjustment at the end of a sentence

[Stefan Monnier]

> Differentiating between end-of-sentence full stop and in-sentence
> period by the number of spaces is an artifact of pre-Unicode
> typography.  When the only available space was the ASCII 0x20, it made
> sense.  Now it doesn’t, as we have the U+0020 SPACE, the U+00A0
> NON-BREAKING SPACE, and the U+2009/U+200A THIN SPACE and HAIR SPACE,
> respectively, as well as other fixed-width spaces.

While Unicode provides the necessary different elements to eliminate the
need to use conventions such as double-spaces to end sentences, I don't
think Unicode has penetrated enough in everyday use yet to make such
conventions completely useless.

E.g. for many people it's much easier to type SPC sometimes and SPC SPC
other times than to try and figure out how to type NBSP.
Also there's no good convention for how to distinguish on screen a SPC
from a NBSP.  Emacs highlights the NBSP specially (because accidental
use of NBSP in program code leads to trouble) but that's not ideal when
reading text that uses NBSP between Dr. and Watson or between « and the
quoted text.

So the Unicode characters offer a way to represent/store the needed
information, but I don't think we have yet a sufficiently good way for
the user to enter this information, nor do we have a sufficiently good
way for Emacs to display this information.

> One place where two spaces are double plus annoying is when people try
> to apply this rule to the Web.

While the "double space convention" might be at the origin of those
problems, I don't think it's unfair to say that it's a case where the
"double space convention" is annoying, because this convention applies
to plain text only.
We can apply the convention to HTML source code (it will only help us
navigate the text but won't affect the display), but we can't directly
apply it to its rendering because we don't type its rendering.


        Stefan

Re: line adjustment at the end of a sentence

[Eric Abrahamsen]

On Thu, Sep 27 2012, Barry Margolin wrote:

> In article <mailman.9790.1348681903.855.help-gnu-emacs@gnu.org>,
>  "Drew Adams" <drew.adams@oracle.com> wrote:
>
>> > The number of spaces between English sentences has been 
>> > gradually switching from two to one.
>> 
>> Dunno about that.  Mostly I think people just use plain text less and 
>> formatted
>> text more nowadays.
>
> Right. The old convention was for typewriters with fixed-width fonts, 
> and Emacs was designed for the same type of text processing.
>
> I don't think it was ever applied to typeset text, and most people now 
> use word processors that generate comparable output.

For everyone's entertainment, the following is from Bringhurst's
excellent _The Elements of Typographic Style_:

"2.1.4 Use a single word space between sentences.

In the nineteenth century, which was a dark and inflationary age in
typography and type design, many compositors were encouraged to stuff
extra space between sentences. Generations of twentieth-century typists
were then taught to do the same, by hitting the spacebar twice after
every period. Your typing as well as your typesetting will benefit from
unlearning this quaint Victorian habit."

Obviously, emacs still needs to be able to handle it!

E

-- 
GNU Emacs 24.2.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.4)
 of 2012-09-16 on pellet

RE: line adjustment at the end of a sentence

[Drew Adams]

> Also there's no good convention for how to distinguish on screen a SPC
> from a NBSP.  Emacs highlights the NBSP specially (because accidental
> use of NBSP in program code leads to trouble) but that's not 
> ideal when reading text that uses NBSP between Dr. and Watson or
> between < and the quoted text.

I agree generally with everything you said.  Wrt showing no-break space and
non-breaking hyphen so that you can distinguish them from SPC and ASCII hyphen,
`show-wspace.el' can help.

There are commands that toggle the distinguishing display of each on/off, and
you can customize the faces used for that.  Quick toggling is helpful, because
most of the time you don't care about the difference, but you can easily check.

http://www.emacswiki.org/emacs-en/show-wspace.el

http://emacswiki.org/emacs/ShowWhiteSpace#ShowWspace

Re: line adjustment at the end of a sentence

[Stefan Monnier]

> I agree generally with everything you said.  Wrt showing no-break
> space and non-breaking hyphen so that you can distinguish them from
> SPC and ASCII hyphen, `show-wspace.el' can help.

I don't think any of those comes anywhere close to the convenient of
"SPC vs SPC-SPC" in terms of showing the difference without getting in
the way.

> There are commands that toggle the distinguishing display of each on/off

A really good solution would not require turning it on/off.


        Stefan

RE: line adjustment at the end of a sentence

[Drew Adams]

> > I agree generally with everything you said.  Wrt showing no-break
> > space and non-breaking hyphen so that you can distinguish them from
> > SPC and ASCII hyphen, `show-wspace.el' can help.
> 
> I don't think any of those comes anywhere close to the convenient of
> "SPC vs SPC-SPC" in terms of showing the difference without getting in
> the way.

That was not the point.  I was responding to your point that:

> how to distinguish on screen a SPC from a NBSP.  Emacs highlights
> the NBSP specially (because accidental use of NBSP in program code
> leads to trouble) but that's not ideal when reading text that uses
> NBSP between Dr. and Watson or between < and the quoted text.

The `nobreak-char-display' highlighting provided by Emacs is all or nothing (one
variable for both chars together, and not a user option), face not separately
customizable from escape glyph highlighting, and no toggles.

Those are the weaknesses that `show-wspace.el' overcomes for these two chars and
the reason it can help distinguishing them without that always getting in the
way.

And not just those two chars.  You can use it to distinguish any chars you like.

> > There are commands that toggle the distinguishing display 
> > of each on/off
> 
> A really good solution would not require turning it on/off.

It's not about requiring.  Sometimes (and perhaps in some places) you want to
distinguish such chars, sometimes you do not.  You want to be able to pick those
times - i.e., on demand.

Other editors and word processors do this kind of thing all the time, not only
wrt hard-to-detect chars but wrt other things that you sometimes want to see and
sometimes do not: XML element boundaries and attributes, editor text
symbols/artifacts (e.g. pilcro), conditionalized text, and so on.

Just as in Emacs you can choose whether to see control chars using ^ syntax or
\ooo syntax, so you can choose whether and when to see other chars in particular
ways.

No DWIM will ever guess just when you want to see what.  You can add heuristics
to try to fit common use cases, but that's all.

See what XML and WYSIWYG editors do in this regard: they offer different "views"
that correspond to common use cases, showing different sets of such things, and
they offer individual toggle commands to handle individual such things.  See
Framemaker, Arbortext Epic, Oxygen, and other XML editors, for example.

Re: line adjustment at the end of a sentence

[Stefan Monnier]

>> A really good solution would not require turning it on/off.
> It's not about requiring.  Sometimes (and perhaps in some places) you
> want to distinguish such chars, sometimes you do not.  You want to be
> able to pick those times - i.e., on demand.

"SPC vs SPC SPC" lets you eat your cake and have it too, because while
it shows the difference, your brain will happily disregard it, so noone
ever felt the need to provide a command to switch between "show the
diff" and "hide the diff".

So, yes, it's about "requiring".

> Other editors and word processors do this kind of thing all the time,
> not only wrt hard-to-detect chars but wrt other things that you
> sometimes want to see and sometimes do not: XML element boundaries and
> attributes, editor text symbols/artifacts (e.g. pilcro),
> conditionalized text, and so on.

Yes, in the general case, there's probably no way to avoid the need to
distinguish between "show markup" and "hide markup".  But some markup
(such as the SPC vs SPC SPC convention) is sufficiently lightweight that
you don't need to have those two states.


        Stefan

RE: line adjustment at the end of a sentence

[Drew Adams]

> >> A really good solution would not require turning it on/off.
> >> It's not about requiring.  Sometimes (and perhaps in some 
> >> places) you want to distinguish such chars, sometimes you do not.
> >> You want to be able to pick those times - i.e., on demand.
> 
> "SPC vs SPC SPC" lets you eat your cake and have it too, because
> while it shows the difference, your brain will happily disregard it,
> so noone ever felt the need to provide a command to switch between
> "show the diff" and "hide the diff".

I have no problem with "SPC vs SPC SPC".  Never have had.

Apparently you are talking about something else than I.  My point was in reply
to your post regarding distinguishing no-break space from SPC.

*IF* you have SPC and no-break space chars in the same buffer, *THEN* what I
mentioned provides a good way to distinguish them when you want to and not
distinguish them when you do not want to.  A much better way than the one you
mentioned: what vanilla Emacs provides.

That is a different discussion from whether one should try to use no-break space
vs SPC as some kind of substitute for "SPC vs SPC SPC".  I did not and would not
propose that.

> So, yes, it's about "requiring".

You will never come up with a DWIM that guesses exactly just when and where Ms.
X or Mr. Y might want to distinguish SPC from no-break space visually.

So no, it is not about "requiring" users to toggle.  They will _want_ to be able
to turn showing such differences on/off easily.  Experience with other editors
and word processors that deal with such distinctions should make that clear.

> > Other editors and word processors do this kind of thing all 
> > the time, not only wrt hard-to-detect chars but wrt other things that you
> > sometimes want to see and sometimes do not: XML element boundaries and
> > attributes, editor text symbols/artifacts (e.g. pilcro),
> > conditionalized text, and so on.
> 
> Yes, in the general case, there's probably no way to avoid the need to
> distinguish between "show markup" and "hide markup".

Good.  But don't look at it so negatively.  It is a _good_ thing for users to be
able to easily change the way they see things.

Providing them _only_ some programmer's guess as to what they need (DWIM) would
be restrictive.  Give them some common views, certainly, but let them also pick
and choose.

> But some markup (such as the SPC vs SPC SPC convention) is sufficiently 
> lightweight that you don't need to have those two states.

Irrelevant - see above.  IF you have both SPC and no-break present THEN...

Re: line adjustment at the end of a sentence

[Stefan Monnier]

> Apparently you are talking about something else than I.

Of course: I'm talking about distinguishing sentence separators from
other spaces (the subject of this thread, AFAICT).


        Stefan

Re: line adjustment at the end of a sentence

[Sivaram Neelakantan]

On Thu, Sep 27 2012,Eric Abrahamsen wrote:


[snipped 21 lines]

> "2.1.4 Use a single word space between sentences.
>
> In the nineteenth century, which was a dark and inflationary age in
> typography and type design, many compositors were encouraged to
> stuff extra space between sentences. Generations of
> twentieth-century typists were then taught to do the same, by
> hitting the spacebar twice after every period. Your typing as well
> as your typesetting will benefit from unlearning this quaint
> Victorian habit."
>

I spend 10 years learning to double space because Emacs says so and
M-q plays nice to me and you dig this out?

Just when I know something, someone changes the rules!  Again. :-)

 sivaram
 -- 

Re: line adjustment at the end of a sentence

[Stefan Monnier]

> Just when I know something, someone changes the rules!  Again. :-)

The single-vs-double space debate is still raging.  You can still choose
which side you're on without risking being left alone.


        Stefan

Re: line adjustment at the end of a sentence

[David Combs]

In article <jwvpq54pxbo.fsf-monnier+gnu.emacs.help@gnu.org>,
Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>> Just when I know something, someone changes the rules!  Again. :-)
>
>The single-vs-double space debate is still raging.  You can still choose
>which side you're on without risking being left alone.
>
>
>        Stefan

Next subject:

Is it:

   a, b and c
or
  a, b, and c  ?

:-)

David

Re: line adjustment at the end of a sentence

[Joe Fineman]

dkcombs@panix.com (David Combs) writes:

> Next subject:
>
> Is it:
>
>    a, b and c

Most people's natural punctuation; observed religiously in
journalism.

> or
>   a, b, and c  ?

A shibboleth.  Advised by all the tonier stylebooks, and required by
the tonier publishers, on both sides of the Atlantic.  As a
copyeditor, I have inserted many thousands of such commas.

The serial comma (Harvard comma, Oxford comma) has been controversial
for at least a century.  The name "Harvard comma" is usual among
journalists & probably harks back to the time when "Harvard" in such
circles connoted "rich intellectual snob".
-- 
---  Joe Fineman    joe_f@verizon.net

||:  Quotation marks & car horns are warning devices that are  :||
||:  used by the vulgar to express their feelings.             :||

Re: line adjustment at the end of a sentence

[PJ Weisberg]

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

On Sunday, October 14, 2012, Joe Fineman <joe_f@verizon.net> wrote:
> dkcombs@panix.com (David Combs) writes:
>
>> Next subject:
>>
>> Is it:
>>
>>    a, b and c
>
> Most people's natural punctuation; observed religiously in
> journalism.

They taught this to me in elementary school, and it always seemed like an
unusual special case to me.  For the last item in the list you leave off
the comma, but when you read it aloud you still pause where the comma would
be.

>> or
>>   a, b, and c  ?
>
> A shibboleth.  Advised by all the tonier stylebooks, and required by
> the tonier publishers, on both sides of the Atlantic.  As a
> copyeditor, I have inserted many thousands of such commas.
>
> The serial comma (Harvard comma, Oxford comma) has been controversial
> for at least a century.  The name "Harvard comma" is usual among
> journalists & probably harks back to the time when "Harvard" in such
> circles connoted "rich intellectual snob".

http://greaterthanlapsed.tumblr.com/post/10340315471/aundressa-weexist-weresist-ejob

-- 
-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

[-- Attachment #2: Type: text/html, Size: 1570 bytes --]

Re: line adjustment at the end of a sentence

[Stefan Monnier]

> Is it:
>    a, b and c
> or
>   a, b, and c  ?

Huh?  Obviously, neither: (and a b c)


        Stefan

Re: line adjustment at the end of a sentence

[David Combs]

In article <mailman.10975.1350238417.855.help-gnu-emacs@gnu.org>,
PJ Weisberg  <pjweisberg@gmail.com> wrote:
>-=-=-=-=-=-
>
>On Sunday, October 14, 2012, Joe Fineman <joe_f@verizon.net> wrote:
>> dkcombs@panix.com (David Combs) writes:
>>
>>> Next subject:
>>>
>>> Is it:
>>>
>>>    a, b and c
>>

I myself always use a, b, and c.

I once read that the original reason for leaving out the
final comma was with NEWSPAPERS, with their narrow columns,
and the difficulty of fitting text within them.

So typesetters started removing the final comma so
as to have more room to make things fit.

I think that if you look around you'll find that
there's a hierarchy of this usage:

--- leave out serial comma:

Newspapers

Magazines

Novels (from "average quality" publishers)

Novels, etc, from "high quality" publishers, eg Knopf.

--- include serial comma.






As to formal papers, there seems to be no rule; it's whatever
the individual author was taught in school.


David

Re: line adjustment at the end of a sentence

[J. David Boyd]

dkcombs@panix.com (David Combs) writes:

> In article <mailman.10975.1350238417.855.help-gnu-emacs@gnu.org>,
> PJ Weisberg  <pjweisberg@gmail.com> wrote:
>>-=-=-=-=-=-
>>
>>On Sunday, October 14, 2012, Joe Fineman <joe_f@verizon.net> wrote:
>>> dkcombs@panix.com (David Combs) writes:
>>>
>>>> Next subject:
>>>>
>>>> Is it:
>>>>
>>>>    a, b and c
>>>
>
> I myself always use a, b, and c.
>


I always use a, b, and c as well....