Inspecting behaviour of `make-overlay', is this expected?

Inspecting behaviour of `make-overlay', is this expected?

[Jean Louis]

XXXXXXXXXX
^
| position 0 in buffer

(setq my-overlay (make-overlay 0 10))
(get-buffer-window (overlay-buffer my-overlay))
(overlay-put my-overlay 'display "Hello") then I get:

HelloX 

instead of "Hello"

Is this normal behavior?

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Inspecting behaviour of `make-overlay', is this expected?

[Eli Zaretskii]

> Date: Sat, 24 Dec 2022 10:52:47 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> XXXXXXXXXX
> ^
> | position 0 in buffer
> 
> (setq my-overlay (make-overlay 0 10))
> (get-buffer-window (overlay-buffer my-overlay))
> (overlay-put my-overlay 'display "Hello") then I get:
> 
> HelloX 
> 
> instead of "Hello"
> 
> Is this normal behavior?

Yes.  The 10 part says that the overlay _ends_ before position 10.
This is standard Emacs behavior with text properties and overlays: END
means the first character NOT affected by the property/overlay.

RE: [External] : Inspecting behaviour of `make-overlay', is this expected?

[Drew Adams]

> XXXXXXXXXX
> ^
> | position 0 in buffer

Position 1.  Buffer positions start with 1.

Try (make-overlay 1 11).

Re: Inspecting behaviour of `make-overlay', is this expected?

[Jean Louis]

x* Eli Zaretskii <eliz@gnu.org> [2022-12-24 11:40]:
> > Date: Sat, 24 Dec 2022 10:52:47 +0300
> > From: Jean Louis <bugs@gnu.support>
> > 
> > XXXXXXXXXX
> > ^
> > | position 0 in buffer
> > 
> > (setq my-overlay (make-overlay 0 10))
> > (get-buffer-window (overlay-buffer my-overlay))
> > (overlay-put my-overlay 'display "Hello") then I get:
> > 
> > HelloX 
> > 
> > instead of "Hello"
> > 
> > Is this normal behavior?
> 
> Yes.  The 10 part says that the overlay _ends_ before position 10.
> This is standard Emacs behavior with text properties and overlays: END
> means the first character NOT affected by the property/overlay.

Good to know.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Inspecting behaviour of `make-overlay', is this expected?

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2022-12-24 19:30]:
> > XXXXXXXXXX
> > ^
> > | position 0 in buffer
> 
> Position 1.  Buffer positions start with 1.
> 
> Try (make-overlay 1 11).

OK it means I have to add one.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Inspecting behaviour of `make-overlay', is this expected?

[Drew Adams]

> > XXXXXXXXXX
> > ^
> > | position 0 in buffer
> 
> Position 1.  Buffer positions start with 1.
> 
> Try (make-overlay 1 11).

You _can_ pass 0 to `make-overlay', but it
creates the overlay starting at position 1.

E.g. (make-overlay 0 10) creates an overlay
from the first position, 1, through the 9th
(as Eli mentioned).

As (elisp) `Managing Overlays' tells you:

 Function: make-overlay start end &optional buffer front-advance
           rear-advance
     This function creates and returns an overlay that belongs to BUFFER
     and ranges from START to END.  Both START and END must specify
     buffer positions; they may be integers or markers

You can use `overlay-start' and `overlay-end'
to see the limits of your overlay.

Re: [External] : Inspecting behaviour of `make-overlay', is this expected?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

On Sat, Dec 24, 2022 at 04:39:55PM +0000, Drew Adams wrote:
> > > XXXXXXXXXX
> > > ^
> > > | position 0 in buffer
> > 
> > Position 1.  Buffer positions start with 1.
> > 
> > Try (make-overlay 1 11).
> 
> You _can_ pass 0 to `make-overlay', but it
> creates the overlay starting at position 1.

Same as if you pass -12 as start position: it gets rounded (if
you allow that expression ;-) up to 1:

  (overlay-start (make-overlay 0 10))
  => 1

> E.g. (make-overlay 0 10) creates an overlay
> from the first position, 1, through the 9th
> (as Eli mentioned).
> 
> As (elisp) `Managing Overlays' tells you:
> 
>  Function: make-overlay start end &optional buffer front-advance
>            rear-advance
>      This function creates and returns an overlay that belongs to BUFFER
>      and ranges from START to END.  Both START and END must specify
>      buffer positions; they may be integers or markers
> 
> You can use `overlay-start' and `overlay-end'
> to see the limits of your overlay.

I often use `eval-expression' and friends to clear up those
things.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Inspecting behaviour of `make-overlay', is this expected?

[Marcin Borkowski]

On 2022-12-24, at 09:36, Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Sat, 24 Dec 2022 10:52:47 +0300
>> From: Jean Louis <bugs@gnu.support>
>> 
>> XXXXXXXXXX
>> ^
>> | position 0 in buffer
>> 
>> (setq my-overlay (make-overlay 0 10))
>> (get-buffer-window (overlay-buffer my-overlay))
>> (overlay-put my-overlay 'display "Hello") then I get:
>> 
>> HelloX 
>> 
>> instead of "Hello"
>> 
>> Is this normal behavior?
>
> Yes.  The 10 part says that the overlay _ends_ before position 10.
> This is standard Emacs behavior with text properties and overlays: END
> means the first character NOT affected by the property/overlay.

Somewhat related: https://fhur.me/posts/always-use-closed-open-intervals
(not my piece, just found it on the internet; also I do not want to
imply the OP doesn't know/understand that - but I consider this short
article interesting & worthwhile also for others reading this).

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Inspecting behaviour of `make-overlay', is this expected?

[Jean Louis]

* Marcin Borkowski <mbork@mbork.pl> [2022-12-25 11:05]:
> On 2022-12-24, at 09:36, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> Date: Sat, 24 Dec 2022 10:52:47 +0300
> >> From: Jean Louis <bugs@gnu.support>
> >> 
> >> XXXXXXXXXX
> >> ^
> >> | position 0 in buffer
> >> 
> >> (setq my-overlay (make-overlay 0 10))
> >> (get-buffer-window (overlay-buffer my-overlay))
> >> (overlay-put my-overlay 'display "Hello") then I get:
> >> 
> >> HelloX 
> >> 
> >> instead of "Hello"
> >> 
> >> Is this normal behavior?
> >
> > Yes.  The 10 part says that the overlay _ends_ before position 10.
> > This is standard Emacs behavior with text properties and overlays: END
> > means the first character NOT affected by the property/overlay.
> 
> Somewhat related: https://fhur.me/posts/always-use-closed-open-intervals
> (not my piece, just found it on the internet; also I do not want to
> imply the OP doesn't know/understand that - but I consider this short
> article interesting & worthwhile also for others reading this).

I did not put attention, and can't, because the advise is partially
helpful for me to think of similar issues in future, but not to
discover similar issues in past.

We have in Lisp functions like:

(elt '(1 2 3) 0) ➜ 1
(nth 0 '(1 2 3)) ➜ 1
(nth 1 '(1 2 3)) ➜ 2

then for that reason I always think that first char in buffer is 0 and
not 1, and to be conclusive then I use (goto-char (point-min)) because
I never inspected multiple times (point-min) ➜ 1, aha, now I get it.

If the function `make-list' makes 3 elements:

(make-list 3 1) ➜ (1 1 1)

then I want first element be designated as `1' representng "1st" or
"first", but first is second element. It does not give me feeling of
consistency.

(nth 1 '(1 2 3)) ➜ 2

Things already programmed one has to inspect and determine what is
going on.

k
-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/