From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: pop-up-windows Date: Wed, 6 May 2009 14:14:49 +0200 Message-ID: <22E47E07-CA61-4BA9-8992-3339A9084A37@gmail.com> References: <20524da70904242044g264eb994vfd13a3d258452210@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1g1c-0004fO-Fe for emacs-orgmode@gnu.org; Wed, 06 May 2009 08:15:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1g1X-0004ZY-Fo for emacs-orgmode@gnu.org; Wed, 06 May 2009 08:14:59 -0400 Received: from [199.232.76.173] (port=56014 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1g1X-0004ZN-2y for emacs-orgmode@gnu.org; Wed, 06 May 2009 08:14:55 -0400 Received: from mail-ew0-f162.google.com ([209.85.219.162]:41312) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1g1W-0005iN-MD for emacs-orgmode@gnu.org; Wed, 06 May 2009 08:14:54 -0400 Received: by ewy6 with SMTP id 6so63860ewy.42 for ; Wed, 06 May 2009 05:14:53 -0700 (PDT) In-Reply-To: <20524da70904242044g264eb994vfd13a3d258452210@mail.gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Samuel Wales Cc: emacs-orgmode@gnu.org 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