GNU bug report logs - #35476
[PATCH] 27.0.50; font-lock-{append,prepend}-text-property and anonymous faces

Previous Next

Package: emacs;

Reported by: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>

Date: Sun, 28 Apr 2019 17:12:02 UTC

Severity: normal

Tags: fixed, patch

Fixed in version 27.1

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #33 received at 35476 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35476 <at> debbugs.gnu.org
Subject: Re: bug#35476: font-lock-{append,
 prepend}-text-property and anonymous faces
Date: Tue, 14 May 2019 08:01:04 +0200
Noam Postavsky <npostavs <at> gmail.com> writes:

> Kévin Le Gouguec <kevin.legouguec <at> 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.

Duly noted, I'll watch out for that in the future.

> 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

Just tried with and without EMACS_EXTRAOPT, and it does seem to work
around the problem.

>> 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.

OK.  FWIW, since I like to give context to my messages and I expect to
be doing the hash ↦ date+title dance a lot, this command seems to do the
job adequately for commit $c:

    git show --no-patch --date=short --format=format:'%ad "%s"' $c

Now to write some Lisp to make that available from vc and magit buffers…

(one-liner for action stamps left as exercise to the reader)

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

Thanks!




This bug report was last modified 6 years and 4 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.