emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] pop-up-windows


From: Carsten Dominik
Subject: Re: [Orgmode] pop-up-windows
Date: Wed, 6 May 2009 14:14:49 +0200


Hi Samuel,

On Apr 25, 2009, at 5:44 AM, Samuel Wales wrote:

When I click on a link, org-open-at-point splits the window.
What I would like is for it to open the link in the current
window.  The same occurs with org-remember; it splits the
window, but I would like to have the whole window.

Both Emacs and Xemacs have a standard variable,
pop-up-windows, that allows the user to control this
behavior.  Users who set it to nil can expect all but the
most unusual buffers to open in the current window.  Most
parts of emacs respect it.

I do not use display-buffer in Org, because the results are
so unpredictable for different users precisely because there
is a plethora of options and hooks that do modify the behavior.
This makes it difficult to create a consistent interface, at
least in my opinion.

As mentioned in this thread, use org-link-frame-setup to
customize this for links.

For remember you can use

(add-hook 'remember-mode-hook 'delete-other-windows)



IMO it would be useful for org to do the same.  It is easy to do,
because you can call pop-to-buffer instead of
switch-to-buffer-other-window.

Try these:

(let ((pop-up-windows t)) (pop-to-buffer (get-buffer "*Messages*")))
(let ((pop-up-windows)) (pop-to-buffer (get-buffer "*Messages*")))

People who use small screens and people who use large fonts
use nil because splitting the window makes small windows.



In org, todo state selection and tag selection should
probably ignore the variable, provided that the window
height contains the buffer.  The context is useful, so it's
OK to split the window.

Exactly, this is what drove me crazy and toward
abandoning pop-to-buffer and display-buffer entirely.

Export dispatch and agenda dispatch should probably respect
the variable because context usually does not add to the
decision being made (among other reasons).  They do not
currently respect it.

I don't think this is an issue.  These commands make the
buffer as large as needed to display their entire content.
If necessary they will remove the other window.  So with a
large font, they can use the whole frame.

In general, I do like the other window to remain visible
if enough space is there, to remind the user of the calling
context.

org-complete is currently problematic because it
inadvertently respects the variable.  It changes to the
completions buffer, and then the completion keys do not
work.

I don't understand.  What is the problem?

This should probably either ignore the variable or accept the
completion keys.  However, I do not use it, so I have not
tried it much.

- Carsten





reply via email to

[Prev in Thread] Current Thread [Next in Thread]