init_iterator takes window

init_iterator takes window

[Thien-Thi Nguyen]

rms,

per your suggestion, i have looked into using an iterator as a basis for
a current-column computation in the presence of variable-width fonts.  i
see that init_iterator takes a `struct window *' as its second arg and
from xdisp.c:1519 that this cannot be NULL.

is it possible for there to be two different windows open on the same
text with different display behaviors?  if so, which window to choose?
even if not, i'm confused about how to choose a window to to pass to
init_iterator; might there be a legitimate call to current-column where
there is no window available?

any clues appreciated.

thi

Re: init_iterator takes window

[Stefan Monnier]

> is it possible for there to be two different windows open on the same
> text with different display behaviors?

Very much so.  The same buffer can be displayed in two different
windows in two different frames and since faces can be changed on
a frame-by-frame basis, the appearance can be changed significantly.

Of course, the fact that overlays can be made window-specific as well
means that the appearance can also change between two windows even
in the same frame.


	Stefan

Re: init_iterator takes window

[Thien-Thi Nguyen]

   appearance can also change between two windows even
   in the same frame.

so there is a semantic gap between current `current-column' and one that
would take into account variable-width fonts, implying `current-column'
callers need to bifurcate their usage to call some "window-current-column"
if they care about variable-width fonts, and `current-column' otherwise.

alternatively, we can add an "&optional window" arg to `current-column',
which if a window would mean take variable-width fonts into account (using
that window), if t would mean look for some default window and use that,
and otherwise fall back to using the existing computation methods, w/o
taking any font info into account.

depending on how we support `(current-column t)', two callers may get
different return values.  it might be a good idea to delay this support
until after we vet the callers, to see what idioms are most useful to
abstract.

to rms: could you define precisely what is meant by "upward compatibility"
wrt `current-column' *usage*?  to fulfill that goal i need to understand
the concept fully, including from caller perspective.

thi

Re: init_iterator takes window

[Stefan Monnier]

>    appearance can also change between two windows even
>    in the same frame.
> 
> so there is a semantic gap between current `current-column' and one that
> would take into account variable-width fonts, implying `current-column'
> callers need to bifurcate their usage to call some "window-current-column"
> if they care about variable-width fonts, and `current-column' otherwise.

The problem is not specific to variable-width fonts.
Even in Emacs-20 the `current-column' depends on the window
because of window-specific overlays that might make some part
of the buffer invisible in one window but not in another.

And the problem is not only with `current-column' but also
with how we use the result.  If we then use it to align to
pieces of text, they might be aligned in one window but not
in another.


	Stefan

PS: I don't see why `current-column' needs an extra `window' argument.
    What's wrong with using the currently selected window ?

Re: init_iterator takes window

[Thien-Thi Nguyen]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

   The problem is not specific to variable-width fonts.

true.

   And the problem is not only with `current-column' but also
   with how we use the result.  If we then use it to align to
   pieces of text, they might be aligned in one window but not
   in another.

yes, this is the real problem, AFAICS.

   PS: I don't see why `current-column' needs an extra `window' argument.
       What's wrong with using the currently selected window ?

you're right.  it doesn't.  i retract that proposal, now realizing that
selected window sensitivity is already supported.  i'll use selected window
for the iterator.

thi

Re: init_iterator takes window

[Richard Stallman]

    is it possible for there to be two different windows open on the same
    text with different display behaviors?  if so, which window to choose?

Yes, there can be--any buffer can be displayed in multiple windows.
You should simply use the selected window.  That is simple, and
probably right.

    even if not, i'm confused about how to choose a window to to pass to
    init_iterator; might there be a legitimate call to current-column where
    there is no window available?

I believe Emacs always must have a selected window.

Re: init_iterator takes window

[Richard Stallman]

       appearance can also change between two windows even
       in the same frame.

    so there is a semantic gap between current `current-column' and one that
    would take into account variable-width fonts, implying `current-column'
    callers need to bifurcate their usage to call some "window-current-column"
    if they care about variable-width fonts, and `current-column' otherwise.

current-column is not affected at present by the selected window, and
that may be a good thing--but it is not a crucial design requirement.
It was easy to do this, because current-column at present does not
crucially need any data from the selected window.

With the changes for variable width, it would make sense to
get all this info from the selected window.

    Even in Emacs-20 the `current-column' depends on the window
    because of window-specific overlays that might make some part
    of the buffer invisible in one window but not in another.

Actually it seems to ignore those overlays, because it calls
skip_invisible with Qnil for the WINDOW arg.

    to rms: could you define precisely what is meant by "upward compatibility"
    wrt `current-column' *usage*?  to fulfill that goal i need to understand
    the concept fully, including from caller perspective.

Upward compatibility means, here, that existing user programs that
call current-column and other primitives should DTRT (as much as
possible) in cases with variable width fonts, when they use the new
version of current-column that handles variable width.  Clearly we
can't make all of these programs DTRT just by changing current-column
and other primitives.  The point is that the proper way to change the
primitives is the way that achieves the largest portion of that goal.

It may be that it would be desirable to have a form of current-column
that assumes fixed-width, as well as the new one that calculates based
on variable width fonts.  After your new version is working, we will
see if that is needed.