emacs-devel
[Top][All Lists]
Advanced

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

Re: [ELPA] New package: ert-font-lock


From: john muhl
Subject: Re: [ELPA] New package: ert-font-lock
Date: Mon, 20 Nov 2023 22:45:19 -0600

Vladimir Kazanov <vekazanov@gmail.com> writes:

> Hi everyone,
>
> Just bumping this thread for visibility.
>
> I've made most of the changes that were suggested earlier and
> clarified how my package differs from faceup.el. I'm also considering
> if it's feasible to lower the Emacs version requirement to 27.1 and
> planning to run some more tests for edge cases. Other than that, the
> tool is pretty much set and shouldn't see major changes.
>
> Could you let me know what I should do next to move forward with
> adding the package to ELPA (or Emacs itself if Eli doesn't mind)?
>
> Thanks a lot for your help!

FWIW I used it to add tests for lua-ts-mode’s font-lock rules.
It works well and feels to me like it would be a nice addition
to Emacs. Thanks for working on it.

> On Sun, 19 Nov 2023 at 10:08, Vladimir Kazanov <vekazanov@gmail.com> wrote:
>>
>> > I won't object to including this, FWIW.
>>
>> Would this require any additional changes to the way the code is structured?
>>
>> There were also some questions around ert-font-lock.el being similar
>> to faceup.el. I covered these elsewhere.
>>
>> On Sat, 18 Nov 2023 at 12:43, Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> > > From: Po Lu <luangruo@yahoo.com>
>> > > Cc: Vladimir Kazanov <vekazanov@gmail.com>,  emacs-devel@gnu.org
>> > > Date: Sat, 18 Nov 2023 20:07:42 +0800
>> > >
>> > > Philip Kaludercic <philipk@posteo.net> writes:
>> > >
>> > > > ELPA shouls be fine.
>> > >
>> > > Since this is an adjunct to ERT, which is plausibly useful for the unit
>> > > testing of Emacs fontification code itself, I think such code should be
>> > > part of Emacs proper.
>> >
>> > I won't object to including this, FWIW.
>> >
>> > > BTW, this code requires cl-lib for a meager one macro.  Please replace
>> > >
>> > >       (cl-incf curline)
>> > >
>> > > with
>> > >
>> > >       (setq curline (1+ curline))
>> > >
>> > > that cl-lib might not be loaded either at compile-time or runtime.
>> > > There is no rationale for requiring cl-lib so as to employ a single
>> > > macro once.
>> >
>> > Doesn't this library require ert?  if it does, cl-lib is already
>> > loaded by ert.
>> >
>> > But if people like cl-incf so much, we could just add incf to subr.el
>> > or something.
>>
>>
>>
>> --
>> Regards,
>>
>> Vladimir Kazanov




reply via email to

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