[arch-projects] Modular Text Editor
If this has been done, I'd really like to see where. I'm really getting tired of the messy hacks that text editors tend to be, with features I never use and so forth. I want to build a text editor that allows you to install features one at a time (sounds like the archwm philosophy, eh?)
I don't have time to do this, I was wondering if I could gain support. Basically, here's what I'm thinking:
There is an extremely simple main editor component (written in python). This provides basic text editing and an extension/plugin/macro language.
Then you can use import statements in a config to import editor modules that you are interested in. Such modules would provide syntax highlighting, keyboard shortcuts, menubars (I'd never install this, but somebody else might), toolbars (ditto), code completion, abbreviations, search and replace etc.
Finally, you can have usually very short configuration scripts that provide additional customizations (set up your keyboard shortcuts, syntax colours, etc) or macro-like features in your home directory. If possible, it would be cool if these short scripts could be scripted in languages other than python
Question 1: How is this different from <insert-favourite-text-editor>?
Answer 1: Maybe its not. Maybe you have an editor that I would like to use. I really don't want to write my own editor, but none of the existing tools are elegant enough for me. Please tell me about it, especially if its not a common editor.
Answer 2: There is an editor that is similar to what I want. Its known as vim. I have some issues with vim though -- its a real pain to configure, its syntax is what I consider ugly. I don't want to learn yet another language just to configure my editor (Actually, I know how to script vim so I don't have to learn it, but neither do I want to look it up).
Answer 3: There is an editor that is similar to what I want. Its known as emacs. Same issues. I mean... Lisp???
Answer 4: There is an editor that is similar to what I want. Its known as JEdit. I've been using JEdit for years. But I'd like something that's a little more streamlined. JEdit has a beautiful Java plugin architecture, and a beautiful beanshell macro interpreter. I don't see why plugins and macros should be different, for example. It also suffers from the same issues as the previous answers -- I mean.... Java? I would borrow a lot of cool ideas from JEdit though if I could.
Answer 5: The key thing about my vision of an editor is that each feature is totally optional. It doesn't have "built-in" anything. BUT installing a feature should be as easy as importing some python module. keep it SIMPLE SIMPLE SIMPLE. The main reason for this is I like to rebind practically ALL my keyboard shortcuts, and usually the ones I like are bound to actions I never use, and unbinding them is.... tricky.
Question 2: Why reimplement the wheel?
Answer 1: Its all been done. This frustrates me. I really don't want to waste time implementing a text editor right now, but I spend so much time in my editor, I'd like something that's got even better HCI than JEdit. That does exactly what I want, not just almost exactly what I want.
I've looked at several editors, focusing on python editors lately. There's apparently nothing that suits me. But I don't want to start from scratch. I'm thinking of borrowing from xerces2's lazy-edit (http://xerxes2.1go.dk/python/python_start.php?kap=program.html), and a project nobody's worked on for a while called pyeditor (http://www.rexx.com/~dkuhlman/#special-purpose-scriptable-text-editors) -- the idea behind this project is almost exactly what I want, it just didn't get finished.
Answer 2: I really don't want to create an IDE. I want a text editor. Terminals have a purpose, you don't have to embed them into your editor, for god's sake! Debuggers can be run externally. Code navigators..... ok, maybe. The point is, if somebody else wants one of these things, they can create a new module to provide that functionality *without* causing me any pain -- I just won't install it!
Question 3: Who's involved?
Answer: If nobody would join me, I can't do this on my own at this time, too busy. :-(
At this point, I'd like to BEG xerces2 to take an interest in this project, because he's pretty good with PyGTK and has done an editor already. I'd also like to see Mr. Green on board because he's got a pretty good grasp on what sucks in an interface. As an HCI student, I'm learning that those of us who call ourselves programmers are not the best people to be designing user interfaces. Actually, I've been repeatedly beat over the head with this fact... but I digress.
I think it would be wonderful to see phrakture and cactus join me, but phrakture is a C++ guy. He's got all that free time though, so maybe he'd make some C++ modules to be embedded in the python interpretter.... Cactus.... well I'd really like to have somebody helping that could help make ruby and python cooperate in this project so that it would fully satisfy both python and ruby programmers.
I'd also like to see Xentac and iphitus (python programmers) join me, but I think I'm starting to ask for too much now. Wishful thinking can only go so far. ;-)
Question 4: How would you proceed?
Assuming I can get at least one good programmer interested in the project (begging xerces2 again, plus anybody else... lol I have no shame), I think I would do the following:
Start with lazy-edit and refactor it to allow for fully modular extensions. The extension interface is pretty much the *only* property of the editor itself, besides support for a buffer. I would take out syntax highlighting and the tabbed interface and put them in extensions of their own. This would help test the extension interface. The extension interface would be comprised of allowing extensions protected access to the user interface itself, and providing some sort of 'actions' framework to allow extensions to register actions that could be called back somehow.
I would then go on to enhance the syntax highlighting module. It would be nice if it were not necessary to rewrite 'edit modes' for every syntax available. The cool thing would be to steal edit modes from some other editor... JEdit has XML based edit modes; I'm toying with that idea, but I'm not too fond of XML.
Then I would work on a totally generic keyboard shortcuts module. It should be fully chainable and beautiful.... configurable in Python. The #1 worst thing in every single editor I have ever used is the horrible GUI interface for customizing keyboard shortcuts.
Once I have these two things, I have the two things that I consider really important in a text editor. At that point, I will probably start adding little things here and there as I need them, since I will be using the editor full time.
I'm not terribly excited about this project. Its just something I feel resigned to do because no editor I currently use behaves in the way I think it should. I want to believe nobody else likes their editor either, and that our connection (The Arch Philosophy) will allow you to think that this is a good idea.
Suggestions are definately welcome.
Thanks for your time, Dusty
Dusty Phillips wrote:
If this has been done, I'd really like to see where. I'm really getting tired of the messy hacks that text editors tend to be, with features I never use and so forth. I want to build a text editor that allows you to install features one at a time (sounds like the archwm philosophy, eh?)
I don't have time to do this, I was wondering if I could gain support. Basically, here's what I'm thinking:
There is an extremely simple main editor component (written in python). This provides basic text editing and an extension/plugin/macro language.
Then you can use import statements in a config to import editor modules that you are interested in. Such modules would provide syntax highlighting, keyboard shortcuts, menubars (I'd never install this, but somebody else might), toolbars (ditto), code completion, abbreviations, search and replace etc.
Finally, you can have usually very short configuration scripts that provide additional customizations (set up your keyboard shortcuts, syntax colours, etc) or macro-like features in your home directory. If possible, it would be cool if these short scripts could be scripted in languages other than python
Question 1: How is this different from <insert-favourite-text-editor>?
Answer 1: Maybe its not. Maybe you have an editor that I would like to use. I really don't want to write my own editor, but none of the existing tools are elegant enough for me. Please tell me about it, especially if its not a common editor.
Answer 2: There is an editor that is similar to what I want. Its known as vim. I have some issues with vim though -- its a real pain to configure, its syntax is what I consider ugly. I don't want to learn yet another language just to configure my editor (Actually, I know how to script vim so I don't have to learn it, but neither do I want to look it up).
Answer 3: There is an editor that is similar to what I want. Its known as emacs. Same issues. I mean... Lisp???
Answer 4: There is an editor that is similar to what I want. Its known as JEdit. I've been using JEdit for years. But I'd like something that's a little more streamlined. JEdit has a beautiful Java plugin architecture, and a beautiful beanshell macro interpreter. I don't see why plugins and macros should be different, for example. It also suffers from the same issues as the previous answers -- I mean.... Java? I would borrow a lot of cool ideas from JEdit though if I could.
Answer 5: The key thing about my vision of an editor is that each feature is totally optional. It doesn't have "built-in" anything. BUT installing a feature should be as easy as importing some python module. keep it SIMPLE SIMPLE SIMPLE. The main reason for this is I like to rebind practically ALL my keyboard shortcuts, and usually the ones I like are bound to actions I never use, and unbinding them is.... tricky.
Question 2: Why reimplement the wheel?
Answer 1: Its all been done. This frustrates me. I really don't want to waste time implementing a text editor right now, but I spend so much time in my editor, I'd like something that's got even better HCI than JEdit. That does exactly what I want, not just almost exactly what I want.
I've looked at several editors, focusing on python editors lately. There's apparently nothing that suits me. But I don't want to start from scratch. I'm thinking of borrowing from xerces2's lazy-edit (http://xerxes2.1go.dk/python/python_start.php?kap=program.html), and a project nobody's worked on for a while called pyeditor (http://www.rexx.com/~dkuhlman/#special-purpose-scriptable-text-editors) -- the idea behind this project is almost exactly what I want, it just didn't get finished.
Answer 2: I really don't want to create an IDE. I want a text editor. Terminals have a purpose, you don't have to embed them into your editor, for god's sake! Debuggers can be run externally. Code navigators..... ok, maybe. The point is, if somebody else wants one of these things, they can create a new module to provide that functionality *without* causing me any pain -- I just won't install it!
Question 3: Who's involved?
Answer: If nobody would join me, I can't do this on my own at this time, too busy. :-(
At this point, I'd like to BEG xerces2 to take an interest in this project, because he's pretty good with PyGTK and has done an editor already. I'd also like to see Mr. Green on board because he's got a pretty good grasp on what sucks in an interface. As an HCI student, I'm learning that those of us who call ourselves programmers are not the best people to be designing user interfaces. Actually, I've been repeatedly beat over the head with this fact... but I digress.
I think it would be wonderful to see phrakture and cactus join me, but phrakture is a C++ guy. He's got all that free time though, so maybe he'd make some C++ modules to be embedded in the python interpretter.... Cactus.... well I'd really like to have somebody helping that could help make ruby and python cooperate in this project so that it would fully satisfy both python and ruby programmers.
I'd also like to see Xentac and iphitus (python programmers) join me, but I think I'm starting to ask for too much now. Wishful thinking can only go so far. ;-)
Question 4: How would you proceed?
Assuming I can get at least one good programmer interested in the project (begging xerces2 again, plus anybody else... lol I have no shame), I think I would do the following:
Start with lazy-edit and refactor it to allow for fully modular extensions. The extension interface is pretty much the *only* property of the editor itself, besides support for a buffer. I would take out syntax highlighting and the tabbed interface and put them in extensions of their own. This would help test the extension interface. The extension interface would be comprised of allowing extensions protected access to the user interface itself, and providing some sort of 'actions' framework to allow extensions to register actions that could be called back somehow.
I would then go on to enhance the syntax highlighting module. It would be nice if it were not necessary to rewrite 'edit modes' for every syntax available. The cool thing would be to steal edit modes from some other editor... JEdit has XML based edit modes; I'm toying with that idea, but I'm not too fond of XML.
Then I would work on a totally generic keyboard shortcuts module. It should be fully chainable and beautiful.... configurable in Python. The #1 worst thing in every single editor I have ever used is the horrible GUI interface for customizing keyboard shortcuts.
Once I have these two things, I have the two things that I consider really important in a text editor. At that point, I will probably start adding little things here and there as I need them, since I will be using the editor full time.
I'm not terribly excited about this project. Its just something I feel resigned to do because no editor I currently use behaves in the way I think it should. I want to believe nobody else likes their editor either, and that our connection (The Arch Philosophy) will allow you to think that this is a good idea.
Suggestions are definately welcome.
Thanks for your time, Dusty
arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
I really like the idea of this project. I would be willing put out some lines of code for this.
God Bless, Lukas
I really like the idea of this project. I would be willing put out some lines of code for this.
That's about enough for me to get started. =) I *really* don't have time for this, I don't know what I'm thinking, but I don't want to waste the rest of my life using an almost good enough editor either. :-D
I haven't been able to get ahold of xerxes2 yet. I've downloaded lazy-edit from http://xerxes2.1go.dk/lazy-edit-0.24.tar.gz but I can't figure out how to install it to a source directory -- by default, setup.py installs to /usr with items in /usr/bin, /usr/share, etc. Does anybody know if there's a setup.py option to install a 'source' tree or some such instead? I'm not even sure what license xerxes2 has on lazy-edit, so maybe we can't use it.
I've been thinking about basic ideas for what is needed to make an editor fully extensible. I think the core needs to provide a mechanism for arbitrary modules to register actions. An action is comprised of the name of the module, the name of the action, and a callback when that action is executed. In addition, the core needs to allow arbitrary modules to register events. Events can be generated by modules, by the core, or by user input (each character entered needs to generate an event, for example, so that modules can provide such cool things as auto-completion. Also, the core needs to provide some mechanism to allow arbitrary modules to be registered with it. The core also needs to provide access to the GUI. I'm thinking an extension of JEdit's 'docking' feature would be cool. Since Python is a scripting language, I thought the easiest (for a python programmer) way to do this is to allow modules to create GTK components that can be added to a window. Then the user can actually edit an interface script to place these components where they are wanted. Finally, the modules need to be able to access many of the variables used by the core, such as the buffer, the filename, etc.
Now, the problem is, I really need to be working on a research project instead of a text editor right now. I'd rather use JEdit for this than start using a not yet full featured editor, but I think I will try to use the editor and maybe add or refactor features as I go...
Dusty
On 10/9/05, Dusty Phillips buchuki@gmail.com wrote:
I really like the idea of this project. I would be willing put out some lines of code for this.
That's about enough for me to get started. =) I *really* don't have time for this, I don't know what I'm thinking, but I don't want to waste the rest of my life using an almost good enough editor either. :-D
Xerxes2 is cool with this. He's setting up a gna project now.... if we can think of a name. ;-)
Dusty
Dusty Phillips wrote:
On 10/9/05, Dusty Phillips buchuki@gmail.com wrote:
I really like the idea of this project. I would be willing put out some lines of code for this.
That's about enough for me to get started. =) I *really* don't have time for this, I don't know what I'm thinking, but I don't want to waste the rest of my life using an almost good enough editor either. :-D
Xerxes2 is cool with this. He's setting up a gna project now.... if we can think of a name. ;-)
Dusty
arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
Sounds good! Let me know when you have it set up!
God Bless, Lukas
Sounds good! Let me know when you have it set up!
Here it is!
https://gna.org/projects/magnum/
Send a message to Jens requesting membership. Hopefully he'll have the existing lazy-edit code in svn soon. I'm thinking we'll probably have two branches, the current branch that he's developing, and a devel branch where we'll start from scratch on a modular editor copy-pasting it. I've got some code and some ideas, but no time. :'(
Dusty
We have a mailing list and some source code up on gna now. Discussion will be moving to the mailing list. I intend to write a nice clear summary as soon as I have time.
Dusty
From the screenshots I assume the editor will be CLI only. If so, CLI
doesn't means always "simple" when navigation is poor, which I feel is important in an editor. In coding when dealing with large number of lines, for me scrolling, find/replace, and copy/paste are very essential.
Rasat
On Mon, 2005-10-10 at 13:22 -0600, Dusty Phillips wrote:
We have a mailing list and some source code up on gna now. Discussion will be moving to the mailing list. I intend to write a nice clear summary as soon as I have time.
Dusty
arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
Its pyGTK.
On 10/17/05, Rasatmakananda rasat@pacific.net.sg wrote:
From the screenshots I assume the editor will be CLI only. If so, CLI
doesn't means always "simple" when navigation is poor, which I feel is important in an editor. In coding when dealing with large number of lines, for me scrolling, find/replace, and copy/paste are very essential.
Rasat
On Mon, 2005-10-10 at 13:22 -0600, Dusty Phillips wrote:
We have a mailing list and some source code up on gna now. Discussion will be moving to the mailing list. I intend to write a nice clear summary as soon as I have time.
Dusty
arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
Did a test, its good. If not yet, possible to have an option to display line number beside the line?
Rasat
On Mon, 2005-10-17 at 20:35 -0600, Dusty Phillips wrote:
Its pyGTK.
On 10/17/05, Rasatmakananda rasat@pacific.net.sg wrote:
From the screenshots I assume the editor will be CLI only. If so, CLI
doesn't means always "simple" when navigation is poor, which I feel is important in an editor. In coding when dealing with large number of lines, for me scrolling, find/replace, and copy/paste are very essential.
Rasat
On Mon, 2005-10-10 at 13:22 -0600, Dusty Phillips wrote:
We have a mailing list and some source code up on gna now. Discussion will be moving to the mailing list. I intend to write a nice clear summary as soon as I have time.
Dusty
arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
Mostly I'm starting over from scratch. Xerxes2 is still working on the existing code, while I am starting on a redesign from scratch. Not really adding features yet. Hopefully soon we'll be able to convert existing features to a modular format, then we'll have the plugin format worked out and will be able to start designing new plugins. Hopefully at that time it will be easy to add your own features without hacking the core...
Dusty
On 10/18/05, Rasatmakananda rasat@pacific.net.sg wrote:
Did a test, its good. If not yet, possible to have an option to display line number beside the line?
Rasat
On Mon, 2005-10-17 at 20:35 -0600, Dusty Phillips wrote:
Its pyGTK.
On 10/17/05, Rasatmakananda rasat@pacific.net.sg wrote:
From the screenshots I assume the editor will be CLI only. If so, CLI
doesn't means always "simple" when navigation is poor, which I feel is important in an editor. In coding when dealing with large number of lines, for me scrolling, find/replace, and copy/paste are very essential.
Rasat
On Mon, 2005-10-10 at 13:22 -0600, Dusty Phillips wrote:
We have a mailing list and some source code up on gna now. Discussion will be moving to the mailing list. I intend to write a nice clear summary as soon as I have time.
Dusty
arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
Hi,
Dusty, nice idea. If you/we get a modular editor, it make spark an interest in developing other common sofwares in modular form as well. The current style of developing small/simple programs don't suite everyone when range of option and features are few. But as modular, its what they make it.
Rasat
On Sat, 2005-10-08 at 10:34 -0600, Dusty Phillips wrote:
If this has been done, I'd really like to see where. I'm really getting tired of the messy hacks that text editors tend to be, with features I never use and so forth. I want to build a text editor that allows you to install features one at a time (sounds like the archwm philosophy, eh?)
I don't have time to do this, I was wondering if I could gain support. Basically, here's what I'm thinking:
There is an extremely simple main editor component (written in python). This provides basic text editing and an extension/plugin/macro language.
Then you can use import statements in a config to import editor modules that you are interested in. Such modules would provide syntax highlighting, keyboard shortcuts, menubars (I'd never install this, but somebody else might), toolbars (ditto), code completion, abbreviations, search and replace etc.
Finally, you can have usually very short configuration scripts that provide additional customizations (set up your keyboard shortcuts, syntax colours, etc) or macro-like features in your home directory. If possible, it would be cool if these short scripts could be scripted in languages other than python
Question 1: How is this different from <insert-favourite-text-editor>?
Answer 1: Maybe its not. Maybe you have an editor that I would like to use. I really don't want to write my own editor, but none of the existing tools are elegant enough for me. Please tell me about it, especially if its not a common editor.
Answer 2: There is an editor that is similar to what I want. Its known as vim. I have some issues with vim though -- its a real pain to configure, its syntax is what I consider ugly. I don't want to learn yet another language just to configure my editor (Actually, I know how to script vim so I don't have to learn it, but neither do I want to look it up).
Answer 3: There is an editor that is similar to what I want. Its known as emacs. Same issues. I mean... Lisp???
Answer 4: There is an editor that is similar to what I want. Its known as JEdit. I've been using JEdit for years. But I'd like something that's a little more streamlined. JEdit has a beautiful Java plugin architecture, and a beautiful beanshell macro interpreter. I don't see why plugins and macros should be different, for example. It also suffers from the same issues as the previous answers -- I mean.... Java? I would borrow a lot of cool ideas from JEdit though if I could.
Answer 5: The key thing about my vision of an editor is that each feature is totally optional. It doesn't have "built-in" anything. BUT installing a feature should be as easy as importing some python module. keep it SIMPLE SIMPLE SIMPLE. The main reason for this is I like to rebind practically ALL my keyboard shortcuts, and usually the ones I like are bound to actions I never use, and unbinding them is.... tricky.
Question 2: Why reimplement the wheel?
Answer 1: Its all been done. This frustrates me. I really don't want to waste time implementing a text editor right now, but I spend so much time in my editor, I'd like something that's got even better HCI than JEdit. That does exactly what I want, not just almost exactly what I want.
I've looked at several editors, focusing on python editors lately. There's apparently nothing that suits me. But I don't want to start from scratch. I'm thinking of borrowing from xerces2's lazy-edit (http://xerxes2.1go.dk/python/python_start.php?kap=program.html), and a project nobody's worked on for a while called pyeditor (http://www.rexx.com/~dkuhlman/#special-purpose-scriptable-text-editors) -- the idea behind this project is almost exactly what I want, it just didn't get finished.
Answer 2: I really don't want to create an IDE. I want a text editor. Terminals have a purpose, you don't have to embed them into your editor, for god's sake! Debuggers can be run externally. Code navigators..... ok, maybe. The point is, if somebody else wants one of these things, they can create a new module to provide that functionality *without* causing me any pain -- I just won't install it!
Question 3: Who's involved?
Answer: If nobody would join me, I can't do this on my own at this time, too busy. :-(
At this point, I'd like to BEG xerces2 to take an interest in this project, because he's pretty good with PyGTK and has done an editor already. I'd also like to see Mr. Green on board because he's got a pretty good grasp on what sucks in an interface. As an HCI student, I'm learning that those of us who call ourselves programmers are not the best people to be designing user interfaces. Actually, I've been repeatedly beat over the head with this fact... but I digress.
I think it would be wonderful to see phrakture and cactus join me, but phrakture is a C++ guy. He's got all that free time though, so maybe he'd make some C++ modules to be embedded in the python interpretter.... Cactus.... well I'd really like to have somebody helping that could help make ruby and python cooperate in this project so that it would fully satisfy both python and ruby programmers.
I'd also like to see Xentac and iphitus (python programmers) join me, but I think I'm starting to ask for too much now. Wishful thinking can only go so far. ;-)
Question 4: How would you proceed?
Assuming I can get at least one good programmer interested in the project (begging xerces2 again, plus anybody else... lol I have no shame), I think I would do the following:
Start with lazy-edit and refactor it to allow for fully modular extensions. The extension interface is pretty much the *only* property of the editor itself, besides support for a buffer. I would take out syntax highlighting and the tabbed interface and put them in extensions of their own. This would help test the extension interface. The extension interface would be comprised of allowing extensions protected access to the user interface itself, and providing some sort of 'actions' framework to allow extensions to register actions that could be called back somehow.
I would then go on to enhance the syntax highlighting module. It would be nice if it were not necessary to rewrite 'edit modes' for every syntax available. The cool thing would be to steal edit modes from some other editor... JEdit has XML based edit modes; I'm toying with that idea, but I'm not too fond of XML.
Then I would work on a totally generic keyboard shortcuts module. It should be fully chainable and beautiful.... configurable in Python. The #1 worst thing in every single editor I have ever used is the horrible GUI interface for customizing keyboard shortcuts.
Once I have these two things, I have the two things that I consider really important in a text editor. At that point, I will probably start adding little things here and there as I need them, since I will be using the editor full time.
I'm not terribly excited about this project. Its just something I feel resigned to do because no editor I currently use behaves in the way I think it should. I want to believe nobody else likes their editor either, and that our connection (The Arch Philosophy) will allow you to think that this is a good idea.
Suggestions are definately welcome.
Thanks for your time, Dusty
arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
participants (3)
-
Dusty Phillips
-
Lukas Sabota
-
Rasatmakananda