Re: [O] org-capture: keeping window visible during date entry
Hi Christoph, Christoph Groth c...@falma.de writes: I would say that a proper solution would be to reserve delete-other-windows for interactive use and to replace it by something more sensible which ensures that a given window is well visible but tries to preserve the visibility and arrangement other windows if possible. That hypothetical function could be given the minimum required height for the current window. Does anyone know of such functionality already existing anywhere in the emacs world? There is `maximize-window'. If you want to work on a patch that uses `maximize-window' in places where you think it should replace `delete-other-windows', please do. But I think ̀delete-other-windows' is fine in most cases. If not, I believe it would be useful to think of something like this. Given current screen sizes, it would be good to replace most uses of delete-other-windows by something more gentle. But this is a topic for the general emacs mailing list. Yep, why not. I'm archiving Eric's patch for now. Let's raise this issue again if we can more precisely define what's wrong with the current behavior. -- Bastien
Re: [O] org-capture: keeping window visible during date entry
Eric Abrahamsen e...@ericabrahamsen.net writes: On Thu, Jun 14 2012, Christoph Groth wrote: How to ensure that the buffer which was active when org-capture was executed remains visible during date entry? I've had the same annoyance. The attached patch is *not* a real solution to the problem, as it still produces some weird windowing, and I have no idea if it will wreck other uses of capture, but it does preserve gnus windows so you can see the information you're trying to capture. It's at least a pointer in the right direction… Yes, the problems are mostly due to calls to delete-other-windows which is used quite often in org (19 times) and other emacs packages as well. I would say that a proper solution would be to reserve delete-other-windows for interactive use and to replace it by something more sensible which ensures that a given window is well visible but tries to preserve the visibility and arrangement other windows if possible. That hypothetical function could be given the minimum required height for the current window. Does anyone know of such functionality already existing anywhere in the emacs world? If not, I believe it would be useful to think of something like this. Given current screen sizes, it would be good to replace most uses of delete-other-windows by something more gentle. But this is a topic for the general emacs mailing list.
Re: [O] org-capture: keeping window visible during date entry
On 7/7/12, Christoph Groth c...@falma.de wrote: I would say that a proper solution would be to reserve delete-other-windows for interactive use and to replace it by something more sensible which ensures that a given window is well visible but tries to preserve the visibility and arrangement other windows if possible. That hypothetical function could be given the minimum required height for the current window. This is something that needs to be under user control. We cannot force a regression on an accessibility issue. Not all screen sizes are large and not all fonts are small. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] org-capture: keeping window visible during date entry
Samuel Wales samolog...@gmail.com writes: On 7/7/12, Christoph Groth c...@falma.de wrote: I would say that a proper solution would be to reserve delete-other-windows for interactive use and to replace it by something more sensible which ensures that a given window is well visible but tries to preserve the visibility and arrangement other windows if possible. That hypothetical function could be given the minimum required height for the current window. This is something that needs to be under user control. We cannot force a regression on an accessibility issue. Not all screen sizes are large and not all fonts are small. My proposal is not about reducing accessibility but increasing usability. What's the point of deleting all the other windows to show a buffer containing only five lines of text (a typical capture buffer) and unlikely to grow much? If the user wants to type a lot into the new buffer, he can press C-x 1 himself. By something more sensible I meant functionality which would do the right thing both for small and large emacs frames. In many cases a reasonable minimum size for the new window to be displayed can be estimated. My font is actually not small and my screen typical. Still, my emacs frame is 70 lines high.
Re: [O] org-capture: keeping window visible during date entry
Not all use cases are identical to yours. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] org-capture: keeping window visible during date entry
On Thu, Jun 14 2012, Christoph Groth wrote: Hello, I recently switched from remember to org's new capture facility which seems to work fine. However, an issue I already had with remember is still bothering me, perhaps someone knows a good solution: I often call org-capture from within a buffer containing some relevant context, for example an e-mail message displayed by gnus. The emacs window created by org-capture that allows to choose a template is created below the two Gnus windows showing the group and the message. My org-capture templates require entering a date. During the subsequent date entry, the gnus windows are not visible anymore (I only see the nascent buffer with the entry to be captured and a window showing the emacs calendar). This is impractical, because the e-mail message often contains the very date I would like to enter. How to ensure that the buffer which was active when org-capture was executed remains visible during date entry? Thanks, Christoph I've had the same annoyance. The attached patch is *not* a real solution to the problem, as it still produces some weird windowing, and I have no idea if it will wreck other uses of capture, but it does preserve gnus windows so you can see the information you're trying to capture. It's at least a pointer in the right direction… Eric diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 0e6ab2c..e53b430 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -873,7 +873,7 @@ it. When it is a variable, retrieve the value. Return whatever we get. (defun org-capture-place-template () Insert the template at the target location, and display the buffer. (org-capture-put :return-to-wconf (current-window-configuration)) - (delete-other-windows) +; (delete-other-windows) (org-switch-to-buffer-other-window (org-capture-get-indirect-buffer (org-capture-get :buffer) CAPTURE)) (widen) @@ -1347,8 +1347,8 @@ The template may still contain \%?\ for cursor positioning. (unless template (setq template ) (message No template) (ding) (sit-for 1)) (save-window-excursion - (delete-other-windows) - (org-pop-to-buffer-same-window (get-buffer-create *Capture*)) +; (delete-other-windows) + (org-switch-to-buffer-other-window (get-buffer-create *Capture*)) (erase-buffer) (insert template) (goto-char (point-min)) -- GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-06-11 on pellet 7.8.10
[O] org-capture: keeping window visible during date entry
Hello, I recently switched from remember to org's new capture facility which seems to work fine. However, an issue I already had with remember is still bothering me, perhaps someone knows a good solution: I often call org-capture from within a buffer containing some relevant context, for example an e-mail message displayed by gnus. The emacs window created by org-capture that allows to choose a template is created below the two Gnus windows showing the group and the message. My org-capture templates require entering a date. During the subsequent date entry, the gnus windows are not visible anymore (I only see the nascent buffer with the entry to be captured and a window showing the emacs calendar). This is impractical, because the e-mail message often contains the very date I would like to enter. How to ensure that the buffer which was active when org-capture was executed remains visible during date entry? Thanks, Christoph
