[Top][All Lists]

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

Re: Dynamic loading progress

From: Philipp Stephani
Subject: Re: Dynamic loading progress
Date: Sat, 21 Nov 2015 09:01:12 +0000

Eli Zaretskii <address@hidden> schrieb am Fr., 20. Nov. 2015 um 10:54 Uhr:

>     Re this fragment from module.c:
>     Lisp_Object ret = list4 (Qlambda,
>     list2 (Qand_rest, Qargs),
>     documentation ? build_string (documentation) : Qnil,
>     list3 (module_call_func,
>     envobj,
>     Qargs));
>     Thou shalt not use build_string, except when you _know_ the argument
>     will always be a pure-ASCII string. Practically, this means the
>     argument must be a constant ASCII string. See these messages (and the
>     preceding discussion, if you are interested) for the gory details:
>     http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-10/msg00955.html
>     http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-10/msg00976.html
>     http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-10/msg00979.html
>     The above should call make_multibyte_string instead.
> We had a discussion about encodings in
> https://github.com/aaptel/emacs-dynamic-module/issues/37. Sorry that this
> didn't get resolved earlier; it's an important point. My suggestion would be to
> always mandate specifying an encoding whenever a char* is passed, and limit
> that to two or three functions dealing with creating strings and accessing
> string contents. Would that address your concerns?

No, this is not about encoding at all.  This is about calling
build_string: you should only call it when the argument is a fixed
ASCII string.  If the argument is not fixed or might include non-ASCII
characters, you should call make_multibyte_string instead.  That's
because build_string might decide on its own whether to produce a
unibyte or a multibyte string, out of your control, whereas we always
want a multibyte string in this context.

build_string doesn't encode or decode its argument, it creates a Lisp
object whose text is taken from the argument.  It's similar to
make_number in that respect.

Let me summarize the issues I see: The internal Emacs encoding can change between versions (command in mule-conf.el), therefore we shouldn't use it in the module API. IIUC this rules out make_multibyte_string: it only accepts the internal encoding. Therefore I proposed to always have users specify the encoding explicitly and then use code_convert_string_norecord to create the Lisp string objects. Would that work? (We probably then need another set of functions for unibyte strings.)

reply via email to

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