[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: window-configurations and marks
From: |
Andreas Röhler |
Subject: |
Re: window-configurations and marks |
Date: |
Sat, 26 Apr 2014 14:13:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.4.0 |
On 24.04.2014 15:15, Stefan Monnier wrote:
A lot of code assumes that "mark-active non-nil implies that (mark)
points somewhere", and I think it's a reasonable assumption.
But occasionally this property is invalid. One place I found where
it can be invalidated is in set-window-configuration because
window-configurations keep a copy of the mark, which is hence reset by
set-window-configuration without paying attention to its connection to
mark-active.
I just installed a patch which changes set-window-configuration so as to
call deactivate-mark when mark-active is non-nil and we set the mark to
point nowhere. But I don't like this patch:
- I don't like to idea of running arbitrary Elisp code from the middle of
set-window-configuration.
- It calls for calling activate-mark in the reverse case.
- It's done "per-window" whereas the mark is "per-buffer".
So, I'm really thinking that the better fix is to change
set-window-configuration such that it does not touch the mark (which
really doesn't have anything to do with windows or
window-configurations, and indeed window-state doesn't include
information about the mark).
Any objection?
Stefan
Hi Stefan,
can't object at this point, as IMO the basics are confused to such an extend,
these and other quirks are to expect.
Remember related matter being discussed around "interactive-p".
Best way is to clean up the core-functions.
For example have a look at "mark". Its docstring says:
"Return this buffer's mark value as integer, or nil if never set.
In Transient Mark mode, this function signals an error if
the mark is not active. However, if `mark-even-if-inactive' is non-nil,
or the argument FORCE is non-nil, it disregards whether the mark
is active, and returns an integer or nil in the usual way."
IMO only the first line/feature is reasonable.
The remaining stuff belongs to commands making use of it, not here - nil or
point is all needed.
Just an example. Cleaning that stuff up would save a lot of time and bugs later
on.
Cheers,
Andreas