[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
quit
Kévin Le Gouguec <kevin.legouguec@gmail.com> 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
Emacs.
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.
:D
> 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
properties"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=417c52b0b7fbf5cb02d229e81b7aaaacf2082bde
59ad303e8f 2019-05-13T20:41:02-04:00 "Stop splicing anonymous faces in
font-lock-append-text-property"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=59ad303e8f3bb174ce326c76a9e7649f602120db