GNU bug report logs -
#56393
Actually fix the long lines display bug
Previous Next
Full log
Message #260 received at 56393 <at> debbugs.gnu.org (full text, mbox):
>
> Thanks. A few comments to what I see on the branch (apologies if these
> are premature because you are still working on the code):
>
I am not, as far as I see the code is in a near-final state, except that I
will of course try to take your (and other's) comments into account.
>
> . init_iterator is also called to display strings, and I'm not sure I
> understand what you intended to do in that case, since BEGV/ZV are not
> relevant to strings.
>
I guess moving the calculation of the restriction into start_display
should fix that problem. Then it->narrowed_begv will be 0 for strings.
>
> . The WITH_NARROWED_BEGV macro is IMO awkward and not very convenient to
> use in C. For starters, it cannot accommodate multi-line code, except
> via the 'do { ... } while(0);' kludge, which I think will make the code
> less readable. It also should set up an unwind-protect handler, so that
> any non-local exit from the code will restore BEGV/ZV. So I think it
> will be better to have two separate functions (and a third one to
> unwind).
>
Hmmm... I'll see what I can do. (But I don't understand why you write
that it cannot accomodate multi-line code: you can write
"WITH_NARROWED_BEGV (frobnicate (foo); frobnicate (bar));".)
>
> . You currently only apply the "restriction" in a few places where the
> code calls functions like find_newline_no_quit. What about the rest of
> display code -- are you saying that it doesn't need to be "restricted"?
> or do you intend to add that in the future?
>
Yes, that's what I'm saying. You asked me to make sure that the
restriction would have the least possible impact, which I did.
>
> And what about restricting the Lisp code invoked via
> Vfontification_functions (i.e. jit-lock.el)?
>
That would mean that some Lisp code would not have access to the entire
buffer, which you wanted to avoid.
>
> . Don't we want to "restrict" ZV as well?
>
It's not necessary, no. Doing so has no performance impact AFAICS.
>
> . I'm not sure the "restriction" should be computed relative to point:
> that might be OK for redisplaying a window, but for commands that use
> the display code the position with which we call init_iterator and
> start_display might be a better/safer alternative, because that position
> could be very far from point. In any case, get_narrowed_begv receives a
> pointer to a window, so I think it should use the window-point, not PT,
> which is the value of point in the current buffer.
>
Okay, I'll do that.
>
> . The 10000 number should at least be a C macro if not a variable
> exposed to Lisp.
>
Okay.
>
> . The maximum number of characters in a window could be more than just
> its width multiplied by its height, because the window could use smaller
> fonts than the default. I think it is safer to use the dimensions of
> the window's glyph matrix for this, because there couldn't possibly be
> more characters in the window than the glyph matrix allows, and we
> always resize the matrix when we need to display more characters.
>
Okay.
This bug report was last modified 3 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.