all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Heime <heimeborgia@protonmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Adding colour when font-lock in disabled
Date: Fri, 09 Dec 2022 12:27:22 +0000	[thread overview]
Message-ID: <TqcJ11RTBMwfSWJxa0S0LszAgM_5lZT5Ap51Q6zgiOMzXKKN-nEjlzVtLyCNhfVioXp8HuEDC3PuB1EWNFboY5gVUxQcxY_5t5IzKxL4Gog=@protonmail.com> (raw)
In-Reply-To: <831qp82340.fsf@gnu.org>

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



  reply	other threads:[~2022-12-09 12:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09  0:50 Adding colour when font-lock in disabled Heime
2022-12-09  1:46 ` Heime
2022-12-09  7:09   ` Eli Zaretskii
2022-12-09  8:09     ` Heime
2022-12-09 12:06       ` Eli Zaretskii
2022-12-09 12:27         ` Heime [this message]
2022-12-09 12:36           ` Eli Zaretskii
2022-12-09 13:04             ` Heime
2022-12-09 14:53               ` Eli Zaretskii
2022-12-09 18:54           ` Jean Louis
2022-12-09 21:39             ` [External] : " Drew Adams
2022-12-09 23:19             ` Heime
2022-12-10  7:31               ` Eli Zaretskii
2022-12-10  8:31                 ` Heime
2022-12-10  8:50                   ` Eli Zaretskii
2022-12-10 11:06                     ` Heime
2022-12-09  8:26     ` Heime
2022-12-09 12:07       ` Eli Zaretskii
2022-12-09 13:48       ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-10  1:59       ` Emanuel Berg

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

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

  git send-email \
    --in-reply-to='TqcJ11RTBMwfSWJxa0S0LszAgM_5lZT5Ap51Q6zgiOMzXKKN-nEjlzVtLyCNhfVioXp8HuEDC3PuB1EWNFboY5gVUxQcxY_5t5IzKxL4Gog=@protonmail.com' \
    --to=heimeborgia@protonmail.com \
    --cc=eliz@gnu.org \
    --cc=help-gnu-emacs@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.