[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "... the window start at a meaningless point within a line."

From: Eli Zaretskii
Subject: Re: "... the window start at a meaningless point within a line."
Date: Sun, 01 Nov 2015 19:45:28 +0200

> Date: Sun, 1 Nov 2015 15:23:54 +0000
> Cc: address@hidden
> From: Alan Mackenzie <address@hidden>
> > The patch below should go a long way towards solving these problems.
> > The only issue I left unsolved is exposed when typing C-p on the
> > second screen line of the right-side window: you will see that it
> > doesn't succeed in keeping the visual column.  Solving this is left as
> > an exercise ;-)
> ;-).  Sometimes it doesn't even go to the right line (i.e. when there
> are more or fewer "actual" lines than "xdisp" lines).

The code is explicitly unfinished, I said that much.  I wrote it in
the hope that it will show enough to get you off the ground with using
the move_it_* functions for the purposes such as this.  But it
definitely needs more work.

> To detect this situation necessarily involves reseat_at_window_start
> followed by moving forward, counting (display) line starts, in some
> fashion.  Do you agree?

I don't know if I agree.  I don't think I understand the situation
well enough to reason about it.

The problem with the first screen line of a window is the call to
move_it_by_lines with its second argument zero.  The simplest solution
is to eliminate that call, and instead achieve the same effect "by
hand" (if at all necessary).

> To move to the right column of the line necessarily involves knowing
> where the "actual" BOL is.

No, not necessarily.  Moreover, the "actual BOL" will not help you if
it is known as a buffer position (as opposed to its screen horizontal

> At the moment, I can't see how post analysis (i.e. analysis after
> Fvertical_motion has done move_it_by_lines (&it, nlines)) can be
> avoided.

I don't understand the significance of what you want to say here,
sorry.  One of the large changes I made does precisely that, right?

> In this line of thinking, considering how bidi complicates the order of
> PT, end position, and various BOLs, it might be very convenient to
> enhance move_it_in_display_line_to to take TWO (or even several)
> to_charpos parameters, such that the function would stop after reaching
> either one of them.

IME, this kind of reasoning about these problems is not useful, it
leads into a conceptual trap.  The key problem is with the definition
of "reaching".  In the unidirectional display, whenever you see a
buffer position >= goal, you have "reached" the goal.  But this breaks
with bidirectional text, so only strict equality can be meaningfully
tested.  But the exact equality might legitimately be out of our reach
(pun intended), for any number of valid reasons: display properties,
truncated lines, position outside the visible portion of the buffer,
and many others.  So you can never "reach" the goal, but it doesn't
mean you didn't find your spot.  And there are no good solutions to
this conundrum.

Instead of reasoning in terms of buffer positions, you should reason
in terms of screen coordinates.  The move_it_* functions all work in
the visual order, i.e. they traverse the text in the order it would be
displayed, from left to right, screen line after screen line.  If you
think in terms of screen coordinates and horizontal/vertical moves
across screen lines, you can blissfully forget about bidi.

> > I hope the changes I made and the comments to those changes will speak
> > for themselves, and show how to solve such problems.
> I like your idea for solving the "going back over the top of the window"
> problem.  Is there any guarantee that w->prev will actually be the
> window "to the left of" w (whatever that might mean)?

Yes.  See the documentation and the implementation of
window-prev-sibling and window-next-sibling.

> > But in general, I must say that fixing what you are trying to fix
> > is an ambitious undertaking; perhaps it would be better to make
> > sure the two windows are always the same width, using pixel-wise
> > resizing where necessary.
> As already said, this would be sub-optimal for ttys, where the total
> width is fixed, and tends not to be a number of the form 2n+1 or 3n+2.

We could say that on a TTY vertical cursor motion across windows can
create strange artifacts, if a continued line spans the window.  It's
a relatively rare situation, I think.

Or maybe we could arrange for the windows to be scrolled when cursor
approaches the edge, so that a continued line never straddles more
than one window.

Any of these 2 possibilities looks better to me than to fight an
uphill battle against hidden assumptions within the display engine.
The more I think about this, the more it feels like a tip of a giant
iceberg.  Beware!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]