[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: idea -> internal frames?

From: Richard Stallman
Subject: Re: idea -> internal frames?
Date: Tue, 30 Oct 2001 19:50:41 -0700 (MST)

    Maybe.  Special frames like speedbar would probably have custom
    commands jump the their frames if desired.  If there is no generic way
    to get to these windows/frames, then it would be tough for a
    programmer to fix mistakes on a terminal.

(With this feature, these would not be special frames;
they would not be separate frames at all.  They would
be special windows.)

Ok, so these windows should be selectable with select-window,
like any other window.

    > next-window would normally not see them, but there could be a special 
mode in
    > which it does see them.  Or each of these windows could have a flag which
    > controls whether next-window will see it.

I think we need to have two modes of next-window.  That way,
walk-windows will automatically have two modes too.  Then those things
that really need to see *all* windows can see these windows, while
they are invisible fo rordinary commands such as C-x o.

It will be necessary to figure out the best way to specify the args
for next-window for this.  Does someone want to do it?  If it can be
done using new values of the existing args of next-window, without
adding any new args, that would be good, because many other functions
that call next-window would automatically get the new feature in
a compatible way.

    A bug that annoys many w/ speedbar is when they try to close the frame
    which hosts Speedbar's minibuffer, at which time it throws an error.
    Such a walk-windows feature would allow some bit of code to seek out
    frames whos minibuffers are hosted in such another frame.

Why does Speedbar use a minibuffer for this?  That seems like a very
bizarre and inconvenient thing to do.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]