bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#9254: previous-line stays put, and next-line crashes


From: Eli Zaretskii
Subject: bug#9254: previous-line stays put, and next-line crashes
Date: Sat, 06 Aug 2011 14:15:38 +0300

> From: Stefan Monnier <address@hidden>
> Date: Fri, 05 Aug 2011 11:10:45 -0400
> 
> Not sure if the two are related

They weren't.

>    % emacs -Q ~/tmp/foo.ll
>    [ accept the file-local settings ]
>    M->
>    C-p C-p C-p
> 
> I notice 3 problems:
> - After the first C-p the cursor is drawn on the second "\n" of the
>   "¶\n\n" display property.  In Emacs-23, the cursor was drawn on the
>   "¶".  Not sure if it's longlines-mode which should add a `cursor'
>   property, but at least that's a change in behavior w.r.t Emacs-23.
> - On the second (and third) C-p, the cursor fails to move.
>   AFAICT this bug was already present in Emacs-23.
> - If I then hit C-n, I get a crash with the backtrace appended after
>   my sig.  I.e. bidi_cache_start is zero upon entry to bidi_pop_it.

The crash was caused by a stupid thinko; fixed in revision 105413.

I also fixed in that revision the first of the 3 problems, because the
cursor position was different from Emacs 23 even with
bidi-display-reordering set to nil.  Hopefully, I didn't introduce any
new bugs in cursor positioning by this change.

As for the second problem you mention, please file a separate bug
report, as anything that isn't a regression from Emacs 23 should be
separate anyway, and in any case its priority on my todo is lower than
bidi-related problems.  I'm closing this bug report.

In general, yes, I think modes that use display strings should use the
`cursor' property much more now, instead of relying on the display
engine to figure this out.  The bidi-aware display needs much more
help in this regard because it cannot rely on monotonicity of
character position changes with screen positions.  This monotonicity
in the unidirectional display was the main reason why all kinds of
tricky cases "just worked" in Emacs 23.  There's a limit to the amount
of logic and flags we can put into the code to implement heuristics
whose sole basis is that "it worked like that in Emacs 23".






reply via email to

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