Re: .substring bug - indicies don't work as documented(?)

[Ralph Corderoy]

Hi Werner,

> >     % python
> >     >>> s = 'abcdefg'
> >     >>> s[1]
> >     'b'
> >     >>> s[1:1]
> >     ''
> >     >>> s[1:2]
> >     'b'
> >     >>> s[0:2]
> >     'ab'
> >     >>> s[-2]
> >     'f'
> >     >>> s[-2:]
> >     'fg'
> 
> Emacs Lisp's `substring' command behaves identically.  I'm more and
> more convinced that it is a good idea to make groff's .substring
> request work similar.
> 
> While this is an incompatible change, it is an improvement IMHO.  Any
> objections?

No objection to changing it from here, but I'm not sure what it would
be changed to.  Is it

    n1          Equivalent to n1 n1+1
    n1 n1       Empty string
    n1 n2       String between positions n1 and n2

It was David Hanson who I was trying to think of earlier.  In _C
Interfaces and Implementations_, section 15.1, he explains the
reasoning behind

        1   2   3   4   5   6   7   8   9  10
        | I | n | t | e | r | f | a | c | e |
       -9  -8  -7  -6  -5  -4  -3  -2  -1   0

which matches Griswold's Icon programming language, and Hanson had a
hand in that.

Since the book is about C routines, Hanson didn't have to define the
case of omitting n2, however Icon treats it as (n1, n1+1) giving a
single character.

Python does something similar to above but starts from zero at the
left, like C.

        0   1   2   3   4   5   6   7   8   9
        | I | n | t | e | r | f | a | c | e |
      -10  -9  -8  -7  -6  -5  -4  -3  -2  -1

That's because Python treats s[p], s[p:], and s[p:q] all differently
whereas troff doesn't have the colon to give significance.  Without
s[p:] you'd have to write s[p:-1] unless the string length is known and
that looks ugly;  s[p:0] seems better.

So I'd prefer Icon's arrangement, but I don't know what Emacs does.

Cheers,


Ralph.