sxemacs-devel
[Top] [All Lists]

Re: Todo List (aka Lets get busy)

From: "Johann 'Myrkraverk' Oskarsson" <johann@xxxxxxxxxxxxxx>
Subject: Re: Todo List (aka Lets get busy)
Date: Sun, 23 Jan 2005 11:10:19 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)
Steve Youngs <steve@xxxxxxxxxxx> writes:

>   o Johann's "window number patch".
>
>     Johann, are you able to put this together for 22.1.2?

Since I use this as much as I use emacs itself, it follows that this
will be in my very first merge request ;)

Good news are, I'm finally going to build the stuff today, so porting
the patch should be done by tonight, if I can find the 21.4 version
that is.  I've no idea where I put it.

>  o New concept of what a "buffer" is.
>
>    Evgeny needs to explain this, but basically a buffer is nothing
>    more than a string.  Evgeny wants more. :-)

So do I.  Among other things I've researched, is embedding
StarOffice/OpenOffice windows inside SXE.  I've only recearched the SO
side of that project but assuming I can do a UNO binding and actually
display a doc in a window, what would I do with self-insert-command?
I think I need a different kind of buffer somehow to make this as
painless as possible.  That is, that SXE knows about different kinds
of buffers.

Also, I think it's been 10 years since we should have had the notion
of a local mode, such as java-mode in javascript in html buffer.
Hasn't javascript been used in html since like '95 or '96?  I don't
know what'd be involved but maybe a rich buffer would help.

>   o New widget toolkits.
>
>     Should SXEmacs be "skin-able"?

That's a good question, but I'm not sure we'd want to.  I think that'd
mean implementing the skinning in every new window system.  We're
currently using X, but I'm hot for Qt as well (remember, as embedded
it's its own window system, and not just a toolkit), there's a patch
for the Be window system I'd like to backport, I'm sure we want GTk 2
as well and maybe Carbon and others I'm not aware of right now.

If there's a way to do it without re-implementing for each toolkit, I
might go along with it, but I'm not really hot for skins at the
moment.

>   o "Embeddable" buffers.
>
>     |-----------------------------------|
>     |            Buffer A               |
>     |                                   |
>     |        |-----------------|        |
>     |Buffer A|    Buffer B     |Buffer A|
>     |        |                 |        |
>     |        |-----------------|        |
>     |            Buffer A               |
>     |-----------------------------------|
>
>     ...in a single frame.

I had been thinking of window-gutters too, and maybe they would be
related to this project?  Remember that a window gutter and a buffer
are 2 different things.  A buffer can be shown in 2 or more windows,
and each of those can have it's unique window-gutter with unique stuff
in (such as the window number).

Also, we need to drop the current implementation of the modeline, I
think.  The code is horrible and buggy, and has been buggy for years.

I was thinking we could drop it once window-gutters were in place, and
emulate the current behaviour (when needed) or something with them.

I'm not sure how that'd be done, but I was thinking a new style of a
modeline, with the old style emulated for legacy applications.
Probably some smart detection scheme is needed for that, but I'm sure
we can do it.

>   o Display _anything_ in a buffer.
>
>     Including full motion resizable video.

I think my idea about different kinds of buffers would facilitate
this.  Also, we need to be aware of what happens when somebody brings
forth a video buffer on tty.  If we have AAlib we can use it, but we
also need to be able to deny showing the buffer on this device.  I
think it's foolish to make AAlib a requirement.


Oh, and what about mouse enabled menu in tty?  I think ncurses have
all we need to implement it.

                                 ***

I think that's all for now folks, have fun,

Johann


-- 
This line is left blank intentionally


<Prev in Thread] Current Thread [Next in Thread>