The first one is to customize creation of the new window in Emacs. The second one is for adding API to use it from Emacs lisp (and I guess it will be available for Vim, too). I hope they will be merged soon!
> Could you name it as project_opened_p and return the root directory when > it is true? Thanks.
> Leo
Yes, I think returning project root is a good idea. About naming, is "*_p" Vim script convention too? I didn't find "*_p" in ropemode and that's why I didn't choose that name. How about "get_project_root" if it returns a path?
On 2012-02-06 18:19 +0800, Takafumi Arakaki wrote:
> Yes, I think returning project root is a good idea. About naming, is > "*_p" Vim script convention too? I didn't find "*_p" in ropemode and > that's why I didn't choose that name. How about "get_project_root" if > it returns a path?
Is there a more general solution? For example, if it goes through with-output-to-temp-buffer, then its behaviour can be controlled in elisp and `q' can correctly restore window configuration.
On Tue, Feb 7, 2012 at 2:46 AM, Leo <sdl....@gmail.com> wrote: > Is there a more general solution? For example, if it goes through > with-output-to-temp-buffer, then its behaviour can be controlled in > elisp and `q' can correctly restore window configuration.
You can do this with popwin.el and my patch. There is no general solution as far as I know. pop-to-buffer is general in some sense because it tries to do the "right" thing (like using already opened window if it is available) and you can customize its behavior via display-buffer-function variable.
Takafumi Arakaki <aka....@gmail.com> wrote: > On Tue, Feb 7, 2012 at 2:46 AM, Leo <sdl....@gmail.com> wrote: > > Is there a more general solution? For example, if it goes through > > with-output-to-temp-buffer, then its behaviour can be controlled in > > elisp and `q' can correctly restore window configuration.
> You can do this with popwin.el and my patch. There is no general > solution as far as I know. pop-to-buffer is general in some sense > because it tries to do the "right" thing (like using already opened > window if it is available) and you can customize its behavior via > display-buffer-function variable.
How does it differ from the old behavior? Can't we use pop-to-buffer and merge the two cases in window="other"?
> Takafumi Arakaki <aka....@gmail.com> wrote: >> On Tue, Feb 7, 2012 at 2:46 AM, Leo <sdl....@gmail.com> wrote: >> > Is there a more general solution? For example, if it goes through >> > with-output-to-temp-buffer, then its behaviour can be controlled in >> > elisp and `q' can correctly restore window configuration.
>> You can do this with popwin.el and my patch. There is no general >> solution as far as I know. pop-to-buffer is general in some sense >> because it tries to do the "right" thing (like using already opened >> window if it is available) and you can customize its behavior via >> display-buffer-function variable.
> How does it differ from the old behavior? Can't we use > pop-to-buffer and merge the two cases in window="other"?
> Ali
I think the original version has some additional behaviors such as fitting height of the opened window if there is not much contents when window="othere" and fit_lines=True. Maybe some people prefer this. Personally I don't need this because I want let other elisp module handle this. I don't know what is the best solution for every one. But yes, I guess using pop-to-buffer is a point of compromise if you want keep the function simple.
> I think the original version has some additional behaviors such as > fitting height of the opened window if there is not much contents when > window="othere" and fit_lines=True.
Oops. No. It fits height to the number of lines given by fit_lines.
>> I think the original version has some additional behaviors such as >> fitting height of the opened window if there is not much contents when >> window="othere" and fit_lines=True.
> Oops. No. It fits height to the number of lines given by fit_lines.
Now most of the path is common between the cases. Also mentioning the new variable in "Variables" section of ropemacs and adding a defcustom in ropemacs/__init__.py can help users that need the same feature.
It works almost fine, but I found another issue with
lisp.bury_buffer(new_buffer) since it is in the execution path even if
I set ropemacs-use-pop-to-buffer to t now.
popwin.el decide whether to close the created window by watching if
the buffer is buried (there are other conditions). Therefore, it
won't show the document buffer created by rope-show-doc. It is not
ropemacs's bug or anything, it's just that two emacs modules do not
play well together. I don't know what is the best way to solve this.
I can ask popwin's author to workaround this somehow.
However, I think burring the buffer *after* reading it makes more
sense than burring it at the time it is created, *before* reading it.
So I hope you don't mind if I remove the line containing
lisp.bury_buffer(new_buffer). Another possible fix is to add new
customization variable to choose the behavior. (Also, I don't
understand why lisp.bury_buffer(new_buffer) is called only when
window='other' and fit_lines is specified. So if we are going to
choose the second fix, please specify the execution path in which it
should be located)
Takafumi
On Feb 13, 4:36 am, Ali Gholami Rudi <aligr...@gmail.com> wrote:
> Now most of the path is common between the cases. Also mentioning the
> new variable in "Variables" section of ropemacs and adding a defcustom
> in ropemacs/__init__.py can help users that need the same feature.
> It works almost fine, but I found another issue with > lisp.bury_buffer(new_buffer) since it is in the execution path even if > I set ropemacs-use-pop-to-buffer to t now.
> However, I think burring the buffer *after* reading it makes more > sense than burring it at the time it is created, *before* reading it. > So I hope you don't mind if I remove the line containing > lisp.bury_buffer(new_buffer). Another possible fix is to add new > customization variable to choose the behavior. (Also, I don't > understand why lisp.bury_buffer(new_buffer) is called only when > window='other' and fit_lines is specified. So if we are going to
As far as I remember, bury-buffer is called to put the buffer at the end of the buffer list since you never want to switch back to this buffer, specially with fit_lines: you want to show a window in as small as possible room and then close it with C-x 1.
> choose the second fix, please specify the execution path in which it > should be located)
Any of them seem OK. Maybe it is cleaner to put the incompatible stuff in the else block of self.get("use_pop_to_buffer").
On Wed, Feb 22, 2012 at 4:49 PM, Ali Gholami Rudi <aligr...@gmail.com> wrote:
>> However, I think burring the buffer *after* reading it makes more >> sense than burring it at the time it is created, *before* reading it. >> So I hope you don't mind if I remove the line containing >> lisp.bury_buffer(new_buffer). Another possible fix is to add new >> customization variable to choose the behavior. (Also, I don't >> understand why lisp.bury_buffer(new_buffer) is called only when >> window='other' and fit_lines is specified. So if we are going to
> As far as I remember, bury-buffer is called to put the buffer > at the end of the buffer list since you never want to switch > back to this buffer, specially with fit_lines: you want to show > a window in as small as possible room and then close it > with C-x 1.
I understand that point. What I was saying that calling bury-buffer after reading the buffer is more consistent behavior. For example, when you do M-x describe-function, *help* buffer is opened and it has quit-window bound to key q, which does bury-buffer internally. So the buffer is not buried when the user is reading it. The buffer is buried only when the user quit the window by pressing q. If the user want see some other buffer and go back to the *help* window, he can choose not to push q and do C-x b.
Furthermore, functions which use _make_buffer, show_occurrences and show_doc, bind similar commands to q. This binding makes no sense if you already bury buffer in _make_buffer. So, I think deleting lisp.bury_buffer(new_buffer) is better choice (I changed my statement a little bit after finding about show_occurrences and show_doc). What do you think?
Takafumi Arakaki <aka....@gmail.com> wrote: > > As far as I remember, bury-buffer is called to put the buffer > > at the end of the buffer list since you never want to switch > > back to this buffer, specially with fit_lines: you want to show > > a window in as small as possible room and then close it > > with C-x 1. > I understand that point. What I was saying that calling bury-buffer > after reading the buffer is more consistent behavior. For example, > when you do M-x describe-function, *help* buffer is opened and it has > quit-window bound to key q, which does bury-buffer internally. So the > buffer is not buried when the user is reading it. The buffer is > buried only when the user quit the window by pressing q. If the user > want see some other buffer and go back to the *help* window, he can > choose not to push q and do C-x b.
My emacs skills are quite rusty and I may be wrong. So be warned!
When window equals "other" and fit_lines is specified, you usually don't switch to the buffer, so the q command probably won't be used.
> Furthermore, functions which use _make_buffer, show_occurrences and > show_doc, bind similar commands to q. This binding makes no sense if > you already bury buffer in _make_buffer. So, I think deleting > lisp.bury_buffer(new_buffer) is better choice (I changed my statement > a little bit after finding about show_occurrences and show_doc). What > do you think?
Only if it is backward compatible. Otherwise I suggest not calling bury-buffer() in the pop-to-buffer case. Specifically, after rope-show-doc (C-c d), and then using C-x 1 to close *rope-pydoc* buffer, it should not appear high in the buffer list.
On Thu, Feb 23, 2012 at 4:48 PM, Ali Gholami Rudi <aligr...@gmail.com> wrote:
> When window equals "other" and fit_lines is specified, you usually don't > switch to the buffer, so the q command probably won't be used.
>> Furthermore, functions which use _make_buffer, show_occurrences and >> show_doc, bind similar commands to q. This binding makes no sense if >> you already bury buffer in _make_buffer. So, I think deleting >> lisp.bury_buffer(new_buffer) is better choice (I changed my statement >> a little bit after finding about show_occurrences and show_doc). What >> do you think?
> Only if it is backward compatible. Otherwise I suggest not > calling bury-buffer() in the pop-to-buffer case. Specifically, after > rope-show-doc (C-c d), and then using C-x 1 to close *rope-pydoc* buffer, > it should not appear high in the buffer list.
You are right, the focus does not go to the *rope-pydoc* buffer. I was not aware of that. I guess I understand why you want to bury buffer at the time the buffer is created; you want to make the buffer virtually never opened, right? And it makes sense because you do not move the focus to the buffer.
Please choose the version you like. I think my old version is clearer, although the execution path is completely separated. If anything needed to be changed, let me know.
> Please choose the version you like. I think my old version is > clearer, although the execution path is completely separated. If > anything needed to be changed, let me know.
