unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Cursor positioning with `after-string' overlays
Date: Fri, 02 Apr 2010 11:16:42 +0300	[thread overview]
Message-ID: <83ljd6w9p1.fsf@gnu.org> (raw)
In-Reply-To: <jwvd3yiq1l5.fsf-monnier+emacs@gnu.org>

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 01 Apr 2010 18:06:26 -0400
> Cc: emacs-devel@gnu.org
> 
> > found.  IOW, exact match wins over all other considerations.  Since
> > C-f from the second `o' moves point to buffer position to which `b'
> > corresponds exactly, that is where the trunk version puts the cursor.
> 
> But depending on the insertion-type of the end marker of your overlay,
> text inserted "at point" will be inserted (visually) between the o and
> the - rather than between the - and the b, so while this choice would
> sometimes be correct, it's sometimes incorrect.

Sorry, I don't understand the specific situation.  In my example, when
the cursor is on `b', insertion happens between `-' and `b', which is
visually correct.  Can you modify my example to create the situation
you are describing?  Then I could try to reason about it and perhaps
modify the code if necessary.

In any case, do you really think that being unable to put the cursor
on `b' (with the old code) is correct behavior?  The `after-string'
does not replace `b' on the screen and doesn't cover its position, so
this behavior looks like a subtle bug, since `b' comes from the
buffer.

> That's why we have the
> `cursor' property (although admittedly, for this particular use, the
> insertion-type of the marker should already provide the needed info).

What do you mean by ``the insertion-type of the marker''?  I've seen
your comments in minibuffer.el about something similar, so perhaps now
is the time to add whatever features you thought were absent.

> One use case is when you simply want to control where the cursor is
> displayed on a piece of text that's not in the buffer (typically an
> after-string).  In such a case, without any extra information, it would
> not be incorrect to place the cursor before the after-string, or after
> the after-string or anywhere in between.  So the `cursor' property
> allows to specify the intended behavior (e.g. the after-string has the
> form "()" and you want the cursor to appear in between the two parens).

This may make sense when the string is displayed _instead_ of some
portion of the buffer, or perhaps when we have a single buffer
position that uses up several columns on display, like in Kim's
example with a TAB in Cua Mode.

But if you type C-f, which moves point to the next buffer position,
and the glyph produced from that buffer position is displayed on the
screen, how can it be TRT not to place the cursor on that glyph?

> The other use case is when the cursor positioning code gets it wrong
> because it works at too low a level (typically the after-string or
> similar thingy is on an overlay with carefully chosen stickiness which
> should make it clear whether the cursor should come before or after the
> string, but the cursor positioning code only gets to see a "flattened"
> representation of the text, so it can't know the stickiness property).

I think this kind of problems should be fixed, not worked around with
the `cursor' property.  The cursor-positioning code does not work only
on glyphs, it does search the buffer for `display' properties and
overlays, so whatever information is available in the buffer, the
cursor-positioning code can get at it.




  reply	other threads:[~2010-04-02  8:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-01 13:15 Cursor positioning with `after-string' overlays Eli Zaretskii
2010-04-01 21:54 ` Kim F. Storm
2010-04-02  7:53   ` Eli Zaretskii
2010-04-02  8:54     ` Eli Zaretskii
2010-04-02 10:24       ` Kim F. Storm
2010-04-01 22:06 ` Stefan Monnier
2010-04-02  8:16   ` Eli Zaretskii [this message]
2010-04-02 18:17     ` Stefan Monnier
2010-04-02 18:38       ` Eli Zaretskii
2010-04-02 20:35         ` Stefan Monnier
2010-04-02 21:16           ` Eli Zaretskii
2010-04-03  1:21             ` Stefan Monnier
2010-04-03  7:26               ` Eli Zaretskii
2010-04-03  7:30               ` redisplay code is ugly (was: Cursor positioning with `after-string' overlays) Eli Zaretskii
2010-04-03 10:42               ` Cursor positioning with `after-string' overlays Eli Zaretskii
2010-04-03 10:28       ` Eli Zaretskii

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83ljd6w9p1.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).