emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47856: closed (auto-fill-mode vs. oriental languages: no respect)


From: GNU bug Tracking System
Subject: bug#47856: closed (auto-fill-mode vs. oriental languages: no respect)
Date: Tue, 20 Apr 2021 12:15:02 +0000

Your message dated Tue, 20 Apr 2021 15:14:34 +0300
with message-id <83tuo1qhjp.fsf@gnu.org>
and subject line Re: bug#47856: auto-fill-mode vs. oriental languages: no 
respect
has caused the debbugs.gnu.org bug report #47856,
regarding auto-fill-mode vs. oriental languages: no respect
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
47856: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47856
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: auto-fill-mode vs. oriental languages: no respect Date: Sun, 18 Apr 2021 08:14:35 +0800
auto-fill-mode is an interactive compiled Lisp function in‘simple.el’. ...

   When Auto Fill mode is enabled, inserting a space at a column
                                               ^^^^^[1]
   beyond ‘current-fill-column’ automatically breaks the line at a
   previous space.
   ^^^^^^^^^^^^^^[2]

That is all fine and dandy. But it has no respect for oriental
languages.

What if it bro
ke a line like th
is?

That's how it treats oriental languages.

What if emacs "helpfully" turned

...if temperature > temp
   then stop_nuclear_reactor()

into

...if temp
   erature > temp
   then stop_nuclear_reactor()

Syntax error. Meltdown!

It's like if one wore braces for five years, and along came emacs and
in one second put ugly gaps back in your teeth.

Here is my line, pre-victimization:

 <p>那麼請貴司, 走過去台電大樓坐下來合作, 透過台電內部精準座標, 把這些孤兒門牌, 盡量一一歸案。</p>

And here is the mangled result:

 <p>那麼請貴司, 走過去台電大樓坐下來合作, 透過台電內部精準座標, 把
   這些孤兒門牌, 盡量一一歸案。</p>

In [2] we were promised "at a previous *space*".

Well it lied.

We put plenty of *spaces* in the line,
just to feed its hungry mouth.
But no. It had to go rip in to
"把這些孤兒門牌,"
and put a goofy gap in:
"把 這些孤兒門牌,"
That's how the rendered HTML will look.

Might as well make it

"把 這 些 孤 兒 門 牌,"

that way readers will think you were angry.

Also if the space is accidentally inserted before presidents' names,
that will mean you support/honor/respect them.

Sure, in English, President Nixon looks better than PresidentNixon.
So you will just have to take my word that I know what I am talking about.

I.e., it is super dangerous to go inserting random spaces in oriental
languages where there was none to begin with.

If there was one to begin with, then make it two or three, be my guest.
But don't just go semi-randomly put ting gaps in gran dmas' te eth. Than k you.

If there really is no way then to break a line, then just don't break
it. It's the user's problem in that case.

Maybe it can play fast and lose with .txt files,
but it should know better how silly it will make HTML look.

"Well browsers will break your oriental lines arbitrarily anyway. Bug closed."

Yes, but they do that a the ends of lines they render. The damage that
emacs does to the source file ends up as an ugly mid-word gap.
(Unless in the rare case where the browser also breaks the line at
emacs' gap, in which case the reader will not notice any problem.)

[1] P.S., RET at the end of line will destroy the line too. Not just space.
What's worse, you probably won't notice what happened, as your eyes are
already on the next line.

Seen with emacs 27.1, using -q. LC_CTYPE=zh_TW.UTF-8 .



--- End Message ---
--- Begin Message --- Subject: Re: bug#47856: auto-fill-mode vs. oriental languages: no respect Date: Tue, 20 Apr 2021 15:14:34 +0300
> Date: Tue, 20 Apr 2021 14:24:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 47856@debbugs.gnu.org
> 
> So yeah, it's a documentation issue, to be fixed soon enough.

Now done, and closing the bug.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]