Re: user sees \xxx but is thwarted from searching for them

[Eli Zaretskii]

> From: David Kastrup <David.Kastrup@t-online.de>
> Newsgroups: gnu.emacs.bug
> Date: 16 Apr 2002 13:36:45 +0200
> 
> eliz@is.elta.co.il (Eli Zaretskii) writes:
> 
> > On 16 Apr 2002, Dan Jacobson wrote:
> > 
> > > Anyway, the user sees a \.  The user wants to hunt for a \.  The user
> > > must have a Ph.D. to hunt for a \. 
> > 
> > Not really.  `M-: (skip-chars-forward "\000-\177") RET' will do.  
> > Wrapping this into a simple user command is left as an exercise for the 
> > interested reader.
> 
> That's exactly what Dan means by "must have a Ph.D.".  It is easy, but
> non-obvious.

It's easy once you know what to do.  To _know_ it might require
specific knowledge, but to _use_ it does not.

> We have regular expressions like [::ascii::] or so, perhaps something
> like [::encodable-in-the-current-default-encoding::]
> [::not-encodable-in-latin2::] (look for better names) would be a
> first shot at making things easier to wrap into user accessible
> functions.

This was discussed in preparation for Emacs 21.1, and turned out to be
a very complex job.  The main problem is that, contrary to what users
may expect, Emacs does not actually know what characters prevent it to
encode the buffer in the default coding systems.  The code which
implements this test (see the function select-safe-coding-system and
its subroutines) calls primitives that don't return this information.
Instead, they return a list of encodings that can safely encode all of
the characters in the region; Emacs then compares that list with the
list of default and preferred encodings, and if these two lists don't
intersect, it pops up the question.

Several alternatives were suggested to show the offending characters,
but IIRC they were all non-trivial.  On top of that, all the effort to
implement that will go down the drain when Emacs switches to
Unicode-based internal representation of characters.  And since
Handa-san, who does most of the Mule-related development, is currently
busy working on Unicode support... well, you can guess the rest.