bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Jambunathan K]

Improve facemenu.el: Better "integration" with other libraries.

History junkies can lookup
        http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13686#101

----------------------------------------------------------------

facemenu.el highlights text, so does hi-lock.el.

        facemenu.el => Highlight "this text"
        hi-lock.el  => Highlight all text that "has" "this content".

----------------------------------------------------------------
        
1. Same prefix keys.  Why have two prefixes
        C-x w h and M-o

   Can we merge them into same prefix?

    ,----
    | Global Bindings Starting With M-o:
    | key             binding
    | ---             -------
    | 
    | M-o ESC		Prefix Command
    | M-o b		facemenu-set-bold
    | M-o d		facemenu-set-default
    | M-o i		facemenu-set-italic
    | M-o l		facemenu-set-bold-italic
    | M-o o		facemenu-set-face
    | M-o u		facemenu-set-underline
    | 
    | M-o M-S		center-paragraph
    | M-o M-o		font-lock-fontify-block
    | M-o M-s		center-line
    `----

    ,----
    | `hi-lock-mode' Minor Mode Bindings Starting With C-x w:
    | key             binding
    | ---             -------
    | 
    | C-x w b		hi-lock-write-interactive-patterns
    | C-x w h		highlight-regexp
    | C-x w i		hi-lock-find-patterns
    | C-x w l		highlight-lines-matching-regexp
    | C-x w p		highlight-phrase
    | C-x w r		unhighlight-regexp
    `----

2. Provide default bindings for
     M-x facemenu-set-foreground RET
     M-x facemenu-set-background RET

----------------------------------------------------------------     

In GNU Emacs 24.3.50.10 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2013-04-06 on debian-6.05
Bzr revision: 112232 dgutov@yandex.ru-20130405222212-kae38v65pns84qj0
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
Important settings:
  value of $LANG: en_IN
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Jambunathan K]

Should facemenu.el use overlays for highlighting?

facemenu.el, "works" only for certain modes.  More specifically it works
only for those modes that defines a `facemenu-enable-faces-p'.  Start
exploring with the following snippet

,---- See facemenu-add-face
|
| (unless (facemenu-enable-faces-p)
|   (message "Font-lock mode will override any faces you set in this buffer"))
`----

One main disadvantage of not using overlays is that Orgmode cannot be
used in conjunction with enriched mode.  See the following threads

1. http://lists.gnu.org/archive/html/emacs-orgmode/2011-11/msg00990.html

   Here the user wants to hide a piece of text.  He is probably a
   student trying to recall a piece of memorized information.

   Is it possible to have an "invisible face".  A text having this face
   will not be displayed at all.

2. http://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00179.html

   Lots of cross talk here.

3. http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01277.html

        and

   http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01287.html

    ,----
    | I (actually me and several colleagues here at the school of public
    | health at Harvard) have been using for the past 4 years a note taking
    | app called notecase pro (http://www.notecasepro.com/) which is nice but
    | not FLOSS and lacking in other areas. I am a post doc who takes alot of
    | notes (30-40) daily which include images and color markings.
    | 
    | colors are especially important to us since we use them to mark
    | different commands, research areas, paths, comments and warning so that
    | we have a clear easy to remember color visual clue. We use 15-20 color
    | fg/bg commands. An example note could look like this:
    | 
    | http://i.imgur.com/Ncq6ozs.png
    `----

The notion of persistence of face properties (as in serializing/encoding
face properties in to the edited text - either tex mode, sgml mode or
more importantly enriched mode) is "in built" in to facemenu.el.  It is
not necessary that a highlighted text be encoded/persisted in to the
saved file.  I could be reviewing a piece of text and might want to do
"on the go" highlighting some phrases to take notes without saving it
anyway.

Color-coding of text is indeed an effective note-taking tool.

Side note: 

Since Org mode format is frozen for maximum portability, there is a lot
of resistance on the part of Org mode developers to re-define - C-h v
org-emphasis-alist - to mean more colourful things.  So emphasis is
limited to insipid things like bold, italic etc.

IMNSHO, coloring of text can co-exist with Org mode.  This without the
Orgmode format extended or enhanced.

With facemenu using overlays and very minor adjustments elsewhere, an
enriched/Org mode is possible.  Here the Orgmode parser could be
*oblivious* of the fact that enriched encoding is actually in use and
rely on the facemenu/enriched mode do encode or decode enriched markup.

The format used by "Enriched text" is not popular or well-known.
However, that shouldn't limit chaps who aren't interested in cross
editor or cross platform portability to extract last bit of juice out of
Emacs.

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Wed, 10 Apr 2013 09:20:45 +0530
> 
> 
> Should facemenu.el use overlays for highlighting?

Why should it?  Text properties can do everything that facemenu needs
to do, and they scale much better.

> One main disadvantage of not using overlays is that Orgmode cannot be
> used in conjunction with enriched mode.

Org mode already strains the limits of the Emacs display engine, with
its massive use of invisible text and various display properties.
Adding yet more overlays to it, for such a mundane task as
highlighting text, would be extremely unwise.

If facemenu cannot work with Org, either facemenu should be changed to
be able to do that, or some new feature should be added to Org to
allow the highlighting functionality.

> The notion of persistence of face properties (as in serializing/encoding
> face properties in to the edited text - either tex mode, sgml mode or
> more importantly enriched mode) is "in built" in to facemenu.el.  It is
> not necessary that a highlighted text be encoded/persisted in to the
> saved file.  I could be reviewing a piece of text and might want to do
> "on the go" highlighting some phrases to take notes without saving it
> anyway.

I don't understand what are you talking about.  facemenu doesn't save
the faces, it just allows to define and put them.  Maybe you are
thinking about Enriched text mode.

The usual way Emacs uses faces is that faces are re-applied anew each
time a file is visited.  Enriched does what it does because plain text
files don't have enough structure to re-apply the faces.

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Jambunathan K]

If I have to talk like a layman:

When in an Org file, I want enriched mode to be turned on and the
highlighted text to be persisted in the saved Org file.

As I indicated the blocker is that facemenu.el doesn't play nicely with
font-lock-modes.

Do you think that it is possible to achieve what users are requesting
without using overlays?

----------------------------------------------------------------

As for Orgmode straining the display engine, it depends on many factors
- I guess the size of the Orgmode file, number of foldings, number of
overlays etc.

----------------------------------------------------------------

I have seen prior discussions of using augmented interval trees for
managing overlays.  (Theoretically) Will such a migration alleviate the
problem/fear.

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: 14157@debbugs.gnu.org
> Date: Wed, 10 Apr 2013 21:59:11 +0530
> 
> When in an Org file, I want enriched mode to be turned on and the
> highlighted text to be persisted in the saved Org file.

Enriched mode is a means to an end.  But it's not the only means.

What you need is a way to tell Org to re-highlight some parts of the
text when the file is revisited.  How hard can that be?

> As I indicated the blocker is that facemenu.el doesn't play nicely with
> font-lock-modes.

No face plays nicely with font-lock-modes.

> Do you think that it is possible to achieve what users are requesting
> without using overlays?

Of course.

> As for Orgmode straining the display engine, it depends on many factors
> - I guess the size of the Orgmode file, number of foldings, number of
> overlays etc.

The problem is that a typical Org file has a lot of all of those.
Just moving vertically through a single display line might mean moving
hundreds of KBytes in the buffer.  The way Emacs display was designed,
this use case was not considered as an important one.

> I have seen prior discussions of using augmented interval trees for
> managing overlays.  (Theoretically) Will such a migration alleviate the
> problem/fear.

Being able to find overlays efficiently is only one part of the
problem.  The other one is that we have no easy way of finding which
parts of the buffer are "covered" by an overlay.  That forces many
dubious and expensive tricks during redisplay.

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Stefan Monnier]

> As I indicated the blocker is that facemenu.el doesn't play nicely with
> font-lock-modes.
> Do you think that it is possible to achieve what users are requesting
> without using overlays?

And here's for another suggestion: implement the "planes" I suggested
elsewhere some times ago.  Then we could get rid of
char-property-alias-alist and let any package use its own "face"
property without conflict.
This could also be a GSoC candidate.


        Stefan

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Jambunathan K]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> As I indicated the blocker is that facemenu.el doesn't play nicely with
>> font-lock-modes.
>> Do you think that it is possible to achieve what users are requesting
>> without using overlays?
>
> And here's for another suggestion: implement the "planes" I suggested
> elsewhere some times ago.  Then we could get rid of
> char-property-alias-alist and let any package use its own "face"
> property without conflict.
> This could also be a GSoC candidate.

Here is the relevant thread:

        http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00177.html

>
>
>         Stefan

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Stefan Monnier]

> Why should it?  Text properties can do everything that facemenu needs
> to do, and they scale much better.

BTW, if someone wants to do something useful, overlays could be stored
in the same tree as text-properties and benefit from the same kind
of scalability.
That could be a nice GSoC project.


        Stefan

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Wed, 10 Apr 2013 09:20:45 +0530
> 
>    Is it possible to have an "invisible face".  A text having this face
>    will not be displayed at all.

Forgot to answer this: there's the 'invisible' text property, of
course, but my guess is that this is not what you had in mind.  For
what I think you had in mind, 'display' text property is probably the
right tool, since it can make any text look like almost anything else.

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jambunathan K <kjambunathan@gmail.com>
>> Date: Wed, 10 Apr 2013 09:20:45 +0530
>> 
>>    Is it possible to have an "invisible face".  A text having this face
>>    will not be displayed at all.
>
> Forgot to answer this: there's the 'invisible' text property, of
> course, but my guess is that this is not what you had in mind.  For
> what I think you had in mind, 'display' text property is probably the
> right tool, since it can make any text look like almost anything else.

I mean something like "special" (defface invisible-face ...).  If
`font-lock-comment-face' were to "inherit" from such a face then all
comments in the file will disappear.  A user is likely to understand
faces than text properties.

ps: My question was more of a "madman's question".  So it is quite
possible that it is crazy and something impossible.

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Cc: 14157@debbugs.gnu.org
> Date: Wed, 10 Apr 2013 22:04:39 +0530
> 
> A user is likely to understand faces than text properties.

I see no reason why that should be true.  At most some convenient UI
could be needed.

bug#14157: 24.3.50; Improve facemenu.el: Better "integration" with other libraries

[Jambunathan K]

OP here. Closed.