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 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"?
Tom Kramer <kra...@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.
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 <kra...@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.
> 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.
> 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.
> 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«
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.
> 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.
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.
> From: Eli Zaretskii <e...@gnu.org>
> To: help-gnu-em...@gnu.org
> Date: Tue, 25 Sep 2012 23:50:37 +0200
> Subject: Re: line adjustment at the end of a sentence
> Message: 8
>> 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.
> From: Tom Kramer
> Sent: Wednesday, September 26, 2012 7:01 AM
> To: T.F. Torrey
> Cc: help-gnu-em...@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).
On Thu, Sep 27, 2012 at 12:12 AM, Ludwig, Mark <ludwig.m...@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.
> 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.
> 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.
> 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.
On Thu, Sep 27 2012, Barry Margolin wrote:
> In article <mailman.9790.1348681903.855.help-gnu-em...@gnu.org>,
> "Drew Adams" <drew.ad...@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
> 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.
> 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.
> > 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.
>> 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.
> >> 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...
> "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. :-)
