[Top][All Lists]

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

bug#35476: font-lock-{append, prepend}-text-property and anonymous faces

From: Noam Postavsky
Subject: bug#35476: font-lock-{append, prepend}-text-property and anonymous faces
Date: Mon, 13 May 2019 21:01:33 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

tags 35476 fixed
close 35476 27.1

Kévin Le Gouguec <address@hidden> writes:

> [1] Although running 'make lisp/font-lock-tests' in the test/ folder
>     fails on the append test.  Could it be that the Makefile runs the
>     tests against the old font-lock.el that is installed on my system,
>     rather than the new one in my repository?  I took a look at the
>     test_template in test/Makefile, but I could not understand what the
>     machinery loads at a glance.

I forgot to answer this before.  There's two issues here:

1. The default value of load-prefer-newer means that of you change a .el
file without recompiling it, Emacs will load the .elc file instead.

2. For font-lock.el in particular, it's preloaded, so even if you
recompile it, font-lock.elc isn't loaded again, you need to redump

So generally, the way to test changes is

    make && make -C test font-lock-tests

Although it should also work to load the modified .el file explicitly
(untested, but):

    make -C test EMACS_EXTRAOPT='-l font-lock.el' font-lock-tests

>> It's best to avoid using hashes in commit messages, as they're
>> translated to ChangeLog files which might read from the tarball (i.e.,
>> without a git repo to hand).  CONTRIBUTE talks about using "action
>> stamps" but I think date+title is more readable.  Which would be:
>> 2019-04-29 "Refrain from splicing anonymous faces in text properties".
> Ah, right, didn't think of the children^WChangeLog.

> Can e.g. git-show(1) understand action stamps?  I glanced at
> gitrevisions(7) but nothing suggests Git knows anything about this
> format.

I don't think so.  The last time I brought this up on emacs-devel there
was some suggestion that cgit (a git web frontend) would learn to
recognize them eventually, but I'm not sure if anything is really moving
in that direction.

> (Or, going the opposite route, maybe the git-log-to-ChangeLog machinery
> could translate hashes to action stamps?)

Maybe, although personally, as a human reader, I prefer date+title to
both hashes and action stamps, even when reading from git.  Yes, it's
quicker to find a commit given a hash, but that still requires at least
pressing RET or clicking or something like that.  Quite often, just
seeing the title is enough to understand what's meant and I don't need
to dig further.

> Thank you for the review!  Let me know if there are further nits to
> pick.

I think we're good here, pushed to master.

417c52b0b7 2019-05-13T20:41:02-04:00 "Extract common code for adding text 

59ad303e8f 2019-05-13T20:41:02-04:00 "Stop splicing anonymous faces in 

reply via email to

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