From: Eli Zaretskii <eliz@gnu.org>
To: Phil Sainty <psainty@orcon.net.nz>
Cc: 21533@debbugs.gnu.org
Subject: bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width
Date: Tue, 22 Sep 2015 19:57:23 +0300 [thread overview]
Message-ID: <83y4fyl7d8.fsf@gnu.org> (raw)
In-Reply-To: <560165C5.2020904@orcon.net.nz>
> Date: Wed, 23 Sep 2015 02:29:25 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
>
> I can't tell whether this is expected behaviour or not?
>
> Starting from emacs -Q, in the *scratch* buffer, I get the following
> results from evaluating these forms with C-j:
>
> (progn (insert (propertize " " 'display '(space :width 2)))
> (current-column))
> 2
>
> (progn (insert (propertize " " 'display '(space :relative-width 2)))
> (current-column))
> 1
>
> Which is to say that a specified space of :width 2 occupies 2 columns,
> while a specified space of :relative-width 2 occupies only 1 column.
Simply put, current-column did not support :relative-width. Now it
does, so your example should work as expected with the development
sources.
But beware: current-column is not guaranteed to always produce the
exact results you'd expect on GUI displays when wider-than-normal
characters are involved. That's because character width in column
units is always an integer: 0, 1, or 2, whereas the actual pixel width
of those characters depends on the font and is in general not an
integral multiple of the "normal character width". For example, try
your test case with the (double-width) character ᄀ instead of the
space. Or try ^A (Ctrl-A).
If you want accurate screen coordinates, use pixel coordinates
returned by functions like posn-at-point instead. You can convert the
pixel coordinates into units of canonical character width
(a.k.a. "columns") if you divide the pixel coordinates by the value
returned by the function default-font-width.
Also note that :relative-width is only supported on GUI frames. The
documentation omitted this crucial fact; I fixed that as well.
> (What I'm actually *doing* is scaling indentation, and so if the column
> numbers vary with the scaling, then re-indenting the buffer causes
> changes; and I want the effect to be purely visual.)
If you only ever need to scale TAB and SPC characters, then the above
restrictions don't apply, I think. But it is still useful to keep
them in mind.
next prev parent reply other threads:[~2015-09-22 16:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 14:29 bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width Phil Sainty
2015-09-22 16:57 ` Eli Zaretskii [this message]
2015-09-23 12:32 ` Phil Sainty
2015-09-23 12:57 ` 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=83y4fyl7d8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=21533@debbugs.gnu.org \
--cc=psainty@orcon.net.nz \
/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).