Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Simple Text Editor... #6

Open
BradWBeer opened this issue Dec 14, 2012 · 4 comments
Open

Create Simple Text Editor... #6

BradWBeer opened this issue Dec 14, 2012 · 4 comments

Comments

@BradWBeer
Copy link
Owner

Create a simple text editor for changing code without requiring a return to Emacs.

@smithzvk
Copy link
Collaborator

I am confused what this text editor would be used for. Do you intend to have a window pop up within the CLinch window, similar to the repl that Blocky.io implements? Having a repl with symbol completion is probably about as far as we should bother in this direction (kind of like the Quake console).

I, and I expect many others, wont want to use a half-assed text editor, even for quick edits. For instance, look at Blender, there is nothing more annoying than editing Python scripts via the built in Python editor because, let's face it, it's no Emacs and it won't be without another decade of development.

I imagine that this is geared towards the following scenario: you're playing a game in full screen, some bug pops up, you open a text window and make a few edits and voila, bug fixed on the fly. I don't think that this is the primary way people will use this, or I should say, the primary way people should use this. Imagine two windows side by side or multiple desktops for hobbyists, or in the case of more serious shops multiple monitors or even a game system running the game and a network connected machine running Emacs connected to the game machine via Slime. Swank, Slime, and Emacs are all good pieces of technology that should be leveraged as best we can.

I mean, it's fine for a fallback, but it shouldn't be a primary focus, IMHO.

@BradWBeer
Copy link
Owner Author

Perhaps I'm being seduced by the dark side here. My next step (after issues 2 & 3) it to port a presentation I gave a while back. I used "Qix" at the time to create powerpoint style slides and then had them rotate in a big 3D circle as a demo for doing productivity software in 3D. Using Pango and Cairo I created very rich slides and it was fairly simple to do, I'll post it as a sample as soon as I port it to CLinch. I have some slides but I left them on my zip drive...at work. Also, I want to post the presentation on youtube as soon as I get everything working.

Having Pango makes it very tempting to create rich text. What I would assume would happen, and let me know if my logic is flawed (very likely, I have a cold); but if you had access to an in-application REPL and you could type in text, even if it is fairly simple I would expect people to start adding functions and such to manipulate one from the other. This would create very organic style growth as people modify items as they develop other things. The trick is to make it very simple and accessible so if I wanted to add syntax highlighting I could simply create a quick function and run it on my buffer. The same thing with indenting, etc.

Then again, I may be shooting for my super-app rather than fulfilling user needs. Thoughts?

@smithzvk
Copy link
Collaborator

We clearly had pretty similar thoughts about what we could do with a package such as this but you are a few steps ahead of me. I have been toying around with making an "super powerpoint" as well and recently (as in the last time I worked on it) got a proof of concept working with text and Cairo/Pango in my GLUT based old school stuff. Glad to see other people are thinking like me. One of the cool bits was the idea of inserting simulations directly into the slides, like inserting a live Ising model or Game or Life where you could edit the parameters for that simulation and see them show up live on the slide. So I really like that idea, but I never thought of putting an editor inside the slide. That seems like it would only really be useful in certain special cases such as if you were teaching a lesson on how to program Conway's Game of Life or something. I was thinking that a few simple text fields or slider bars were more appropriate. I have other cool ideas about how you could use something like this, but I digress...

I think that your post title on Reddit lead me to think that this was about games and not what it appears to really be, a system very much like Blocky.io or the graphical SmallTalk set ups I remember playing with long ago. It could be used for a game, but is more about easily visualizing Lisp; does this sound about right? If so, I was very confused, but in the end we have been working toward the same goal all along. If this is about games, it is a severe mistake to split your attention between these very different things. If there is a factorable component, such as the underlying graphics engine, such that it is applicable to both presentations and games, we will be able to factor it out later after there is something up and running. This is one of the things that working in a high level language and using abstractions provides us.

...even if it is fairly simple I would expect people to start adding functions and such to manipulate one from the other. This would create very organic style growth as people modify items as they develop other things. The trick is to make it very simple and accessible so if I wanted to add syntax highlighting I could simply create a quick function and run it on my buffer. The same thing with indenting, etc.

This sounds very much like heading down the road to remaking Emacs or something similar along with its entire ecosystem of developers. As a point of perspective, indentation and syntax highlighting are far from done deals in Emacs, they are messy contentious issues. What makes you think that they won't be inside CLinch. Suffice it to say, I think it is a bad idea to spend more than a couple days on this (in total, I mean for the life of the project) because I think is of little value. It is a solved problem that you want to make unsolved again. The engineering feat is making Emacs or any other editor fit into the work-flow. That said, don't let my opinion stop you.

@BradWBeer
Copy link
Owner Author

That said, don't let my opinion stop you.

Well, this is a library not an application. After I've had some time to think about it I realize you are correct. (Which is why collaborators are so important.) I'm still thinking in "Qix", my superapp. I just carried through the need for a text editor in the base as a given. It's not. Also, I'm making Pango (which gives me the rich text layout) and Cairo (which draws it) optional. If text editing goes anywhere it would be the clinch-pango package.

I think you are right that most people will just use this from Emacs/Slime. A text editor is not really necessary to "live" code. Finally, there are many issues, such as user input which are windowing library dependent. The more I thought about it the worse it became.

In the (far flung) future I may add a REPL and Text Editor Plugin, but I (or we, if I'm not being presumptuous) should focus on core functionality. I'm pulling this from the next release and marking it as a "science project". If someone needs it, they can make it.

Also, my focus is writing games. That's where I need to be. It can still be used to make slides and such, it just won't be WYSIWYG for while.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants