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
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --] 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 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: capture windows --] [-- Type: text/x-patch, Size: 1077 bytes --] 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)) [-- Attachment #3: Type: text/plain, Size: 100 bytes --] -- GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-06-11 on pellet 7.8.10
Eric Abrahamsen <eric@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.
On 7/7/12, Christoph Groth <cwg@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
Samuel Wales <samologist@gmail.com> writes:
> On 7/7/12, Christoph Groth <cwg@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.
Not all use cases are identical to yours. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Hi Christoph, Christoph Groth <cwg@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