Re: [ELPA] New package xeft.el

[Karl Fogel <kfogel@red-bean.com>]

On 04 Jan 2023, Stefan Monnier wrote:
>Yuan Fu [2023-01-02 20:11:50] wrote:
>> I wrote xeft.el awhile ago, it allows you to search text notes 
>> really fast
>> by using a dynamic module. My initial plan is to somehow plug 
>> the dynamic
>> module into Deft some day and I’ll keep xeft to myself. Turns 
>> out it’s not
>> very feasible to make Deft use the dynamic module, so now I 
>> thought I might
>> as well publish xeft. After all I think it is really cool and I 
>> want more
>> people to use it :-)
>>
>> You can find xeft here: https://git.sr.ht/~casouri/xeft
>
>I'm a bit uncomfortable with the way this is set up:
>it's unusable without downloading further code first.

FWIW, I also was uncomfortable with this.  I started to try out 
xeft, but then I stopped when it asked me if I wanted to download 
a binary package whose provenance wasn't clear to me.

Actually, I tried choosing the 'c' option to 'c'ompile, but that 
got a generic error, "Wrong type argument" or something like that. 
I couldn't tell what was wrong.  I thought that having certain 
Debian packages (xapian-tools, python3-xapian, libxapian30, 
libxapian-dev) installed already might mean that xeft would Just 
Work, but that wasn't the case.

Best regards,
-Karl

>Why not do it like the `pq` package, which includes the C source 
>code in
>the GNU ELPA package?  IOW merge your `xapian-lite` repository 
>into the
>`xeft` repository.  Or make a GNU ELPA package for `xapian-lite` 
>if you
>think the two should not be so closely tied to one another?
>
>Other details I saw along the way:
>- You claim you have precompiled packages for GNU/Linux but 
>that's only
>  true for amd64, which is only a particular subset of GNU/Linux
>  (most of my GNU/Linux machines (i386, armhf, arm64) are outside 
>  of
>  that subset, for example).
>
>- Your source code includes `emacs-module.h` which should not be
>  necessary because that file is distributed with Emacs (the way 
>  `pq`
>  finds it is not ideal, but this might be a good opportunity to 
>  look
>  at improving the situation and providing a standardized way for
>  ELisp packages to find that file).
>
>- `xapian-lite.cc` lacks a license blurb.