1. enter into some non-home directory, say, $cd ~/project/yi/ 2. $yi (with emacs keymap) 3. C-x C-f, current directory will be prompted. type in another directory, such as "~/" 4. type C-x C-f in the dired buffer for "~/"
I'm prompted ~/project/yi instead of ~/ -Wen On Sep 9, 2009, at 4:06 AM, Corey O'Connor wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
