From: Dmitry Gutov <dgutov@yandex.ru>
To: 18385@debbugs.gnu.org
Subject: bug#18385: 24.3.93; posn-at-point doesn't account for tab-width
Date: Wed, 03 Sep 2014 03:30:10 +0400 [thread overview]
Message-ID: <86ha0plhx9.fsf@yandex.ru> (raw)
In-Reply-To: <83k35mf3kz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Sep 2014 18:24:12 +0300")
Hi Eli,
Thanks for the detailed explanation.
Eli Zaretskii <eliz@gnu.org> writes:
> "Character number in that row". IOW, it counts characters, not visual
> columns. This function, and the data in its POSITION argument which
> it accesses, are designed to make it easy to find the glyph (or
> "display element") in a screen line, so it simply provides the ordinal
> number of the "thing at point" on its screen line, disregarding the
> screen dimensions of that thing.
Okay, if character widths are "applied" after the glyphs to be displayed
are collected, I guess this makes a certain amount of sense.
Is this value useful, though? Since the visual buffer contents are
inaccessible from Lisp, I believe this value wouldn't be properly
correct in most contexts, even in tty, where the major pitfalls you
described can't happen.
AFAICS, this function is only called in two places in Emacs code:
- From `line-move-partial', where I don't understand what it does.
- From `proced-sort-header', where the caller apparently just assumes
there are no multiple-width characters on that line.
So, was the decision not to return current-column-like value made due to
performance considerations?
> And you were right to resolve that by using posn-col-row instead.
> That function translates pixel coordinates into row/column units,
> which is much closer to what you want.
Thanks, that's good to know.
next prev parent reply other threads:[~2014-09-02 23:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-01 21:53 bug#18385: 24.3.93; posn-at-point doesn't account for tab-width Dmitry
2014-09-02 15:24 ` Eli Zaretskii
2014-09-02 23:30 ` Dmitry Gutov [this message]
2014-09-03 16:12 ` Eli Zaretskii
2014-09-03 22:10 ` Dmitry Gutov
2014-09-04 15:23 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ha0plhx9.fsf@yandex.ru \
--to=dgutov@yandex.ru \
--cc=18385@debbugs.gnu.org \
/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.