[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked
From: |
Eli Zaretskii |
Subject: |
bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing. |
Date: |
Sat, 01 Apr 2023 18:09:41 +0300 |
> Date: Sat, 01 Apr 2023 14:26:50 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca
>
> > . I'm not sure I'm happy about calling find_newline in a loop where
> > previous code just made a trivial calculation. Imagine a buffer with a
> > lot of short lines. What problem exactly is being solved here, and how
> > does this change solve it?
> >
>
> The point is to find the buffer position of BOL. But you're right, there
> is a missed optimization here, which I just added (also in dce08cf05c).
> Now the code searches for that position in [pos-500..pos],
> [pos-5500..pos-500], [pos-55500..pos-5500], [pos-555500..pos-55500], in
> that order, and buffers with lots of short lines (or more precisely:
> buffers with lots of short lines _and_ one or more long lines) are not
> negatively affected by that code anymore.
OK, but still: why do you need to find the buffer position at BOL, and
how is that related to cursor movement?
> > . Why such a strange method of finding out whether we are on a TTY
> > frame? The usual method is FRAME_WINDOW_P (XFRAME (w->frame)).
> >
>
> That's what I've been using since that function was introduced six months
> ago or so. I admit I don't remember why that's what I chose. If you tell
> me that using FRAME_WINDOW_P (XFRAME (w->frame)) has the same effect as
> terminal-live-p == t (and indeed after looking at the code ISTM that
> that's the case), I'll replace that.
FRAME_WINDOW_P is what we use all over the place, so it must be
correct.
> > . The continuation glyph can be present not only on TTY frames, but also
> > on GUI frames when one or both of the fringes are disabled, so the test
> > needs to be augmented. I think you need to use WINDOW_LEFT_FRINGE_WIDTH
> > and WINDOW_RIGHT_FRINGE_WIDTH.
> >
>
> Thanks, I did not realize that. I just did that (again in dce08cf05c),
> but I'm not sure how WINDOW_LEFT_FRINGE_WIDTH should be used. Using
> WINDOW_RIGHT_FRINGE_WIDTH seems enough, but I'm probably missing
> something.
You are missing the case of R2L paragraphs, where the continuation
glyph is displayed on the left.
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Eli Zaretskii, 2023/04/01
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Eli Zaretskii, 2023/04/01
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Gregory Heytings, 2023/04/01
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.,
Eli Zaretskii <=
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Gregory Heytings, 2023/04/01
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Eli Zaretskii, 2023/04/01
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Gregory Heytings, 2023/04/01
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Eli Zaretskii, 2023/04/01
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Gregory Heytings, 2023/04/01
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Eli Zaretskii, 2023/04/02
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Richard Stallman, 2023/04/03
- bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing., Eli Zaretskii, 2023/04/04