From: "B.T. Raven" <ejmn@cpinternet.com>
Subject: Re: i18n search/replace with input methods latin-4-postfix and rfc1345
Date: Wed, 16 Mar 2005 11:18:29 -0600 [thread overview]
Message-ID: <113gqjs29ib2l2d@corp.supernews.com> (raw)
In-Reply-To: 877jk8kxtt.fsf-monnier+gnu.emacs.help@gnu.org
Thanks again, monsieur Monnier. I posted a note about my problem to
gnu.emacs.bug. As a forlorn hope, I changed my encoding of .emacs from
emacs-mule to utf-8 but it didn't make any difference. A fresh latin-4
character is still different from the same one after it has been saved
and revisited.
Although I downloaded the entire suite of cygwin packages (including cvs
and stunnel) I know how to use only the shell tools (grep, sed, sort,
etc) but these things aren't unicode aware and I couldn't conveniently
input strange characters from the command line anyway (if for instance I
wanted make changes with sed by looking at the emacs buffer in one
window and the command line in a Dos Window.
Ed.
"Stefan Monnier" <monnier@iro.umontreal.ca> wrote in message
news:877jk8kxtt.fsf-monnier+gnu.emacs.help@gnu.org...
> >> > (unify-8859-on-decoding-mode 1)
> >>
> >> Good.
> >>
> >> > '(unify-8859-on-encoding-mode t nil (ucs-tables))
> >>
> >> Good as well. Except that the two do the same thing redundantly,
so
> > it's
> >> better to get rid of one of them. I.e. if you like to configure
your
> > system
> >> with Custom, then keep the second, else keep the first.
>
> > They shouldn't do the same thing since one is for decoding and the
other
> > for encoding.
>
> Oops, sorry, I wasn't careful enough.
>
> > Anyway I think I'll stick with Custom since it's probably the less
error
> > prone method. Apparently unify on encoding is safe but the other
one can
> > cause information loss.
>
> Indeed, but only in "unusual" situations (e.g. if you use encodings
like
> iso-2022). And in your case, unification on decoding is exactly what
you
> need (provided you're not bumping into a bug that prevents it from
doing
> its job, of course).
>
> > I am using the NT build and am not comfortable compiling from
source. I
> > have cygwin running under MS win but have never tried to build
anything
> > with gcc.
>
> I think cygwin has a precompiled cygwin version of the CVS code.
>
>
> Stefan
next prev parent reply other threads:[~2005-03-16 17:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-14 3:39 i18n search/replace with input methods latin-4-postfix and rfc1345 B.T. Raven
2005-03-14 13:33 ` Stefan Monnier
2005-03-14 17:43 ` B.T. Raven
2005-03-15 20:33 ` Stefan Monnier
2005-03-16 0:11 ` B.T. Raven
2005-03-16 4:43 ` Stefan Monnier
2005-03-16 17:18 ` B.T. Raven [this message]
2005-03-16 17:54 ` Stefan Monnier
2005-03-17 3:52 ` B.T. Raven
2005-03-17 15:18 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=113gqjs29ib2l2d@corp.supernews.com \
--to=ejmn@cpinternet.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.