GNU bug report logs - #25777
25.1; [PATCH] `rectangle--pos-cols' should not move point

Previous Next

Full log

Message #59 received at 25777 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: npostavs <at> users.sourceforge.net
Cc: 25777 <at> debbugs.gnu.org
Subject: RE: bug#25777: 25.1; [PATCH] `rectangle--pos-cols' should not move
 point
Date: Fri, 3 Mar 2017 08:44:26 -0800 (PST)

> >> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.