problem of marker as position

problem of marker as position

[Kenichi Handa]

I've just noticed that (char-after MARKER) returns a
character in the current buffer even if the buffer of MARKER
is the different one.  I think all such functions that
accept a marker as a position ignores the buffer infomation
of the marker.

It seems that Emacs treats markes as above from the
beginning, so this should be regarded as a feature, not a
bug.  But I could't find a place describing that in info.

lispref/markers.texi has this paragraph.

  A marker specifies a buffer and a position in that buffer.  The marker
can be used to represent a position in the functions that require one,
just as an integer could be used.  @xref{Positions}, for a complete
description of positions.

Shouldn't we say something about the above feature here?

---
Ken'ichi HANDA
handa@m17n.org

Re: problem of marker as position

[Luc Teirlinck]

Ken'ichi Handa wrote:

   I've just noticed that (char-after MARKER) returns a
   character in the current buffer even if the buffer of MARKER
   is the different one.  I think all such functions that
   accept a marker as a position ignores the buffer infomation
   of the marker.

To me that is exactly what is _meant_ by using a marker "as a
position".  A function could also accept a marker "as a buffer", by
ignoring the position, or "truly as a marker", by using both.  It
would seem to me that any function is free to allow both an integer
and a marker as an argument and nevertheless use the marker as a
marker, that is, buffer and all.  In that case however, it would not
be using the marker as a "substitute" for a position, but as a
genuinely different alternative to a position.  I believe that it is
up to the documentation of the individual function to make that clear.
The documentation string of `char-after' clearly says that it uses the
current buffer no matter what.

That being said, _if_ something needs to be clarified, then I believe
that the best place to do that is (elisp)Positions:

===File ~/pos-diff==========================================
cd ~/emacscvsdir/emacs/lispref/
diff -c /home/teirllm/positions.old.texi /home/teirllm/emacscvsdir/emacs/lispref/positions.texi
*** /home/teirllm/positions.old.texi	Sat Nov  8 22:41:19 2003
--- /home/teirllm/emacscvsdir/emacs/lispref/positions.texi	Tue Nov 18 21:14:12 2003
***************
*** 18,24 ****
    Positions are usually represented as integers starting from 1, but can
  also be represented as @dfn{markers}---special objects that relocate
  automatically when text is inserted or deleted so they stay with the
! surrounding characters.  @xref{Markers}.
  
    See also the ``field'' feature (@pxref{Fields}), which provides
  functions that are used by many cursor-motion commands.
--- 18,28 ----
    Positions are usually represented as integers starting from 1, but can
  also be represented as @dfn{markers}---special objects that relocate
  automatically when text is inserted or deleted so they stay with the
! surrounding characters.  Functions that expect an argument to be a
! position (an integer), but accept a marker as a substitute, normally
! ignore the marker buffer.  Of course, markers used this way usually
! point to a position in the buffer that the function operates on, but
! that is entirely the programmer's responsibility.  @xref{Markers}.
  
    See also the ``field'' feature (@pxref{Fields}), which provides
  functions that are used by many cursor-motion commands.

Diff finished at Tue Nov 18 21:20:02
============================================================

Sincerely,

Luc.

Re: problem of marker as position

[Kenichi Handa]

In article <200311190334.hAJ3Yo402428@raven.dms.auburn.edu>, Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Ken'ichi Handa wrote:
>    I've just noticed that (char-after MARKER) returns a
>    character in the current buffer even if the buffer of MARKER
>    is the different one.  I think all such functions that
>    accept a marker as a position ignores the buffer infomation
>    of the marker.

> To me that is exactly what is _meant_ by using a marker "as a
> position".  A function could also accept a marker "as a buffer", by
> ignoring the position, or "truly as a marker", by using both.

I didn't read this paragraph (int the node Positions) as above.

   Positions are usually represented as integers starting from 1, but
can also be represented as "markers"--special objects that relocate
automatically when text is inserted or deleted so they stay with the
surrounding characters.  See *Note Markers::.

But, as I'm not native English, if your understanding is
natural, I don't insist on adding the extra explanation in
info.

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> Maybe, if this does need clarifying, it might be better to do it in
> (elisp)Overview of Markers instead of (not in addition to) in
> (elisp)Positions, anyway:
[...]
> !   A marker specifies a buffer and a position in that buffer.  The
> ! marker can be used to represent a position in the functions that
> ! require one, just as an integer could be used.  In that case, the
> ! marker's buffer is normally ignored.  Of course, a marker used in this
> ! way usually points to a position in the buffer that the function
> ! operates on, but that is entirely the programmer's responsibility.
> ! @xref{Positions}, for a complete description of positions.
  
I agree.  I'll leave the decision of adding it or not to
your discretion.

---
Ken'ichi HANDA
handa@m17n.org

Re: problem of marker as position

[Robert J. Chassell]

   But, as I'm not native English, if your understanding is
   natural, I don't insist on adding the extra explanation in
   info.

I am a native English speaker and, to my embarrassment, have been
confused.  Extra explanation is useful, since the notion of marker
encompasses two different concepts:

  1. a position within a buffer that relocates automatically when
     text is inserted or deleted, 

  2. a specification of which buffer the position is within.

My problem is that sometimes, I focus on concept # 2 when the person
writing the code focuses on concept # 1 --- I should, of course, focus
on both concepts, but forget.  A better explanation would help me
remember.

The two concepts cannot be separated because the position must be
within a particular buffer.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: problem of marker as position

[Kevin Rodgers]

Robert J. Chassell wrote:

> I am a native English speaker and, to my embarrassment, have been
> confused.  Extra explanation is useful, since the notion of marker
> encompasses two different concepts:
> 
>   1. a position within a buffer that relocates automatically when
>      text is inserted or deleted, 
> 
>   2. a specification of which buffer the position is within.
> 
> My problem is that sometimes, I focus on concept # 2 when the person
> writing the code focuses on concept # 1 --- I should, of course, focus
> on both concepts, but forget.  A better explanation would help me
> remember.
> 
> The two concepts cannot be separated because the position must be
> within a particular buffer.

Indeed.  It would be interesting to add debugging code to marker.c
(analagous to byte_char_debug_check) that would signal an error if any
marker was being used as a position in a different buffer.  If there
aren't too many cases, it'd be simple to convert the references to the
marker M to (marker-position M).  Then the run-time check could be left
in for Lisp programmers, dependent upon a variable (analgous to
byte-debug-flag).

-- 
Kevin Rodgers

Re: problem of marker as position

[Luc Teirlinck]

I added my changes to both the "Positions" and the "Markers" chapter,
because Richard thought that it should be mentioned in both places.

Sincerely,

Luc.

Re: problem of marker as position

[Luc Teirlinck]

Maybe, if this does need clarifying, it might be better to do it in
(elisp)Overview of Markers instead of (not in addition to) in
(elisp)Positions, anyway:


===File ~/markers-diff======================================
cd ~/emacscvsdir/emacs/lispref/
diff -c /home/teirllm/emacscvsdir/emacs/lispref/markers.texi.\~1.16.\~
/home/te\irllm/emacscvsdir/emacs/lispref/markers.texi
*** /home/teirllm/emacscvsdir/emacs/lispref/markers.texi.~1.16.~
Sun Nov\  9 10:34:02 2003
--- /home/teirllm/emacscvsdir/emacs/lispref/markers.texi        Wed
Nov 19 09:2\5:52 2003
***************
*** 28,37 ****
  @node Overview of Markers
  @section Overview of Markers

!   A marker specifies a buffer and a position in that buffer.  The
marker
! can be used to represent a position in the functions that require
one,
! just as an integer could be used.  @xref{Positions}, for a complete
! description of positions.

    A marker has two attributes: the marker position, and the marker
  buffer.  The marker position is an integer that is equivalent (at a
--- 28,40 ----
  @node Overview of Markers
  @section Overview of Markers

!   A marker specifies a buffer and a position in that buffer.  The
! marker can be used to represent a position in the functions that
! require one, just as an integer could be used.  In that case, the
! marker's buffer is normally ignored.  Of course, a marker used in
this
! way usually points to a position in the buffer that the function
! operates on, but that is entirely the programmer's responsibility.
! @xref{Positions}, for a complete description of positions.

    A marker has two attributes: the marker position, and the marker
  buffer.  The marker position is an integer that is equivalent (at a

Diff finished at Wed Nov 19 09:27:24
============================================================

Re: problem of marker as position

[Richard Stallman]

    I've just noticed that (char-after MARKER) returns a
    character in the current buffer even if the buffer of MARKER
    is the different one.  I think all such functions that
    accept a marker as a position ignores the buffer infomation
    of the marker.

Right now, every function that accepts a marker or an integer handles
the marker by converting it to an integer.  For some functions, such
as arithmetic, that's the only thing to do.  But you could argue that
functions that look at a position in a buffer ought to use the
marker's buffer when given a marker.  In some sense, that would be
cleaner.  However, it would also be a big incompatible change.