Re: Pretest begins end-June

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: Chong Yidong <address@hidden>,  address@hidden
> Date: Mon, 30 May 2011 16:20:26 -0300
> 
> >> Stefan and I have decided on the end of June for the beginning of the
> >> Emacs 24.1 pretest.  We're hoping for an early 2012 release, but, as
> >> always, that will depend on the code.
> > That schedule is way too early for the bidi stuff.  There are still 2
> > major jobs I need to do (reordering display strings and support for
> > truncated lines) and one minor one (a couple of bug reports regarding
> > cursor motion around invisible text and before-/after-strings).
> > There's no chance in the world that they will be ready in a month.
> 
> I know it's hard to guess the future, but do you have some approximate
> idea of when we could reasonably expect to get these fixed?

The first part of display string support -- reordering portions of
text covered by display properties -- is already done and tested on my
local branch, I was planning on merging that this week.

The other part -- reordering the strings themselves -- is mostly local
to bidi.c, but also involves some changes in xdisp.c, particularly in
cursor motion and push_it/pop_it.  It's a large job, and will probably
take a month (i.e. 4 to 5 weekends) at least, maybe a little more.
The uncertainty here is significant: this area of the display engine
is notoriously under-documented and full of surprises, so it's
possible I'll need to change the design half way through because I
find out something I'm not aware of now.  It happened before.

Truncated lines will take something like 2 weekends to get to some
reasonably usable state, but that's without the radical changes
requested by Richard here:

  http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00167.html

At the time, you (Stefan) thought that the current "inverted
scrolling" was ``OK for now''.  OTOH, if we want to implement the
"rigid hscroll" that everybody agrees is TRT, we need to discuss the
details here first, because we never did back then.  Whatever the
details, I expect this to be a complete rewrite of the whole hscroll
thing, which reaches deep into the core parts of redisplay.

Bug-fixing could be left for after the pretest starts, because I
expect the pretest to be long, and so enough time to fix the bugs.

So in sum, it sounds like I'll need 6 to 7 weeks from now, barring any
unforeseen obstacles, personal disasters, etc.

Alternatively, we could start the pretest end of June as you plan, but
let me commit these changes as they become ready.  I expect that
turning bidi-display-reordering on for everyone even with today's code
base will expose quite a few bugs that I don't know about, so there's
some sense in doing that even though some features are not yet there.
In the past, a pretest version was supposed to be quite stable, but
maybe nowadays with so many people using the development code, it is
no longer such a significant consideration, if people can tolerate
transient breakage even during pretest.

> Other question: do these affect the behavior of Emacs when
> bidi-reorder-display is non-nil but there's no R2L in sight?

Of course, they do: when bidi-display-reordering is non-nil, the
display engine always goes through bidi.c, it doesn't know that the
result will be a simple linear iteration.  The same goes for cursor
positioning in set_cursor_from_row: the old Emacs 23 vintage code is
simply gone from there, so any bugs there will be acutely visible.
>From the user perspective, the behavior in a plain L2R buffer should
be like in Emacs 23, but that's assuming there are no bugs...

> Maybe we could let bidi-reorder-display be t, while leaving some R2L
> reordering (such as display strings) unimplemented?

I won't recommend that except as the last resort, if it turns out that
the above estimates are way too optimistic, and/or the pretest is
otherwise finished quicker than I think it will be.