overlays?

overlays?

[lee]

Hi,

could someone please shed a light on the purpose of overlays?  I`m
wondering under what circumstances they are used, or need to be used.
Are they a feature that has been obsoleted by font-lock, or are they
still needed?


The background is that I`ve made an extension to hi-lock.el, and hi-lock
features alternatively using overlays or font-lock.  My extension does
not support overlays, and I`m wondering if support for overlays needs to
be added or not.


-- 
Knowledge is volatile and fluid.  Software is power.

Re: overlays?

[Marcin Borkowski]

Dnia 2014-03-18, o godz. 02:40:35
lee <lee@yun.yagibdah.de> napisał(a):

> Hi,
> 
> could someone please shed a light on the purpose of overlays?  I`m
> wondering under what circumstances they are used, or need to be used.
> Are they a feature that has been obsoleted by font-lock, or are they
> still needed?

With the risk that I say something stupid: isn't font-lock used for
syntax highlighting?  If yes, then: what about i-search (using
overlays) in a font-lock'ed buffer?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: overlays?

[Joost Kremers]

lee wrote:
> could someone please shed a light on the purpose of overlays?  I`m
> wondering under what circumstances they are used, or need to be used.
> Are they a feature that has been obsoleted by font-lock, or are they
> still needed?

Well, one difference with regard to font lock is that overlays do not
depend on the textual content of the buffer. Font lock is used for
highlighting parts of the buffer that match certain regexes (optionally
in specific contexts). Overlays are Lisp objects that are attached to
specific positions in the buffer, regardless of the text in those
positions. Because of that you can use them for things that you couldn't
use font lock for.

A simple example: in a program of mine, I use an overlay to navigate a
list of (BibTeX) keys. See the screenshots here:

<http://joostkremers.github.io/ebib/#screenshots>.

The selected key ("Booij2009" in the first screenshot) is highlighted
using an overlay. Since the key can be anything, there isn't really a
regexp you can come up with that highlights one single entry. Also,
overlays can be moved around the buffer by assigning new buffer
positions to them. That makes it easy to use them for navigating the
list of keys. And overlays can be made temporarily invisible, something
I use in the lower of the two buffers (where the fields of the current
entry are shown): it has an overlay as well, to highlight the current
field, but it's only visible when focus is in the buffer (i.e., when the
user is editing the fields).

All of that would be nigh impossible with font lock.

> The background is that I`ve made an extension to hi-lock.el, and hi-lock
> features alternatively using overlays or font-lock.  My extension does
> not support overlays, and I`m wondering if support for overlays needs to
> be added or not.

That of course is another question. Overlays certainly do have their
uses, they're not obsoleted by font lock. But whether those uses are
relevant for you is something you'll have to decide.



-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: overlays?

[lee]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Dnia 2014-03-18, o godz. 02:40:35
> lee <lee@yun.yagibdah.de> napisał(a):
>
>> Hi,
>> 
>> could someone please shed a light on the purpose of overlays?  I`m
>> wondering under what circumstances they are used, or need to be used.
>> Are they a feature that has been obsoleted by font-lock, or are they
>> still needed?
>
> With the risk that I say something stupid: isn't font-lock used for
> syntax highlighting?

With hi-lock-mode, either overlays are, or font-lock is used.  I`d have
to check if it potentially uses both.  Perhaps I can somehow make it use
overlays just to see what happens.

My understanding was that it may depend on the display/terminal whether
font-lock or overlays is/are used.  This understanding seems to be
obviously wrong.  They are suited for different circumstances.

> If yes, then: what about i-search (using overlays) in a font-lock'ed
> buffer?

What about it?  Does it use overlays?


-- 
Knowledge is volatile and fluid.  Software is power.

Re: overlays?

[lee]

Joost Kremers <joost.m.kremers@gmail.com> writes:

> lee wrote:
>> could someone please shed a light on the purpose of overlays?  I`m
>> wondering under what circumstances they are used, or need to be used.
>> Are they a feature that has been obsoleted by font-lock, or are they
>> still needed?
>
> Well, one difference with regard to font lock is that overlays do not
> depend on the textual content of the buffer. Font lock is used for
> highlighting parts of the buffer that match certain regexes (optionally
> in specific contexts).

How am I to imagine "specific contexts"?  Like within a function
definition (i. e. a syntactical context) and/or something else (like
"the first five lines of the buffer")?

> Overlays are Lisp objects that are attached to
> specific positions in the buffer, regardless of the text in those
> positions. Because of that you can use them for things that you couldn't
> use font lock for.

So an overlay could possibly be better for "the first five lines of the
buffer" than font-lock.

> A simple example: in a program of mine, I use an overlay to navigate a
> list of (BibTeX) keys. See the screenshots here:
>
> <http://joostkremers.github.io/ebib/#screenshots>.
>
> The selected key ("Booij2009" in the first screenshot) is highlighted
> using an overlay. Since the key can be anything, there isn't really a
> regexp you can come up with that highlights one single entry.

I see :)  And the overlay will be at the wrong position, or even
off-screen, when the size of the display changes?

>> The background is that I`ve made an extension to hi-lock.el, and hi-lock
>> features alternatively using overlays or font-lock.  My extension does
>> not support overlays, and I`m wondering if support for overlays needs to
>> be added or not.
>
> That of course is another question. Overlays certainly do have their
> uses, they're not obsoleted by font lock. But whether those uses are
> relevant for you is something you'll have to decide.

Well, the question is whether the extension I made to hi-lock.el needs
to, or should, support overlays or not.  Since now I understand the
difference between font-lock and overlays, I need to find out what
hi-lock.el uses them for and what it does with them.  That will provide
an answer.


-- 
Knowledge is volatile and fluid.  Software is power.

Re: overlays?

[Jambunathan K]

lee <lee@yun.yagibdah.de> writes:

> Since now I understand the difference between font-lock and overlays,
> I need to find out what hi-lock.el uses them for and what it does with
> them.

If you do

   M-x font-lock-mode

then font-lock gets disabled (or enabled).

If font locking is disabled, hi-lock will use overlays and not the
fontification engine for displaying highlights.

(I think in certain terminal types, font-locking is not available and
overlays get used.  Someone can correct me if I am wrong or provide more
information in this regard.)

Re: overlays?

[Joost Kremers]

lee wrote:
> How am I to imagine "specific contexts"?  Like within a function
> definition (i. e. a syntactical context) and/or something else (like
> "the first five lines of the buffer")?

With "specific contexts", I meant that you can highlight text matching
some regexp if it occurs on the same line as some other regexp. So you
can highlight all occurrences of "bar" that occur on the same line as
"foo", and leave occurrences of "bar" that do not occur together with
"foo".

In Elisp code, for example, a function name is highlighted with
`font-lock-function-name-face' if it is preceded by the string "(defun",
but not in other contexts.

See the Elisp manual for details:

(info "(elisp) Search-based Fontification") <=== Position the cursor here and press `C-x C-e'

> So an overlay could possibly be better for "the first five lines of the
> buffer" than font-lock.

Yes, but you'll have to find a way to figure out where the first five
lines of the buffer end.

> I see :)  And the overlay will be at the wrong position, or even
> off-screen, when the size of the display changes?

No. Overlays are tied to specific buffer positions, so when a display
size change causes those buffer positions to move to another part of the
screen, the overlay changes along with it. In the same way that the
characters at those buffer positions are moved across the screen.
(Actually, I'm not entirely sure I understand your question here.
Perhaps it's caused by confusion over the term "buffer position"? If so,
check out the Elisp manual (info "(elisp) Positions") for an
explanation.)

> Well, the question is whether the extension I made to hi-lock.el needs
> to, or should, support overlays or not.  Since now I understand the
> difference between font-lock and overlays, I need to find out what
> hi-lock.el uses them for and what it does with them.  That will provide
> an answer.

Yup. Have fun! :-)


-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: overlays?

[Stefan]

>> So an overlay could possibly be better for "the first five lines of the
>> buffer" than font-lock.

This makes no sense: You can't oppose "font-lock" and "overlays",
really, because they are by nature different beasts.

`font-lock' is a library that puts "things" on some parts of the buffer
to change their appearance (color, font, size, ...).  hi-lock is another
library that does the same, tho it is meant to be used differently (the
rules specifying what-to-put-where are typically specified interactively
in hi-lock whereas they are typically specified once and for all by the
major-mode author for font-lock, so they can be more complex).

Emacs offers to kinds of "things" that can be used for that purpose:
text-properties and overlays.  These *are* comparable (e.g. font-lock
uses text-properties, but it could use overlays instead).


        Stefan