window-configurations and marks

window-configurations and marks

[Stefan Monnier]

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

Re: window-configurations and marks

[Andreas Röhler]

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

Re: window-configurations and marks

[Stephen J. Turnbull]

Hi, Andreas!

Andreas Röhler writes:

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

One can argue naming (eg, the current function should be named
`active-mark' and `mark' should just return the mark as an integer or
nil).  However there's good reason for factoring out the behavior
relying on Transient Mark mode, because that is behavior chosen by the
user that should be implemented consistently across mark-using commands.

I personally prefer the spellings `(mark)' and `(mark t)' to
`(active-mark)' and `(mark)', because users who enable t-m-m expect it
to affect all uses of the mark.  Therefore the "easier to write" name
should be used for the function affected by t-m-m.

I agree that `mark-even-if-inactive' is an ugly hack give the FORCE
argument.