Edim's Design

[ghost]

• Source Code - The editor is primarily for source code. It is not a word processor, etc. It should not be bloated like EMACS. However, plugins should be able to add these other things in if they want.
• Line-oriented - Source code files and programming deals a lot with lines. Features should still be provided to manipulate the text inside of lines easily also; however, they may be less efficient (depends on the final implementation of the text buffer(s)).
• Portable - Edim and all it's default features should run on most if not all systems, including Windows.
• Unicode and UTF-8
• Consistent Command Language - This should be a given. Not sure if I want to go with a design where all commands can be chained together or not.
• Prompts - Unlike Ed, Edim will use prompts to show what the heck you're doing and to show some context. We can do this because we are not using TTY's anymore. However, prompts should be able to be disabled.
• Language-aware - Edim will be aware of the language of the file to be able to provide code-specific and language-specific functions. This means the plugin API should allow parsers to be created for different languages.
• Customizable - Pretty standard for text editors. A settings file should be provided. Also, a way to do project-specific customizations should be provided with the project system.
• Plugins - Edim will allow plugins to extends it's capabilities, for example adding more language support, introducing more commands, etc. A simple API should be exposed to plugins that allows them to do everything they need while still having some safety.
  • Plugins should be allowed to be compiled in any (compiled) language, including C. This could be similar to 4coder's plugin system.
  • Expose a scripting language for people who like that - NOT Javascript! Perhaps Lua and/or Python.
• Macros - This goes hand in hand with the commands and plugins.
• Bookmarks - Bookmarks allow you to quickly reference a line or a range of lines. Bookmarks can be created by plugins. One example use of this is for a plugin that shows an outline of the current source file and creates bookmarks for each function declaration that reference the range of lines that the function spans.
• Virtual Whitespace - Optional. The programmer shouldn't necessarily have to deal with indentation and whitespace (unless you're writing in python, that is). The program should automatically figure out all of the indentation of all of the lines so the programmer doesn't have to type it in. The file will save with the desired setting (2/4/8 spaces, tab), but this setting should be independent to how the indentation is displayed. This should function very similarly to 4coder's virtual whitespace system.
• Speed - The editor should be fast - which is partly why it's being written in a lower level language, C.
• Project and Build System - This should be similar to 4coder's projects and build system. 4coder allows a project file within a directory to set options specific to that directory/project. Also, allow files to be automatically loaded up into buffers. And, provide a file/command to be run when you want to build the project along with a file/command to run the built executable.
• Copy and Paste System - The Copy and Paste system should be similar to 4coder's. It should also be able to interact with the system clipboard. 4coder's paste system allows you to copy multiple things seperately and paste them seperately - is allows you to paste something you copied before other things that you've copied instead of just pasting the last thing you've copied.
• Unlimited Undo