[-- Attachment #1: Type: text/plain, Size: 1318 bytes --] About a year ago change 819e98afd018cad3c13fd58bfcbd979ab36dfbc7 was checked in to remove code that restored window configuration when =org-edit-src-exit= finished. The net result is af if =C-x 1= is called to remove all windows except the org buffer just edited. This is very inconvenient. Why not call =winner-undo= to restore window configuration as shown here? #+begin_src diff From bd0a2abaa8097338d7f33c7ca9a1d45f5da67e7a Mon Sep 17 00:00:00 2001 From: kimr <kimr@synopsys.com> Date: Sat, 14 Dec 2019 10:59:00 -0800 Subject: [PATCH] restore window config by calling winner-undo --- lisp/org-src.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 5e50a1b4..c8c30889 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -1182,7 +1182,8 @@ Throw an error if there is no such buffer." (write-back (org-src--goto-coordinates coordinates beg end)))) ;; Clean up left-over markers and restore window configuration. (set-marker beg nil) - (set-marker end nil))) + (set-marker end nil) + (winner-undo))) (provide 'org-src) -- 2.22.1 #+end_src For now I'm using the following advice do the same thing. #+begin_src elisp (defadvice org-edit-src-exit (after restore-window-config activate) (winner-undo)) #+end_src [-- Attachment #2: Type: text/html, Size: 8774 bytes --]
Hello,
Richard Kim <Richard.Kim1@synopsys.com> writes:
> About a year ago change 819e98afd018cad3c13fd58bfcbd979ab36dfbc7 was checked in
> to remove code that restored window configuration when =org-edit-src-exit=
> finished. The net result is af if =C-x 1= is called to remove all windows except
> the org buffer just edited. This is very inconvenient.
>
> Why not call =winner-undo= to restore window configuration as shown
> here?
I'd rather not add another dependency just for this.
However, it doesn't mean the inconvenience shouldn't be fixed. I cannot
remember why 819e98afd018cad3c13fd58bfcbd979ab36dfbc7 was necessary. I'm
Cc'ing Matt Price.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > However, it doesn't mean the inconvenience shouldn't be fixed. I cannot > remember why 819e98afd018cad3c13fd58bfcbd979ab36dfbc7 was necessary. I'm > Cc'ing Matt Price. Here's the related thread: https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00253.html Summary: Matt had a case where he didn't want the window configuration to be restored, so he proposed hiding the behavior behind an option. You wondered whether we should just remove support for restoring the window configuration and not bother with the option. Nobody offered a defense for restoring the window configuration or complained... until now :]
I'd like to add a vote for the old behavior. I only recently noticed the new behavior, and agree with Richard that it's inconvenient. I think many of us missed this change because it wasn't in 9.2. In particular, I'd propose to make the old behavior the default, and hide the new behavior behind an option like Matt originally proposed. I'm updating my copyright papers for my current job, if no one has submitted a patch by the time I've got that sorted, I could work on a patch then.
Sorry for the noise, but I just had another thought: Rather than adding a new option, how about we make the behavior dependent on the value of org-src-window-setup? Basically, when org-src-window-setup is current-window, it never makes sense to restore the original layout. But when org-src-window-setup is reorganize-frame (the default), it always makes sense to restore the original layout. I'm not sure what the "correct" behavior would be for the other options however. Now that I think about it, I remember trying out the "current-window" option before, and having a very similar experience to Matt -- while I enjoyed having more manual control over the window layout, the fact that org-mode would change the window layout after I finished editing defeated the whole purpose of this, so I switched back to the original defaults.
On Tuesday, 17 Dec 2019 at 06:28, Jack Kamm wrote:
> Basically, when org-src-window-setup is current-window, it never makes
> sense to restore the original layout. But when org-src-window-setup is
> reorganize-frame (the default), it always makes sense to restore the
> original layout.
This makes sense to me.
While we're talking about org-src-window-setup, I set it to
'split-window-right on my large monitor. Sometimes, I make the src
window full frame but then, when trying to go back to the org buffer
(C-c '), I get the error:
delete-window: Attempt to delete minibuffer or sole ordinary window
This would be fixed if the original layout were restored instead of
simply deleting the src window, I guess.
--
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Hello,
Jack Kamm <jackkamm@gmail.com> writes:
> Rather than adding a new option, how about we make the behavior
> dependent on the value of org-src-window-setup?
>
> Basically, when org-src-window-setup is current-window, it never makes
> sense to restore the original layout. But when org-src-window-setup is
> reorganize-frame (the default), it always makes sense to restore the
> original layout.
>
> I'm not sure what the "correct" behavior would be for the other options
> however.
I think any value that modifies the current layout ought to restore it:
- `split-window-below'
- `split-window-right'
- `reorganize-frame'
OTOH, values that use the current layout should not restore it
afterwards:
- `current-window'
- `other-window'
- `other-frame'
This should be mentioned in the docstring.
WDYT?
Regards,
--
Nicolas Goaziou
Hi,
> I think any value that modifies the current layout ought to restore it:
> - `split-window-below'
> - `split-window-right'
> - `reorganize-frame'
>
> OTOH, values that use the current layout should not restore it
> afterwards:
> - `current-window'
> - `other-window'
> - `other-frame'
>
> This should be mentioned in the docstring.
>
> WDYT?
I agree, this sounds like the correct behavior to me.
Hello,
Jack Kamm <jackkamm@gmail.com> writes:
> I agree, this sounds like the correct behavior to me.
OK. Would you want to implement it?
Regards,
--
Nicolas Goaziou
> OK. Would you want to implement it?
Yes, but I'm still in the process of updating my copyright papers for my
current job. My job said they won't be able to sign the copyright
disclaimer until the new year, so I expect this to be sorted out later
in January some time.
However, the change here is very small, I just wrote a small patch and
it's 15 insertions (+), 4 deletions(-), including the entry in
ORG-NEWS. My understanding is that such small changes don't require
explicit copyright assignment.
Is it OK for me to send the patch along, or should I hold off on this?
--Jack
Jack Kamm <jackkamm@gmail.com> writes:
> However, the change here is very small, I just wrote a small patch and
> it's 15 insertions (+), 4 deletions(-), including the entry in
> ORG-NEWS. My understanding is that such small changes don't require
> explicit copyright assignment.
>
> Is it OK for me to send the patch along, or should I hold off on this?
It is OK.
Hello. I would like to request this to be pushed onto the =maint= branch (7684b59c7) or make it the default, please. https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/txtr_q1WmvVPH.txt which is related to (at least) commits 7d5e931f7 and d833920de from the =master= branch. I have also tested by using lisp/org-src.el from the current =master= (9bc0cc7fb) on the =maint= branch (7684b59c7), and it works for me. Thanks! ------------------------------------------------- This free account was provided by VFEmail.net - report spam to abuse@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!
Hi Edgar,
edgar@openmail.cc writes:
> Hello. I would like to request this to be pushed onto the =maint=
> branch (7684b59c7) or make it the default, please.
this has been applied in the master branch back in January,
it will be part of Org 9.4.
Best,
--
Bastien