From: Drew Adams <drew.adams@oracle.com>
To: npostavs@users.sourceforge.net
Cc: 25777@debbugs.gnu.org
Subject: bug#25777: 25.1; [PATCH] `rectangle--pos-cols' should not move point
Date: Fri, 3 Mar 2017 08:44:26 -0800 (PST) [thread overview]
Message-ID: <2b01eb6e-53b3-4ca1-abe9-ef3090981863@default> (raw)
In-Reply-To: <87zih2a3qg.fsf@users.sourceforge.net>
> >> And looking at the function body again, I think it's checking some other
> >> things, and seems to have some side effects with respect to the current
> >> rectangle.
> >
> > No, I don't think so. What did you have in mind? It can
> > reset window parameter `rectangle--point-crutches' or variable
> > `rectangle--mark-crutches', but I don't think those actions are
> > worth mentioning. Do you?
>
> I thought they might be important. I'm not really sure what the
> user-visible effect of those are though.
AFAICT, those make use of recorded "crutches" (which are
nowhere described explicitly, but which apparently associate
a buffer position with a display column). And that, for a
given window.
They seem important for proper handling of a rectangle
regarded with respect to display (columns are a display
thing in this context).
Put differently, and comparing the code and doc for Emacs 25
with previous releases, it seems that Emacs 25 started
treating rectangles, in at least some cases, wrt _display_
and not just buffer position: respect of wide chars, window,
places past eol, overlay, redisplay highlighting, even bidi
to some extent, etc. The Emacs 25 NEWS says:
Rectangle Mark mode can have corners past EOL or in the
middle of a TAB. 'C-x C-x' in 'rectangle-mark-mode' now
cycles through the four corners. 'string-rectangle'
provides on-the-fly preview of the result.
This seems to be an ongoing initiative (see the code comments,
including for `rectangle--*-char'). We can perhaps expect
even more treatment of a "rectangle" wrt its display.
> But perhaps if you're not interested in them, we should just
> add a function that does only what you want?
>
> (defun rectangle-columns (start end)...
That handles a rectangle in the older sense, but not, I
guess, wrt the new concerns that Emacs 25 starts to address
(display characteristics and needs - see above).
I am really no expert on this. Perhaps the author of the
Emacs 25 rectangle code could weigh in on it. My suggestion
would be to stick to the code as is, since it is the way it
is in order to handle rectangle display better.
Sure, the housekeeping code it includes that deals with
the "crutches" might not be needed to return columns in
most cases. But it is apparently needed in some cases.
Columns do need to take wide chars etc. into account.
In any case, this code is used in the context of other
rect.el code, where that housekeeping seems to play a role.
I'd opt for keeping the display/housekeeping code, since
the more complex code and the use cases that it handles
subsumes the simpler use case that you propose. You can
use it wrt rectangle appearance generally, including the
rectangular region in a particular window.
The use case I have, in `modeline-posn.el', is about the
rectangular region. It tries to report on displayed
columns, not buffer positions. So I think that for my
use case, at least, I need the full-blown
`rectangle--pos-cols' code (under whatever name).
Now, you will say that `current-column' also claims to
DTRT wrt display, taking into account "widths of all the
displayed representations of the character...". I don't
understand this stuff well enough to say why so much more
code apparatus (crutches, a window parameter) is needed
for the Emacs 25 support of rectangles. Partly out of
concern for my ignorance I'd opt to not try to simplify
this.
Just one opinion, and quite uninformed in this case.
Enlightenment welcome.
next prev parent reply other threads:[~2017-03-03 16:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 17:51 bug#25777: 25.1; [PATCH] `rectangle--pos-cols' should not move point Drew Adams
2017-02-19 17:38 ` Drew Adams
2017-02-27 1:37 ` npostavs
2017-02-27 6:24 ` Drew Adams
2017-02-27 13:44 ` npostavs
2017-02-27 17:51 ` Drew Adams
2017-02-27 18:50 ` Noam Postavsky
2017-02-27 19:21 ` Drew Adams
2017-02-27 19:47 ` Noam Postavsky
2017-02-27 20:35 ` Drew Adams
2017-02-28 4:57 ` npostavs
2017-02-28 15:11 ` Drew Adams
2017-03-02 1:21 ` npostavs
2017-03-02 2:32 ` Drew Adams
2017-03-02 18:13 ` Drew Adams
2017-03-03 2:09 ` npostavs
2017-03-03 6:29 ` Drew Adams
2017-03-03 13:28 ` npostavs
2017-03-03 16:44 ` Drew Adams [this message]
2017-03-03 18:16 ` Noam Postavsky
2017-03-03 19:17 ` Drew Adams
2019-06-24 17:10 ` Lars Ingebrigtsen
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=2b01eb6e-53b3-4ca1-abe9-ef3090981863@default \
--to=drew.adams@oracle.com \
--cc=25777@debbugs.gnu.org \
--cc=npostavs@users.sourceforge.net \
/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).