Re: [ELPA] New package xeft.el

[Karl Fogel]

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.