Re: Adding colour when font-lock in disabled

[Heime <heimeborgia@protonmail.com>]

------- Original Message -------
On Friday, December 9th, 2022 at 12:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> > Date: Fri, 09 Dec 2022 08:09:08 +0000
> > From: Heime heimeborgia@protonmail.com
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > What is weird about it? font-lock-mode places face properties
> > > according to the mode's definitions, so it will overwrite any face
> > > properties you put manually. Thus the need to use a different
> > > property, which font-lock-mode doesn't control.
> > 
> > But them when a user wants to introduce some text with some properties (e.g. colour), what is supposed to do.
> 
> 
> Users aren't supposed to introduce text properties, except via Lisp
> programs.
> 
> > Would you expect someone to use font-lock-face when font-lock is enabled
> > 
> > (propertize "G" 'font-lock-face '(:foreground "green"))
> > 
> > --------
> > 
> > And use
> > 
> > (propertize "G" 'face '(:foreground "green"))
> > 
> > when font lock is disabled.

As a developer, what if I do not want font-lock to change it.
Consider I make a special text file where I need to setup same
sections in specific colours.  Is there some special mode that developers can use for their own configuration and design to display to users, and which is not a programming mode ?  

What is the procedure in case there is font-lock enabled or font-lock disabled ? 
 
Should I use an if condition to test for both, as above ?

> The Lisp program which allows users to add faces should do something
> like that, yes.
> 
> > Why places face properties according to the mode's definitions but not allow us to change the properties of inserted text, when we can do that anyway?
> 
> 
> Because font-lock must be in full control of face property to support
> the situation where the user edits the text, and as result the faces
> should change (e.g., because something that was previously just text
> became a comment or a string, or vice versa).

Right.
 
> > After calling a particular mode definitions, I should be able te change properties rather than having a lock.
> 
> See above: the faces change dynamically to follow editing of the
> buffer text. It is not a one-time operation.

What if I try to do something different.  Making a buffer for a package where users are not expected to change it.  For instance, a package could make a named buffer that logs some operations, with certain things coloured.  The faces would not change dynamically because users cannot edit the buffer text.

> If a user wants to highlight addition portions of the buffer, the
> user-level feature we provide is hi-lock-mode (a minor mode). It
> solves the complexity under the hood, and only requires the user to
> specify the patterns to highlight. So if you want an easy user-level
> interface, I suggest to use that minor mode.