[Top][All Lists]

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

Re: Bug 130397

From: Agustin Martin
Subject: Re: Bug 130397
Date: Fri, 7 Jan 2005 16:36:18 +0100
User-agent: Mutt/1.5.6+20040907i

On Wed, Jan 05, 2005 at 02:50:09PM +0900, Kenichi Handa wrote:
> Stefan Monnier <address@hidden> writes:
> > But ispell.el should be able to automatically check whether the chars can be
> > safely encoded with the coding-system and if not (as in your example),
> > ispell.el will know that the word can't be checked by ispell and should
> > just be skipped (and maybe marked as "uncheckable").
> That seems to be a good approach.  But, just checking
> whether the chars is encodable with the coding-system is not
> enough.  For instance, entry for "francais" dict doesn't
> contain "ñ" in CASECHARS, but "español" is safely encodable
> by iso-8859-1.  So, the same error happens.  For ispell.el
> to know that "español" is uncheckable, we anyway need the
> current database ispell-dictionary-alist.

Expect otherwise something like

 ispell and its process have different character maps

during ispell-word, as well as some other possible errors. This for single
byte chars. When there is a char that cannot be encoded in the dict encoding
the 'ispell misalignment' errors appears. 

*Ken*, since you are being cc'ed I vaguely remembered some info I somewhere
read about this misalignements. I finally found it,


Essentially seems to be suggested that ispell-word (as well as flyspell)
does not show the misalignment problems because of the way words are passed
to ispell, while ispell-region (and so ispell-buffer) does. I have tested
that in an ad-hoc file, ispell-buffer gives the misalignement error
while flyspell-buffer not. The suggestion is that making ispell-region iterate
over words intead of over lines this could be fixed. Do you think this would
help to get rid of the misalignements, or there are other drawbacks I am not
aware of? I did not see any reply to that mail.

> By the way, isn't it possible to make that database
> automatically from *.aff?

Remember that there is also aspell, so should use .aff when using ispell and
some other way when using aspell.

The way we do this is trust dict maintainers to provide a file with all the
relevant info updated to the dict current values. ispell-dictionary-alist is
rebuilt after that data, that is parsed at dictionary installation. This way
we try to make sure that all values really match, and also that errors can be
fixed more quickly by the dict maintainer, without needing a centralized
maintainer to keep that alist up to date, and that things are done after the
really installed dicts.

By the way, in emacs CVS esperanto entry claims to use iso-8859-1 encoding,
while it should be iso-8859-3, and that being added to the possible
coding-system values.

Regarding this, we added a patch by Joao Cachopo to allow for coding-system
any coding system supported by emacs (http://bugs.debian.org/208518), 

(coding-system :tag "Coding System")

instead of

(choice :tag "Coding system"
      (const iso-8859-1)
      (const iso-8859-2)
      (const koi8-r))

in both ispell-local-dictionary-alist and ispell-dictionary-alist



reply via email to

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