Ihor Radchenko <[email protected]> writes: > Björn Kettunen <[email protected]> writes: > >> Thanks for the reproducer. Especially the make repro target. One note >> for it it didn't open a unless I removed the & on the repro target. > > Could you elaborate?
I called make repro in Emacs. If there's the & add the end of the make target to send the process into the background then that Emacs doesn't open a frame. >> I figure it would be best to store two window configuration, one for >> before and one for after moving to the note target. >> >> When the starting frame when pressing C-c C-z is the same as the one the >> note is taken in then the previous window configuration is restore, >> nothing else happens. >> >> If the starting and the note frame is different then the configuration >> from just before opening the note window is saved, i.e. from the frame >> the target org file is in and then the previous frame is activated with >> that previous's frame window configuration restored. >> >> I'm not sure if the starting frames window configuration has to be >> restored if it's not the org-note frame. >> ... >> + (if (equal org-log-note-previous-frame (selected-frame)) >> + (set-window-configuration org-log-note-previous-window-configuration) >> + (set-window-configuration org-log-note-window-configuration) >> + (raise-frame org-log-note-previous-frame) >> + (set-window-configuration org-log-note-previous-window-configuration)) > > I am wondering if we could instead use quit-restore window parameter to > handle all this. The code above appears to re-implement the quitting logic. How so? I'm not sure I fully understand. Reading the manual on quitting windows doesn't mention anything on window configuration. The logic is quite complex to be honest. I also don't see any mention about raising frames. > Also, in the code above, I am not sure about setting > org-log-note-window-configuration. Does it try to handle a situation > when note buffer is raised in an existing, but different frame? My > imagination is that notes buffer is created in a new frame, but then the > expected behavior is killing the frame. Yes exactly. The behavior is basically the same as if the starting frame and the frame the note buffer/window is in but with the window configuration restored after popping to the frame that the parent org buffer is in. I.e. like this: 1. org-agenda 2. add-note on agenda item 2. Switch to the frame that the org buffer in which the note will be taken in is 3. Take/not take the note. 4. Restore window configuration of the current frame that we just switched to 5. Go back Restoring the window configuration of the starting frame is probably wrong when it isn't the frame that the note will be taken in. I will remove that.
