include new package wconf.el in GNU ELPA

include new package wconf.el in GNU ELPA

[Ingo Lohmar]

Hi everybody,

I've been using my small single-purpose package wconf.el
https://github.com/ilohmar/wconf for a while now and I am very happy
with it.  The code is all mine and I have signed the FSF papers.  Now I
would like to put it into an elpa for visibility --- is it ok if I
upload it into the GNU elpa (I have commit rights)?

The package does nothing but offer a simple mechanism to switch between
different window configurations of a single frame, and to persist them
across sessions.

If you happen to know/have used workgroups.el, you have a good idea of
what I mean, I also try to summarize it in the github README.  This
package has inspired the basic setup, but it did a whole lot more that I
have no interest in, it had some quirks, and it did not use the window
config facilities of a recent GNU Emacs.

Best,
Ingo

Re: include new package wconf.el in GNU ELPA

[Dmitry Gutov]

Hi Ingo,

On 07/30/2015 06:31 PM, Ingo Lohmar wrote:

> I've been using my small single-purpose package wconf.el
> https://github.com/ilohmar/wconf for a while now and I am very happy
> with it.  The code is all mine and I have signed the FSF papers.  Now I
> would like to put it into an elpa for visibility --- is it ok if I
> upload it into the GNU elpa (I have commit rights)?

I'm sure nobody is going to oppose that. Do you know how to use 'git 
subtree'?

Re: include new package wconf.el in GNU ELPA

[Tassilo Horn]

Ingo Lohmar <i.lohmar@gmail.com> writes:

Hi Ingo,

> I've been using my small single-purpose package wconf.el
> https://github.com/ilohmar/wconf for a while now and I am very happy
> with it.  The code is all mine and I have signed the FSF papers.  Now
> I would like to put it into an elpa for visibility --- is it ok if I
> upload it into the GNU elpa (I have commit rights)?

Then I think all prerequisites are set.

> The package does nothing but offer a simple mechanism to switch
> between different window configurations of a single frame, and to
> persist them across sessions.

Looks simple and useful.  I'll try it out when I find some spare time.
I seldomly use window configurations mainly because I don't like that
window configs also restore point and selected window.  Basically, I'd
prefer that when I restore a window config, the point values stay as
they are for all the buffers which are part of the current window config
and the one I'm switching to.  Likewise, I'd like to have the window
selected which displays the same buffer as the selected window in the
current window config in case the window config I'm switching to also
has a window displaying that buffer.  Does wconf have a knob for that?
(If not and you add one, you have a new user for sure. :-))

One comment on the code: I dislike the practice of having a normal
package name and then use an abbreviated prefix in the actual code.
wconf is a short name anyway, so IMHO there is no benefit of defining
the functions and variables with the abbreviated wc- prefix instead of
wconf-.  But there is the obvious downside of likely clashes with
private stuff from users with the initials WC.  So I'd suggest to change
that before it pops up in the package list and people start using,
configuring, and extending it.

A similar thing applies to the file where window configs are stored
which is currently window-configs.el.  I'd rather go with something
which makes the connection to your package completely obvious, e.g.,
wconf-window-configs.el.

Bye,
Tassilo

Re: include new package wconf.el in GNU ELPA

[Ingo Lohmar]

On Thu, Jul 30 2015 21:17 (+0200), Tassilo Horn wrote:

> Ingo Lohmar <i.lohmar@gmail.com> writes:
>
> Hi Ingo,
>
>> I've been using my small single-purpose package wconf.el
>> https://github.com/ilohmar/wconf for a while now and I am very happy
>> with it.  The code is all mine and I have signed the FSF papers.  Now
>> I would like to put it into an elpa for visibility --- is it ok if I
>> upload it into the GNU elpa (I have commit rights)?
>
> Then I think all prerequisites are set.
>
>> The package does nothing but offer a simple mechanism to switch
>> between different window configurations of a single frame, and to
>> persist them across sessions.
>
> Looks simple and useful.  I'll try it out when I find some spare time.
> I seldomly use window configurations mainly because I don't like that
> window configs also restore point and selected window.  Basically, I'd
> prefer that when I restore a window config, the point values stay as
> they are for all the buffers which are part of the current window config
> and the one I'm switching to.  Likewise, I'd like to have the window
> selected which displays the same buffer as the selected window in the
> current window config in case the window config I'm switching to also
> has a window displaying that buffer.  Does wconf have a knob for that?
> (If not and you add one, you have a new user for sure. :-))
>
> One comment on the code: I dislike the practice of having a normal
> package name and then use an abbreviated prefix in the actual code.
> wconf is a short name anyway, so IMHO there is no benefit of defining
> the functions and variables with the abbreviated wc- prefix instead of
> wconf-.  But there is the obvious downside of likely clashes with
> private stuff from users with the initials WC.  So I'd suggest to change
> that before it pops up in the package list and people start using,
> configuring, and extending it.
>
> A similar thing applies to the file where window configs are stored
> which is currently window-configs.el.  I'd rather go with something
> which makes the connection to your package completely obvious, e.g.,
> wconf-window-configs.el.
>
> Bye,
> Tassilo

Hi Tassilo,

Thanks for your comments!  I have some showstoppers to fix that Dmitry
spotted, and then I'll think about the prefix stuff and will probably
change it.

I have not thought about the point and window business yet, so there's
no option.  Generally I am wary of dealing with window-config details
(which I did in a much earlier version of the package), but this seems
like a general and useful switch to have.. Maybe I will add that.  It
would help me if you could add a github issue describing the option
behavior, otherwise I'll try to keep a note myself.

Bye,
Ingo

Re: include new package wconf.el in GNU ELPA

[Tassilo Horn]

Ingo Lohmar <i.lohmar@gmail.com> writes:

Hi Ingo,

> I have not thought about the point and window business yet, so there's
> no option.  Generally I am wary of dealing with window-config details
> (which I did in a much earlier version of the package), but this seems
> like a general and useful switch to have.. Maybe I will add that.  It
> would help me if you could add a github issue describing the option
> behavior, otherwise I'll try to keep a note myself.

I've thought about it, and I think such an option should be in emacs
itself so that you can have that behavior with winner, wconf, or
whatever else you use for window config business.

I had a look at the corresponding code in emacs, and actually the
restoration of point is not done in `set-window-configuration' but
instead it's done afterwards in `jump-to-register', in `winner-set', and
probably other places as well.

The best I could come up so far is this advice, which uses an ugly timer
to reclaim back the current points...

--8<---------------cut here---------------start------------->8---
(defun th/window-config-keep-points-and-selected-window (old config)
  (let ((bufpoints (mapcar
		    (lambda (buf)
		      (cons buf (with-selected-window (get-buffer-window buf)
				  (point))))
		    (cl-remove-if-not #'get-buffer-window
				      (buffer-list (selected-frame)))))
	(p (point)))
    (funcall old config)
    (when-let ((w (get-buffer-window)))
      (select-window w))
    ;; The setting of point is not performed by `set-window-configuration'
    ;; itself but by `jump-to-register' or the winner functions.
    (run-with-timer 0.139 nil
		    (lambda ()
		      (dolist (bp bufpoints)
			(let ((buf (car bp))
			      (p   (cdr bp)))
			  (when-let ((w (get-buffer-window buf)))
			    (with-selected-window
				(goto-char p)))))))))

(advice-add #'set-window-configuration :around
	    #'th/window-config-keep-points-and-selected-window)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: include new package wconf.el in GNU ELPA

[martin rudalics]

 > I had a look at the corresponding code in emacs, and actually the
 > restoration of point is not done in `set-window-configuration' but
 > instead it's done afterwards in `jump-to-register', in `winner-set', and
 > probably other places as well.

I didn't look into these.  But do they really change a buffer's point?
Or do they change a window's point (aka `window-point').

martin

Re: include new package wconf.el in GNU ELPA

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>> I had a look at the corresponding code in emacs, and actually the
>> restoration of point is not done in `set-window-configuration' but
>> instead it's done afterwards in `jump-to-register', in `winner-set', and
>> probably other places as well.
>
> I didn't look into these.  But do they really change a buffer's point?
> Or do they change a window's point (aka `window-point').

They use `goto-char' in the window which is selected after setting the
window configuration, so I guess it's the buffer's point.

BTW, my advice was completely broken.  Here is a better version:

--8<---------------cut here---------------start------------->8---
(defun th/window-config-keep-points-and-selected-window (old config)
  (let ((bufpoints (mapcar
		    (lambda (buf)
		      (cons buf (with-selected-window (get-buffer-window buf)
				  (point))))
		    (cl-remove-if-not #'get-buffer-window
				      (buffer-list (selected-frame)))))
	(selected-buf (current-buffer)))
    (funcall old config)
    ;; Restore selected window
    (when-let ((w (get-buffer-window selected-buf)))
      (select-window w))
    ;; The setting of point is not performed by `set-window-configuration'
    ;; itself but by `jump-to-register' or the winner functions.
    (run-with-timer 0.139 nil
		    (lambda ()
		      (dolist (bp bufpoints)
			(let ((buf (car bp))
			      (p   (cdr bp)))
			  (when-let ((w (get-buffer-window buf)))
			    (with-selected-window w
			      (goto-char p)))))))))

(advice-add #'set-window-configuration :around
	    #'th/window-config-keep-points-and-selected-window)
--8<---------------cut here---------------end--------------->8---

But that's also really bad.  For example, `edebug' uses
`set-window-configuration' internally, so point always jumps back after
each edebug step.

Seems like I can't achieve what I'm looking for too easily.

Bye,
Tassilo

Re: include new package wconf.el in GNU ELPA

[martin rudalics]

 > They use `goto-char' in the window which is selected after setting the
 > window configuration, so I guess it's the buffer's point.

I still don't get what you want instead.

 >    (let ((bufpoints (mapcar
 > 		    (lambda (buf)
 > 		      (cons buf (with-selected-window (get-buffer-window buf)
 > 				  (point))))
 > 		    (cl-remove-if-not #'get-buffer-window
 > 				      (buffer-list (selected-frame)))))

All you can possibly want here are window-points, the positions of the
cursor in any window shown before or after setting the configuration.
Calling `buffer-list' makes no sense.

 > But that's also really bad.  For example, `edebug' uses
 > `set-window-configuration' internally, so point always jumps back after
 > each edebug step.

`set-window-configuration' should be used only "internally".  It's main
design goal is that the user should _not_ be aware of its existence.

Maybe you could use `window-state-get' and `window-state-put' instead.

martin

Re: include new package wconf.el in GNU ELPA

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>> They use `goto-char' in the window which is selected after setting
>> the window configuration, so I guess it's the buffer's point.
>
> I still don't get what you want instead.
>
>>    (let ((bufpoints (mapcar
>> 		    (lambda (buf)
>> 		      (cons buf (with-selected-window (get-buffer-window buf)
>> 				  (point))))
>> 		    (cl-remove-if-not #'get-buffer-window
>> 				      (buffer-list (selected-frame)))))
>
> All you can possibly want here are window-points, the positions of the
> cursor in any window shown before or after setting the configuration.
> Calling `buffer-list' makes no sense.

Ok, so is this better?

--8<---------------cut here---------------start------------->8---
;; Keep window selection and point
(defun th/window-config-keep-points-and-selected-window (old config)
  (let ((bufpoints (mapcar (lambda (win)
			     (cons (window-buffer win) (window-point win)))
			   (window-list (selected-frame))))
	(selected-buf (current-buffer)))
    (funcall old config)
    ;; Do our magic only if called interactively.
    (when (and (memq this-command '(jump-to-register winner-undo winner-redo))
	       (called-interactively-p 'interactive))
      ;; Restore selected window
      (when-let ((w (get-buffer-window selected-buf)))
	(select-window w))
      ;; The setting of point is not performed by `set-window-configuration'
      ;; itself but by `jump-to-register' or the winner functions.
      (run-with-timer 0.139 nil
		      (lambda ()
			(dolist (bp bufpoints)
			  (when-let ((w (get-buffer-window (car bp))))
			    (set-window-point win (cdr bp)))))))))

(advice-add #'set-window-configuration :around
	    #'th/window-config-keep-points-and-selected-window)
--8<---------------cut here---------------end--------------->8---

It seems to do what I had in mind.

>> But that's also really bad.  For example, `edebug' uses
>> `set-window-configuration' internally, so point always jumps back
>> after each edebug step.
>
> `set-window-configuration' should be used only "internally".  It's
> main design goal is that the user should _not_ be aware of its
> existence.
>
> Maybe you could use `window-state-get' and `window-state-put' instead.

You mean, get the state of all windows in the current window
configuration, then switch to the other, and then put the state back for
all windows of buffers that were also displayed in the previous WC?

Bye,
Tassilo

Re: include new package wconf.el in GNU ELPA

[martin rudalics]

 > Ok, so is this better?

Not much.

 >
 > --8<---------------cut here---------------start------------->8---
 > ;; Keep window selection and point
 > (defun th/window-config-keep-points-and-selected-window (old config)
 >    (let ((bufpoints (mapcar (lambda (win)
 > 			     (cons (window-buffer win) (window-point win)))
 > 			   (window-list (selected-frame))))

Here you record window points ...

 > 	(selected-buf (current-buffer)))
 >      (funcall old config)
 >      ;; Do our magic only if called interactively.
 >      (when (and (memq this-command '(jump-to-register winner-undo winner-redo))
 > 	       (called-interactively-p 'interactive))
 >        ;; Restore selected window
 >        (when-let ((w (get-buffer-window selected-buf)))
 > 	(select-window w))
 >        ;; The setting of point is not performed by `set-window-configuration'
 >        ;; itself but by `jump-to-register' or the winner functions.
 >        (run-with-timer 0.139 nil
 > 		      (lambda ()
 > 			(dolist (bp bufpoints)
 > 			  (when-let ((w (get-buffer-window (car bp))))
 > 			    (set-window-point win (cdr bp)))))))))

... and here you restore them in some completely arbitrary manner.  This
can work reasonably iff all windows show different buffers.

 > You mean, get the state of all windows in the current window
 > configuration, then switch to the other, and then put the state back for
 > all windows of buffers that were also displayed in the previous WC?

`window-state-get' gets you a Lisp object that you can manipulate.  For
example, you can replace point positions in some arbitrary way.  Doing
the same with an object returned by `current-window-configuration' is
practically impossible.

martin

Re: include new package wconf.el in GNU ELPA

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>> --8<---------------cut here---------------start------------->8---
>> ;; Keep window selection and point
>> (defun th/window-config-keep-points-and-selected-window (old config)
>>    (let ((bufpoints (mapcar (lambda (win)
>> 			     (cons (window-buffer win) (window-point win)))
>> 			   (window-list (selected-frame))))
>
> Here you record window points ...
>
>> 	(selected-buf (current-buffer)))
>>      (funcall old config)
>>      ;; Do our magic only if called interactively.
>>      (when (and (memq this-command '(jump-to-register winner-undo winner-redo))
>> 	       (called-interactively-p 'interactive))
>>        ;; Restore selected window
>>        (when-let ((w (get-buffer-window selected-buf)))
>> 	(select-window w))
>>        ;; The setting of point is not performed by `set-window-configuration'
>>        ;; itself but by `jump-to-register' or the winner functions.
>>        (run-with-timer 0.139 nil
>> 		      (lambda ()
>> 			(dolist (bp bufpoints)
>> 			  (when-let ((w (get-buffer-window (car bp))))
>> 			    (set-window-point win (cdr bp)))))))))
>
> ... and here you restore them in some completely arbitrary manner.
> This can work reasonably iff all windows show different buffers.

Yes, that was kind of an assumption.  In the presence of multiple
windows on the same buffer in either the from or to window
configuration, there are lots of special cases to which I don't have an
answer, yet.  (Neither code nor what should actually happen.)

>> You mean, get the state of all windows in the current window
>> configuration, then switch to the other, and then put the state back
>> for all windows of buffers that were also displayed in the previous
>> WC?
>
> `window-state-get' gets you a Lisp object that you can manipulate.
> For example, you can replace point positions in some arbitrary way.
> Doing the same with an object returned by
> `current-window-configuration' is practically impossible.

I see, thanks.

Bye,
Tassilo

Re: include new package wconf.el in GNU ELPA

[Ingo Lohmar]

Hi Tassilo,

On Fri, Jul 31 2015 07:35 (+0200), Tassilo Horn wrote:
>
> I've thought about it, and I think such an option should be in emacs
> itself so that you can have that behavior with winner, wconf, or
> whatever else you use for window config business.
>
> I had a look at the corresponding code in emacs, and actually the
> restoration of point is not done in `set-window-configuration' but
> instead it's done afterwards in `jump-to-register', in `winner-set', and
> probably other places as well.

That makes sense, and I will postpone the issue.  It might still be
feasible to do the changes in wconf after restoration (as a "unique
selling point" :), feel free to let me know (preferably via a github
issue) what would be the best way then.

Regards,
Ingo

Re: include new package wconf.el in GNU ELPA

[martin rudalics]

 > Basically, I'd
 > prefer that when I restore a window config, the point values stay as
 > they are for all the buffers which are part of the current window config
 > and the one I'm switching to.

What is the "point value of a buffer" and where do you see it change?

martin

Re: include new package wconf.el in GNU ELPA

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>> Basically, I'd prefer that when I restore a window config, the point
>> values stay as they are for all the buffers which are part of the
>> current window config and the one I'm switching to.
>
> What is the "point value of a buffer" and where do you see it change?

Say I have just a single window with *scratch* and point at (point-min).
I save that window config to a register.  Now I split windows, and some
of the windows still show *scratch*, but in there I moved point to
(point-max).

What I like to have was that `C-x r j <the-register-with-initial-wconf>`
went back to the single-window displaying *scratch* layout but the last
recent point value would stick to (point-max) instead of going back to
(point-min).

Well, and actually I'd like to have that not only for WCs stored in
registers but also for, e.g., WCs stored by winner, etc.  The problem is
that some things like edebug also use WCs internally, and there
switching back to the original point is absolutely needed.  So I don't
see how to distinguish the cases.  Maybe some whitelist kind of approach
like

  (and (memq last-command '(jump-to-register winner-undo winner-redo))
       (called-interactively-p 'interactive))

could do the trick...

Bye,
Tassilo

Re: include new package wconf.el in GNU ELPA

[martin rudalics]

 > Say I have just a single window with *scratch* and point at (point-min).
 > I save that window config to a register.  Now I split windows, and some
 > of the windows still show *scratch*, but in there I moved point to
 > (point-max).
 >
 > What I like to have was that `C-x r j <the-register-with-initial-wconf>`
 > went back to the single-window displaying *scratch* layout but the last
 > recent point value would stick to (point-max) instead of going back to
 > (point-min).

IIUC you eventually go to a window that was not part of the initial
configuration and there you move `point'.  Then you restore the initial
configuration and that last movement's value is lost.

I'm afraid that want you want cannot be achieved easily.  In principle
we'd have to record for each window the last position of its buffer's
`point' at the time the window was selected together with a time stamp.
When restoring the configuration we'd have to, for the selected window,
check whether its `point' should be moved to some youngest previously
stored position.  What if the window where the last move occurred was
deleted before restoring the configuration?  What if `point' moved at a
time no window showing the buffer was selected?

martin

Re: include new package wconf.el in GNU ELPA

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>> Say I have just a single window with *scratch* and point at
>> (point-min).  I save that window config to a register.  Now I split
>> windows, and some of the windows still show *scratch*, but in there I
>> moved point to (point-max).
>>
>> What I like to have was that `C-x r j
>> <the-register-with-initial-wconf>` went back to the single-window
>> displaying *scratch* layout but the last recent point value would
>> stick to (point-max) instead of going back to (point-min).
>
> IIUC you eventually go to a window that was not part of the initial
> configuration and there you move `point'.  Then you restore the initial
> configuration and that last movement's value is lost.

Yes, pretty much that.  I don't have a real concept of a window other
than a container for a buffer so I can't tell if a window W1 in window
configuration WC1 is different to a window W2 in window configuration
WC2.  All I want is that when switching from WC1 to WC2, all buffers
which are displayed by some window in both WC1 and WC2 keep their window
point values from WC1.

Of course, there are corner cases like some buffer being displayed in
multiple windows in WC1 and/or WC2 which I haven't thought about yet.

> I'm afraid that want you want cannot be achieved easily.  In principle
> we'd have to record for each window the last position of its buffer's
> `point' at the time the window was selected together with a time
> stamp.

I think I'm fine with just the windows that are currently visible at the
point in time where the window config switch happens.

> When restoring the configuration we'd have to, for the selected
> window, check whether its `point' should be moved to some youngest
> previously stored position.  What if the window where the last move
> occurred was deleted before restoring the configuration?

When I deleted it, then I don't care about it.

> What if `point' moved at a time no window showing the buffer was
> selected?

Then I didn't move myself so that move is not interesting to me.

Bye,
Tassilo

Re: include new package wconf.el in GNU ELPA

[martin rudalics]

 > Yes, pretty much that.  I don't have a real concept of a window other
 > than a container for a buffer so I can't tell if a window W1 in window
 > configuration WC1 is different to a window W2 in window configuration
 > WC2.  All I want is that when switching from WC1 to WC2, all buffers
 > which are displayed by some window in both WC1 and WC2 keep their window
 > point values from WC1.
 >
 > Of course, there are corner cases like some buffer being displayed in
 > multiple windows in WC1 and/or WC2 which I haven't thought about yet.
 >
 >> I'm afraid that want you want cannot be achieved easily.  In principle
 >> we'd have to record for each window the last position of its buffer's
 >> `point' at the time the window was selected together with a time
 >> stamp.
 >
 > I think I'm fine with just the windows that are currently visible at the
 > point in time where the window config switch happens.
 >
 >> When restoring the configuration we'd have to, for the selected
 >> window, check whether its `point' should be moved to some youngest
 >> previously stored position.  What if the window where the last move
 >> occurred was deleted before restoring the configuration?
 >
 > When I deleted it, then I don't care about it.
 >
 >> What if `point' moved at a time no window showing the buffer was
 >> selected?
 >
 > Then I didn't move myself so that move is not interesting to me.

So your solution is hardly one that generalizes in a suitable way :-(

martin