unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#47857: fill-paragraph vs. FULLWIDTH DIGITs: bug exposed
@ 2021-04-18  1:06 積丹尼 Dan Jacobson
  2021-04-18  6:52 ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-04-18  1:06 UTC (permalink / raw)
  To: 47857

Disaster! M-q runs the command fill-paragraph

And turns:

Today's lucky number(s)!:
9
10
11

Into:

Today's lucky number(s)!:91011

OK, if it is so smart, then why doesn't it also turn:

Today's lucky number(s)!: 9 10 11

into:

Today's lucky number(s)!:91011

Well, surprise, it was actually very happy with 9 10 11 all along.

OK, let's add some space:
Today's lucky number(s)!: 9         10 11
becomes:
Today's lucky number(s)!: 9 10 11
perfect.

Anyway if it were stable in its output, then one would always get the same
results. Bug exposed!

(Yes, even LC_ALL isn't going to help. And yes, all this works fine if
all this was good old ASCII. emacs-version "27.1".)





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#47857: fill-paragraph vs. FULLWIDTH DIGITs: bug exposed
  2021-04-18  1:06 bug#47857: fill-paragraph vs. FULLWIDTH DIGITs: bug exposed 積丹尼 Dan Jacobson
@ 2021-04-18  6:52 ` Eli Zaretskii
  2021-04-18 16:27   ` Stefan Kangas
  2021-04-19 23:27   ` 積丹尼 Dan Jacobson
  0 siblings, 2 replies; 5+ messages in thread
From: Eli Zaretskii @ 2021-04-18  6:52 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 47857

> From: 積丹尼 Dan Jacobson
>  <jidanni@jidanni.org>
> Date: Sun, 18 Apr 2021 09:06:55 +0800
> 
> Disaster! M-q runs the command fill-paragraph
> 
> And turns:
> 
> Today's lucky number(s)!:
> 9
> 10
> 11
> 
> Into:
> 
> Today's lucky number(s)!:91011
> 
> OK, if it is so smart, then why doesn't it also turn:
> 
> Today's lucky number(s)!: 9 10 11
> 
> into:
> 
> Today's lucky number(s)!:91011
> 
> Well, surprise, it was actually very happy with 9 10 11 all along.
> 
> OK, let's add some space:
> Today's lucky number(s)!: 9         10 11
> becomes:
> Today's lucky number(s)!: 9 10 11
> perfect.
> 
> Anyway if it were stable in its output, then one would always get the same
> results. Bug exposed!

I don't see any bug here.  This is the documented behavior: filling
deletes any excess whitespace, so 2 or more consecutive SPC characters
are squeezed to a single SPC.  All the rest is a typical jidanni-style
hysteria.






^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#47857: fill-paragraph vs. FULLWIDTH DIGITs: bug exposed
  2021-04-18  6:52 ` Eli Zaretskii
@ 2021-04-18 16:27   ` Stefan Kangas
  2021-04-19 23:27   ` 積丹尼 Dan Jacobson
  1 sibling, 0 replies; 5+ messages in thread
From: Stefan Kangas @ 2021-04-18 16:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 47857, 積丹尼 Dan Jacobson

tags 47857 notabug
close 47857
thanks

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see any bug here.  This is the documented behavior: filling
> deletes any excess whitespace, so 2 or more consecutive SPC characters
> are squeezed to a single SPC.  All the rest is a typical jidanni-style
> hysteria.

I'm therefore closing this bug.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#47857: fill-paragraph vs. FULLWIDTH DIGITs: bug exposed
  2021-04-18  6:52 ` Eli Zaretskii
  2021-04-18 16:27   ` Stefan Kangas
@ 2021-04-19 23:27   ` 積丹尼 Dan Jacobson
  2021-04-20 11:29     ` Eli Zaretskii
  1 sibling, 1 reply; 5+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-04-19 23:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 47857

EZ> I don't see any bug here.  This is the documented behavior: filling
EZ> deletes any excess whitespace, so 2 or more consecutive SPC characters
EZ> are squeezed to a single SPC.

Ah, but one needs

Today's lucky number(s)!: <-added space here
9 <-added space here
10 <-added space here
11

to keep the whitespace in with fill-paragraph, whereas no spaces are
required for

Today's lucky number(s)!:
9
10
11

To safely become:

Today's lucky number(s)!: 9 10 11

(Also the value of enable-kinsoku has no effect here or in #47856,
which makes sense.)





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#47857: fill-paragraph vs. FULLWIDTH DIGITs: bug exposed
  2021-04-19 23:27   ` 積丹尼 Dan Jacobson
@ 2021-04-20 11:29     ` Eli Zaretskii
  0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2021-04-20 11:29 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 47857

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: 47857@debbugs.gnu.org
> Date: Tue, 20 Apr 2021 07:27:05 +0800
> 
> EZ> I don't see any bug here.  This is the documented behavior: filling
> EZ> deletes any excess whitespace, so 2 or more consecutive SPC characters
> EZ> are squeezed to a single SPC.
> 
> Ah, but one needs
> 
> Today's lucky number(s)!: <-added space here
> 9 <-added space here
> 10 <-added space here
> 11
> 
> to keep the whitespace in with fill-paragraph, whereas no spaces are
> required for
> 
> Today's lucky number(s)!:
> 9
> 10
> 11
> 
> To safely become:
> 
> Today's lucky number(s)!: 9 10 11

This is a feature: full-width Latin characters, such as 0, 1, and 9,
are exempted from converting newlines into spaces during filling.
They follow the rules of other CJK characters, which are processed the
same.  I think it's because of line-breaking rules: we can break the
line between any 2 CJK characters, including those above, and thus
adding spaces where there were newlines is superfluous, as it would
artificially create separate words where only one has been before.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-04-20 11:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-18  1:06 bug#47857: fill-paragraph vs. FULLWIDTH DIGITs: bug exposed 積丹尼 Dan Jacobson
2021-04-18  6:52 ` Eli Zaretskii
2021-04-18 16:27   ` Stefan Kangas
2021-04-19 23:27   ` 積丹尼 Dan Jacobson
2021-04-20 11:29     ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).