On Tue, Sep 8, 2009 at 6:45 PM, Wen Pu <[email protected]> wrote: > > It seems these changes on minibuffer have affected the behavior of > Misc.promptFile > > maybePath <- withBuffer $ gets file > > maybePath always returns working directory, while the preferred > behavior is returning the path associated with current buffer. >
Can you give some steps to reproduce the issue you are seeing? From my testing Misc.promptFile is performing as expected. Also try reverting the changes in the patch: Mon Sep 7 09:45:49 PDT 2009 [email protected] * use a temp buffer for Dired mode. Pull/put filepath of dir from DiredState I changed how Dired mode stored the current directory being viewed. Perhaps that caused the issues. Cheers, Corey O'Connor > On Sep 8, 2009, at 1:12 PM, Corey O'Connor wrote: > >> >> On Tue, Sep 8, 2009 at 12:05 AM, Jean-Philippe >> Bernardy<[email protected]> wrote: >>> >>> I thought you had reverted the code that inserts the minibuffer at >>> the >>> end of the window list... Maybe this has crept in again. Feel free to >>> remove this and add big warning around explaining why it's done that >>> way. >> >> I had thought so too... I was occupied by other projects for a while >> and didn't pay attention to yi. So I presumed that the >> minibuffer-on-bottom was a settled issue. >> >> I suppose now it can be an option. Though I dislike the onCloseBufferE >> actions since they seem dangerous to me. Though I can't think of a >> case that would cause problems at this point. >> >>> The backstory: we rely on the minibuffer being inserted right after >>> the buffer that it refers to. The command run in the minibuffer will >>> apply to the buffer right on top of it. >>> This simplifies the design, and allows the UI to show the minibuffer >>> and the related window together. >> >> I absolutely agree. I don't think we should stick with the UI >> convention of having the minibuffer detached from it's target window. >> That behaviour probably originated back when terminals had dedicated >> status lines. Placing the minibuffer right next to the target window >> makes more sense. >> >> I'll revert the mini-buffer-on-bottom code but I'll keep the other >> changes. I suspect we'll find a reason to want to remove, or limit, >> onCloseBufferE. But I also suspect somebody may find a nice feature >> that requires onCloseBufferE. So I'll leave those till later. >> >> Cheers, >> Corey O'Connor >> >>> 2009/8/31 codesite-noreply <[email protected]>: >>>> >>>> Status: Accepted >>>> Owner: coreyoconnor >>>> Labels: Type-Defect Priority-Medium Component-UI-Vty Component- >>>> Keymap-vim >>>> >>>> New issue 297 by coreyoconnor: minibuffer actions applied to >>>> incorrect >>>> window >>>> http://code.google.com/p/yi-editor/issues/detail?id=297 >>>> >>>> 0. open file A. >>>> 1. split window (C-w-s) >>>> 3. open file B in the bottom window. >>>> 4. Insert text into file B. >>>> 5. Save from the window viewing file B. >>>> >>>> The expectation is that file B will be saved. Instead file A will >>>> be saved. >>>> >>>> Please use labels and text to provide additional information. >>>> >>>> >>>> -- >>>> You received this message because you are listed in the owner >>>> or CC fields of this issue, or because you starred this issue. >>>> You may adjust your issue notification preferences at: >>>> http://code.google.com/hosting/settings >>>> >>>>> >>>> >>> >>>> >>> >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list [email protected] http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
