On Sep 9, 4:06 am, "Corey O'Connor" <coreyocon...@gmail.com> wrote:
> On Tue, Sep 8, 2009 at 6:45 PM, Wen Pu <dexte...@gmail.com> 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 coreyocon...@gmail.com
> * 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.
I have looked at this change, but why should not use path as buffer
name?
-Wen
>
> 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<berna...@chalmers.se> 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 <codesite-nore...@google.com>:
>
> >>>> 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
yi-devel@googlegroups.com
http://groups.google.com/group/yi-devel
-~----------~----~----~----~------~----~------~--~---
