Steve Youngs <steve@xxxxxxxxxxx> writes:
> * Johann Oskarsson <Johann> writes:
>
> > Steve Youngs <steve@xxxxxxxxxxx> writes:
[...]
> >> 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?
>
> OK, to me, you are talking about 2 different things here.
>
> 1) Embedding an SO/OO window in a SXEmacs buffer. In this situation
> you wouldn't want `self-insert-command' (or any other SXEmacs
> command, except for a few like C-x b etc), you'd want SO/OO
> commands available to you.
>
> 2) Displaying a SO/OO document in a SXEmacs buffer. In this
> situation it'd be a raw file (no SO/OO involved) and you'd want
> all SXEmacs commands available as normal.
As usual, we never manage to speak the same language, and I'm sure
it's to do with something else than just geographical distances.
3) Display a SO/OO doc in a SXEmacs window/buffer. Do not use any
SO specific keybindings and do everything with UNO bindings.
Frankly, I see no advantages in having SO docs in SXE without the
usual behavior of C-n, C-b, etc. That of course means creating a
SO mode for such docs or something, but I think it might be worth
it.
Btw, does gnus allow you to auto-fill the numbers like you put them?
> You'd probably have `M-x visit-file-externally' to visit an SO/OO
> document inside SO/OO inside SXEmacs. `visit-file-externally' would
> prompt for the external app to use (with completion from supported
> list of external apps, configurable default of course), and then
> prompt for the filename.
Well, alternatively, C-x C-f on a .sxw file and it simply shows up in
SO buffer. Though I see no reason to leave out the stuff above.
> Sounds pretty darn sexy to me. :-)
>
> > 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.
>
> You're 6 years too late. We've been able to do this since 1999 when
> mmm-mode.el first came into being. :-) There's an XE package of the
> same name, "mmm-mode". Check it out.
Well, what I mean is, that the mode is locally bound in the buffer,
and ditch the notion of a major mode as it is. I do know about mmm
mode, but I've also heard it doesn't work too well all the time.
What I'm thinking is: text mode in comments, main language most of the
time, and a 2nd language some of the time, sometimes in comments I
suppose. I don't know what PHP sources look like, but I suppose
that'll be one such language, and maybe there's a need for a java mode
with it too (3rd language). That'll mean 4 modes in a buffer.
> >> 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
>
> There's a Qt branch of XEmacs in the XE CVS. It got checked in, one
> or two patches were committed, and then it was left to rot. Nobody
> has touched it since it was originally checked in. I tried building
> it once, doesn't build.
I was actually thinking of doing Qt stuff from scratch, but I may take
a look one day.
> > I'm sure we want GTk 2 as well
>
> I won't block GTK or QT, but don't ask me to run with either, I can't
> stand either of those toolkits. I'm one of those strange people who
> actually likes (and prefers) the current UI look/feel. :-)
I won't, I'm no fan of the current UI, but I'm not going to want to
ditch it.
> > 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.
>
> Me either. Personally I think skins would give SXEmacs too much of a
> "gimicky" image. But if someone gets "itchy" in this area...
>
> >> o "Embeddable" buffers.
>
> > 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).
>
> I'm not sure what you are getting at here? We already have gutters.
Yes, frame specific, not per-window, there's a difference.
>
> > 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 don't agree with that (at least not yet). Specifically, why is it
> horrible? What/where are the bugs.
1) There's a horrible reqursion depth bug. If you nest stuff too
deeply in the modeline, the deep stuff disappears. Increasing the
recursion depth may fix it, but I'm sure there's a better way
somehow.
2) The modeline doesn't merge faces. After all these years, I'm
not sure which is worse, the fact that it doesn't or the fact that
it needs to. Faces should probably inherit each other anyway.
IIRC, that's what FSF Emacs does.
You should be aware that I have fiddled with the code, and I've seen
the comments, they're horrible. Maintainance wise, it's also an utter
nightmare, I think.
> >> 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.
>
> Simple, don't allow it to happen.
Or make use of AA lib, do you know what it does? It displays images
by rendering them in ascii (not art though).
> > Oh, and what about mouse enabled menu in tty? I think ncurses
> > have all we need to implement it.
>
> Just a couple of days ago I was reading about enabling rats in ttys.
> I'm not sure if it was on the XE mailing lists or on c.e.x.
> Basically, I think it's been done (don't quote me on that though).
Rats and rat enabled menu isn't the same thing. You may not be aware
of it, but XE doesn't have any visible menu in the tty. FSF Emacs
does, but uses some menu emulating mode (with buffers) as an
implementation, the top menu is just eye candy/waste or screen real
estate. Of course, I should look at what the rats are all about
before I complain anymore.
Johann
--
This line is left blank intentionally
|