Re: Bidirectional editing in Emacs -- main design decisions

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden
> Date: Sun, 11 Oct 2009 04:41:22 -0400
> 
> move-to-left-margin shows what it means to be at the left margin.
> It is a matter of matching the paragraph regexps after the right
> amount of whitespace as specified by the value of `left-margin'.

Would it be sufficient to account for any arbitrary amount of
horizontal whitespace between the beginning of the line and the
paragraph regexps?  If so, that is an almost trivial modification of
the code I already have.

My problem was with potentially more complicated situations, since
paragraph regexps may in principle be anything.

I also have issues with a paragraph that is separated from the
previous one by just the amount of indentation, like this:

  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
          bbbbbbbbbbbbbbbbbbbbbbbbbbbb
          bbbbbbbbbbbbbbbbbbbbbbbbbbbb

Are you suggesting that Emacs should recompute the paragraph direction
of the two lines with b's, and the result could be a different base
direction from that used by the two preceding lines with a's?  I think
that such direction changes will annoy users of bidirectional scripts.
What are the use-cases where such paragraphs are useful?

> When `left-margin' is nonzero, a line which fails to start with that much
> whitespace also starts a paragraph.

You mean, a line which starts with more indentation, or a line that
starts with less?  Like this:

      aaaaaaaaaaaaaaaaaaaaaa
      aaaaaaaaaaaaaaaaaaaaaa
  xxxxxxxxxxxxxxxxxxxxxxxxxx
      yyyyyyyyyyyyyyyyyyyyyy

Should the "xxx" line be considered a new paragraph?

> To be fully correct, it ought to detect paragraphs correctly when
> `left-margin' is nonzero.  I think that won't be hard to do.

Maybe it will be not hard -- once I make move-to-column,
current-column, and the rest of indent.c work with bidirectional
text.  Right now, it's badly broken, because it assumes buffer
positions increase linearly with screen positions.  Even vertical
cursor motion and C-e does not work correctly, because of that.