Re: woman.el broken?

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 5 Mar 2021 19:43:24 -0800
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> >> If this is performant enough, I don't at the moment see any reason to
> >> have it in C.  Of course, the few places that call Flookup_key from C
> >> will need to be analyzed whether they need to call the internal
> >> function or the Lisp wrapper, and modified accordingly.
> >
> > OK.  I will write up the patch and do some benchmarks.
> 
> Turns out this was actually easier and faster to just do in C, as there
> were less places that needed changing.  See the attached diff.

Thanks.

> The thing that is missing now is converting Foo\ Bar to foo-bar, but
> what is the best method for doing that from C?  Should I just call out
> to `string-replace' or is there a better way?

Something like this should do:

  . copy the original string data to a local buffer (use
    USE_SAFE_ALLOCA and SAFE_ALLOCA to allocate a suitable buffer)
  . replace each space with a '-' in a simple loop that examines each
    character in the above buffer
  . use build_string to create a new string from the replaced contents

> +      Lisp_Object new_key = Fmake_vector (make_fixnum (ASIZE (key)), Qnil);

I think it's better to use make_vector here.

A general comment: many Emacs primitives are just thin wrappers around
C functions; those wrappers typically take care of checking the type
of the arguments, converting Lisp data types to C data types, etc.  In
this case, you will see that Fmake_vector calls make_vector, which is
its workhorse.

When calling those primitives from C, it is generally better to call
the C workhorse instead of the primitive, because that avoids wasting
cycles on checking data types that are already known in advance (by C
rules) to be correct, and consing Lisp data from the underlying C data
(like the call to make_fixnum in this case, but it's even more start
when you need to make a Lisp string from a C string).  The convenience
of such calls from C is actually one reason why we generally prefer to
implement primitives in this 2-layer fashion.