all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: 9254-done@debbugs.gnu.org
Subject: bug#9254: previous-line stays put, and next-line crashes
Date: Sat, 06 Aug 2011 14:15:38 +0300	[thread overview]
Message-ID: <83fwlex02t.fsf@gnu.org> (raw)
In-Reply-To: <jwvaabnx5ai.fsf@iro.umontreal.ca>

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> 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	other threads:[~2011-08-06 11:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-05 15:10 bug#9254: previous-line stays put, and next-line crashes Stefan Monnier
2011-08-06 11:15 ` Eli Zaretskii [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83fwlex02t.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=9254-done@debbugs.gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.