unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: emacs-devel@gnu.org
Subject: RE: feature request: text property to prevent font-locking
Date: Sat, 30 Aug 2014 23:06:56 -0700 (PDT)	[thread overview]
Message-ID: <7a50dd60-5b1c-4f21-aa38-b095d4449d09@default> (raw)
In-Reply-To: <87wq9pirvf.fsf@zigzag.favinet>

>    But since your reply is the only one so far, Alan, I conclude
>    so far that there is no special interest in this -the problem
>    or the proposed solution.
> 
> Maybe it takes a while for answers to arrive.

Yes, maybe. That's why I called the conclusion tentative ("so far").

> As you point out, font-lock must self-gate in some manner,
> especially to avoid doing useless re-work.  Have you looked at
> the source?  A brief dive shows me that
> 
>  ‘font-lock-mode’ docstring mentions
>  ‘font-lock-fontify-buffer’ which calls
>  ‘font-lock-fontify-buffer-function’ which has the value
>  ‘jit-lock-refontify’ (for me), which calls
>  ‘put-text-property’ w/
>  property name ‘fontified’ and
>  property value ‘nil’
> 
> suggesting that property ‘fontified’ w/ non-‘nil’ value is what
> jit-lock must do as testimony of its work.  Now, that took all of
> two minutes.  The next twenty or two-hundred (if i were lucky
> enough to have them available) would be to understand what
> weirdness must mar this simple model.  Maybe you can do that?

I did look into that in the past (and again before my OP message).
And I did try simply setting `fontified' to non-nil, with no luck.

It's quite possible I am missing something simple, which is why
I asked about that.  I still would like to hear that that is the
case, and how.

> Regardless, i like the straightforward ‘font-lock-ignore’ method
> you demo.  It would be nice to have that level of friendliness in
> Emacs (and documented!).

Seems simple to me too.  But maybe there is something simpler
and already available.  After all, font lock was not added
yesterday.  And surely people have tried to use ad hoc
highlighting in a font-locked buffer.

If nothing else, they must have tried `facemenu-set-face'
(`M-o o') and `facemenu-add-face', which are about as old as
font-lock.  But maybe they tried and just gave up when they saw
the unfriendly message "Font-lock mode will override any faces
you set in this buffer", as if that were the final (discouraging)
word.

In any case, it is not the final word.  With the patch I sent
(bug #18367), font-lock no longer prevents you from using `M-o o'
etc.  (If the patch is accepted then that message should of
course be removed.)

That message's presence is another thing that gives me the
impression that I am maybe not missing something: if there were
already a simple way to stop font-lock from overriding facemenu
highlighting then why would we warn people that it does override
it?  Why wouldn't the `facemenu.el' code just DTRT and stop
font-lock's king-of-the-sandbox bullying ;-) for the space of
facemenu's ad hoc highlighting?



  reply	other threads:[~2014-08-31  6:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-28 21:18 feature request: text property to prevent font-locking Drew Adams
2014-08-30  9:27 ` Alan Mackenzie
2014-08-30 20:15   ` Drew Adams
2014-08-30 21:34     ` Thien-Thi Nguyen
2014-08-31  6:06       ` Drew Adams [this message]
2014-08-31 16:11         ` Drew Adams
2014-08-31 12:40     ` Stefan Monnier
2014-08-31 15:30       ` Drew Adams
2014-08-31 19:57         ` Stefan Monnier
2014-08-31 21:07           ` Drew Adams
2014-08-31 21:43           ` Alan Mackenzie
2014-09-01  1:37             ` Stephen J. Turnbull
2014-09-01 20:45               ` Stefan Monnier
2014-09-02  2:02                 ` Stephen J. Turnbull
2014-09-02  2:33                 ` Richard Stallman
2014-09-02  6:04                   ` David Kastrup
2014-08-31 14:31 ` Wolfgang Jenkner
2014-08-31 16:03   ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7a50dd60-5b1c-4f21-aa38-b095d4449d09@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).