unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Kenichi Handa <handa@m17n.org>
Cc: emacs-devel@gnu.org
Subject: Re: Problem of auto-fill-mode for wide character
Date: Wed, 04 Jan 2006 13:28:08 +0900	[thread overview]
Message-ID: <E1Eu0Fs-0000Er-00@etlken> (raw)
In-Reply-To: <BAY110-F80BEFA32ECA37B6399567DA280@phx.gbl> (herberteuler@hotmail.com)

In article <BAY110-F80BEFA32ECA37B6399567DA280@phx.gbl>, "Herbert Euler" <herberteuler@hotmail.com> writes:
[...]
>> I've just registered these apparent characters:
>>    U+3041..U+30FF, U+3400..U+4DB5, U+4e00..U+9fbb, U+F900..U+FAFF,
>>    U+FF00..U+FF9F, U+20000..U+2FFFF
>> So, now auto-fill should work for most Han characters.
>> 
>> But, there are many more questionable characters, for instance:
>>    U+3000..U+303F, U+3200..U+33FF, ...

> In my opinion, this solution is not an applicable one. Trying to register
> most characters in Chinese, Japanese and Korean as auto-fill-chars would
> waste lots of memory, and perhaps some characters would be forgot
> to be registered. For example, in Japanese, Hiragana and Katakana
> probably work, but not for most Kanji. Besides, the policy for filling
> punctuations in English and in Chinese is different: usually, if a 
> punctuation
> appears to be the last character of a line but exceeds the fill-column,
> it will be extended to the next line with the word it follows in English,
> but left there (and following characters will be moved to the next
> line) in Chinese. I don't know whether this is supported by registering
> auto-fill-chars.

At first, a char-table doesn't consume that much space if
you register characters of continuous codes.  For instance,
registering all Han characters is not a problem.

Next, it seems that you misunderstand the role of
auto-fill-chars.  It's a table to register characters that
triggers the auto-fill-function.  How auto-fill-function
fills the line(s) is a different thing.

And, although it's difficult to explain how lines are filled
(it's encoded in functions), at least Emacs considers
special treatment of punctuations (e.g. opening/closing
parentheses at the end/beginning of line) for Chinese and
Japanese.  You'll get a hint if you read
lisp/international/kinsoku.el.

---
Kenichi Handa
handa@m17n.org

  reply	other threads:[~2006-01-04  4:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-17 15:58 Problem of auto-fill-mode for wide character Herbert Euler
2005-12-28  7:46 ` Kenichi Handa
2005-12-30  2:43   ` Herbert Euler
2006-01-04  4:28     ` Kenichi Handa [this message]
2006-01-09  2:56   ` Herbert Euler
2006-01-10  1:20     ` Kenichi Handa
2006-01-10  1:58       ` Herbert Euler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1Eu0Fs-0000Er-00@etlken \
    --to=handa@m17n.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).