[Top][All Lists]

[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

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


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 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]