From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefan@marxist.se>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: woman.el broken?
Date: Sat, 06 Mar 2021 10:07:16 +0200 [thread overview]
Message-ID: <83wnukwvrf.fsf@gnu.org> (raw)
In-Reply-To: <CADwFkmnbd03otW90jqja1k4=nsDJ8Cm9CRMOufjfG2VQbeaV7w@mail.gmail.com> (message from Stefan Kangas on Fri, 5 Mar 2021 19:43:24 -0800)
> 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.
prev parent reply other threads:[~2021-03-06 8:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 19:39 woman.el broken? T.V Raman
2021-03-01 19:48 ` Lars Ingebrigtsen
2021-03-01 20:02 ` Eli Zaretskii
2021-03-01 20:07 ` Lars Ingebrigtsen
2021-03-01 20:19 ` Eli Zaretskii
2021-03-01 20:25 ` Eli Zaretskii
2021-03-01 20:42 ` Stefan Monnier
2021-03-02 5:18 ` Eli Zaretskii
2021-03-01 20:47 ` Lars Ingebrigtsen
2021-03-01 21:06 ` Lars Ingebrigtsen
2021-03-01 21:29 ` Lars Ingebrigtsen
2021-03-03 2:23 ` Stefan Kangas
2021-03-03 6:25 ` Eli Zaretskii
2021-03-03 14:19 ` Stefan Kangas
2021-03-03 14:40 ` Eli Zaretskii
2021-03-03 18:46 ` Stefan Kangas
2021-03-06 3:43 ` Stefan Kangas
2021-03-06 8:07 ` Eli Zaretskii [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83wnukwvrf.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=stefan@marxist.se \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).