cboard community project

[MK27]

Talking about "unintuitive as vim": that's exactly what I like about my idea. With an independant core, the user is free to choose whatever client interface he wants to use (think of blinking OpenGL GUIs and conservative ncurses-like console interfaces). AFAIK all our current editors don't separate the view/control from their respective core unit, which makes it hard to modify things, let alone porting the software to a new environment, e.g. cell phones/toasters. With an interactive core, it will be easy to come up with new clients for different platforms and different needs. My guess is that any decent Perl programmer should be able to build a full-featured client in less than a week (add another week for C).

When I first read this I thought it was a neat idea, however, if you think about it a little more deeply you might recognize it is almost oxymoronic: the most the "independent core" might hope to be is a conceptual framework and not an actual coded interface (a back end for the user-interface front-end).

In other words, you cannot write an integrated "text editor engine" or something that could be implimented this way. You could write a limited set of functions that could be used, but many of the "conceptual connections" between such functions would have to be just that, because they would be implemented completely in the front-end; there will be no place for them beyond the programming of the actual interface, whether it is Qt or ncurses, etc. So you could create an independent library of features as applicable, and then an abstract which describes the functioning of the front-end, but I am sure you will quickly find that is impossible or pointless to try creating a functional process that will "interact" with an independently coded GUI. "Quickly", as in the day you start actually coding.

Not to ixnay the whole idea, just to provide some perpective.

[Brafil]

What about functions like substitute(this, that) or refresh()? I agree, it would be difficult.

We need a project that's very versatile. What about a new standard C Library? ;-p

[MK27]

What about functions like substitute(this, that) or refresh()? I agree, it would be difficult.

Sure, as I said you could have a library of functions for use in text editors. My point is that some features would lend themselves to the concept (working on text independent of the interface) but many would be have to be implemented directly using an API (be it Qt or ncurses or whatever) and you will have a problem trying to create two layers where, logically, only one can have any meaningful significance.

Also, I guarantee that Snafuist has it backward:

My guess is that any decent Perl programmer should be able to build a full-featured client in less than a week (add another week for C).

The time consuming complicated part will be writing a front-end user-interface (client) to work with the back-end conceptual engine (which will be orders of magnitude simpler, just as with a web server/client relationship, conceived of on a one-to-one basis, would mean the server is much, much simpler than the client). I'm sure anyone familiar with GUI programming will concur*, and console text interfaces (eg ncurses) are much the same story. So, once again, you are looking at a library (which is not at all a bad idea, but lets call a car a car).

*if you want my longer winded technical explanation of why, you can ask...

[Brafil]

No need, I believe you're right.

[brewbuck]

Snafuist, your concept sounds a lot like what is in Emacs called a "buffer." A dynamic data structure whose sole purpose is to maintain line-based text and allow arbitrary operations on it. In Emacs, these operations are described in a Lisp-like language called Emacs Lisp.

Not that reinventing the wheel is bad. It's just that I've heard this before. Everybody always wants to make a game, the world's best text editor, or a compiler. The problem is in finishing the project...

I don't have a strong opinion what people decide they want to do. I'll just act as coordinator. Actually writing code is kind of an iffy proposition for me since I have some "interesting" employment contracts.

[MK27]

Snafuist, your concept sounds a lot like what is in Emacs called a "buffer." A dynamic data structure whose sole purpose is to maintain line-based text and allow arbitrary operations on it. In Emacs, these operations are described in a Lisp-like language called Emacs Lisp.

In GUI programming (well, I know gtk) the text buffer is also a distinct entity from the "text view" (or presentation), but this is trivial. You can, of course, perform any operation you want on the buffer -- w/ my last project you can eg, process the buffer on view with an external command (which could be a script, etc.) but this is not to say that writing an editor independent of the interface would be a useful undertaking. You can already write scripts to process text -- that's normative.

I don't have a strong opinion what people decide they want to do. I'll just act as coordinator. Actually writing code is kind of an iffy proposition for me since I have some "interesting" employment contracts.

I think you & zacs7 should step up then with the "build thing" and start coordinating/organizing! Otherwise I will just play pundit 'til the cows come home

[Brafil]

Yeah, agree. Maybe you could give some more proposals and/or work the given ones out. We should make a poll. Really. Explaining what needs to be done for what.

[brewbuck]

Yeah, agree. Maybe you could give some more proposals and/or work the given ones out. We should make a poll. Really. Explaining what needs to be done for what.

I'll post a poll a bit later today. Snafuist is working on getting a server set up for source code hosting. I'll keep you folks updated.

[Brafil]

Great Idea! What will we use? SVN? CVS? git? Bazaar? Maybe poll again

[brewbuck]

Great Idea! What will we use? SVN? CVS? git? Bazaar? Maybe poll again

At this point it looks like SVN, but I wouldn't mind git either. It would take a loaded gun to convince me to use CVS

[Brafil]

I think many people use SVN. I'm starting to learn.

[Snafuist]

Snafuist is working on getting a server set up for source code hosting.

The server (2GHz, 1GB, 20GB, ~6MB/s into the internet) is already running, but it isn't reachable from the internet yet. The guys at our computing center expressed a certain hope that it will work tomorrow, but we'll see... So far, it is running SSH, Apache and an SVN server. brewbuck, laserlight and me will take care of the administration.

Funny story: yesterday, I called the responsible guy at the computing center and explained the situation (i.e. I have a server running WWW, SSH, SVN and need an IP reachable from the internet), and he said "write me an email". So I wrote him an email, again explaining everything which might be of interest to him. An hour later, he replied: "call me". At this point, I was a bit concerned that we're entering some kind of an infinite loop, but when I called him today, I had the impression that they're now finally starting to do their job.

Let's see what happens tomorrow.

Greets,
Philip

[zacs7]

Personally, I don't think yet-another-editor is a good idea. Everyone seems to already have their preference, why would I use anything other than vim? And emacs when I'm _really_ forced to

A native build system is rather useful, especially for small projects.

> It would take a loaded gun to convince me to use CVS
What about RCS?

[brewbuck]

> It would take a loaded gun to convince me to use CVS
What about RCS?

Ugggh... Talk about pain. For nine years I worked on a 1.5 million line application that was source controlled entirely with RCS. And that was by choice (not my choice). I don't even want to describe the horror of branching to do a release, the terrors of compulsory locking, the absolutely fear-inducing way that RCS stores the repository files in the same source tree with the active codebase...

Over time I came up with a several-thousand line bash script just to lessen the pain.

[Brafil]

Yeah... I see how terribly some programs can be. But what about the poll? [/impatiency]