bug#22815: 25.0.91; emacs-module.*

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 27. Feb. 2016 um 09:21 Uhr:

> > From: ohki@gssm.otsuka.tsukuba.ac.jp
> > Cc: ohki@gssm.otsuka.tsukuba.ac.jp, 22815@debbugs.gnu.org
> > Date: Sat, 27 Feb 2016 08:21:39 +0900
> >
> > Eli Zaretskii writes:
> > > > From: ohki@gssm.otsuka.tsukuba.ac.jp
> > > > Cc: ohki@gssm.otsuka.tsukuba.ac.jp, 22815@debbugs.gnu.org
> > > > Date: Fri, 26 Feb 2016 19:09:57 +0900
> > > >
> > > > > I was asking why couldn't the plug-in do the conversion, e.g., by
> > > > > using libiconv?  Emacs is not the only piece of software that knows
> > > > > how to convert from one encoding to another.
> > > >
> > > >  I considered using libiconv once, but Emacs has the conversion
> > > >  capability, so why not use it.
> > >
> > > Because it can signal an error, if the encoding you pass is not a
> > > valid coding-system that Emacs recognizes?
> >
> >  Yes it does!
> >  In the course of developing my plugin,
> >  I encountered `Invalid coding system' message,  and Emacs keep working
> >  (no crash, no hangup).
>
> It's all too easy to get that, since Emacs coding-systems have names
> that are rarely used elsewhere.  And using libiconv is easy enough.
>
> So I'm uneasy about this.  What do others think?
>
>
>
>
I agree, this adds complexity without significant advantages.
I'd recommend to add a wrapper for make-unibyte-string instead, then users
can choose to use Emacs functions for decoding and encoding strings.

[-- Attachment #2: Type: text/html, Size: 2389 bytes --]