What extension languages should be available?

[DanHughes]

We are wanting to know if CMac should be continued or if other languages should be made available to control the editing core.

[Clay Martin MWI]

The concept of having a easily accessible language to manipulate the editor (like cmac) is indispensable. I think switching to something externally compilable, narrows the usability. Programmer A works in C++ with xyz compiler, Programmer B works with OB+-% using abc compiler. Now if xyz can compile to work with ME, A is happy, B must get a second compiler. If neither xyz or abc work with ME both are unhappy.

The sheer number of tools/refinements/language support items users have made in cmac over the years demonstrates the flexibility and ability to adapt to the changing programing environment, cmac has given to ME. Moreover the usefulness of ME is not just evidenced in the ability to make "editing" tools. I once had to convert a customers old data from a old hand-rolled FoxPro db app to Quicken. Although my original thought was to use Delphi to read the data and write the import files (kinda quirky format), It became rapidly obvious that it was easier to do with a cmac macro. Yep never used that macro again but it was a real time saver.

On the other hand, cmac is dated in that it does not incorporate many of the newer "concepts" in programming. I don't mind learning a new language if it is for a tool that I will use for the rest of my carrier.

If cmac goes away, a lot of things will need to be re-writen. But they may be easier to redo with a more modern language. Sometimes when you switch from horses to trucks, you just have to rebuild the stables 'cause the trucks will not fit.

I think the important points are:
- there is a language to extend/manipulate the editor
- the compiler (if compiled) comes with ME
- the language be more modern than cmac

[AndyColson]

I'm gonna vote for Lua, and not the other languages.

1) I dont like python.
2) I love perl but its very painful to embed
3) I dont know ruby or if its embedable

Lua is a simple language to learn and use. Its very simple to embed into delphi, and it would cut a huge amount of "develop a scripting language" time out of the project.

-Andy

[shanawalt]

Every time I see someone stating that they don't like Python, I have to assume that they've never really used it. It really is a very nice object oriented language. Perhaps not the best, I don't know them all, but it is certainly more maintainable than some of the cryptic languages like Perl or Tcl.

With that said, I've never taken the time to learn CMac so either the editor already does everything I really need or I am just lazy. In any case the one thing that I would like to see in the next version more than ANYTHING else is an undo that really does remember everything. I believe all versions of multiedit have a bug that the undo buffer doesn't remember certain mouse movements or something so even though you've edited something somewhere it doesn't undo it because you went there with the mouse or something like that. There's an entry somewhere in the FAQs about it and I run into the bug all the time. Perhaps I'm not old school enough to only use the keyboard to navigate a file? Please fix this bug. That alone would get me to upgrade.

Since we're talking about a new version, other things that would be nice is better support indexing of files. More along the lines of what Eclipse offers. Why don't I switch to Eclipse? So far I haven't figured out how to do block editing operations like ME has. Seems like one of the best and simplest features of ME, but so few other editors seem to offer it.

[FreeTrav]

The more text-manipulation languages, the better, IMO, as everyone has their own preferences. Were I doing the development, I'd actually not build in ANY language except your own proprietary CMAC (and I'd really like to see the Pascal-like MEMAC brought back as well), and just provide some hooks to user-configurable external language processors.

[daantje]

I actually am missing one option. C# would be my preferred option. By now I have seen quite a few solutions that give great scripting features in C# (with all the goodies of .NET .

Daniël

[samej71]

I think CMAC should be continued if the CMAC source to many of the core ME functionality will still be provided. Being able to tweak existing functionality by editing the CMAC source is a big plus in my book.

I'm fluent in Pascal and perl, so both of those sound appealing to me. At one time there was a Delphi component for pascal scripting, which would allow a program to use "pascal macros" a user provided. I don't know how portable that is. The compiled option is interesting because it could come in handy for intensive processes that could use native code execution speed.

If there is an API, theoretically that would enable people to write their macros/extensions in the language of their choice, be it compiled or scripted. All ME would need is the path to the executable (if compiled) or interpreter (if a script) and any parameters to pass.

CMAC has done well for a long time; I'd be good with an updated CMAC2, too and leave the rest of it alone for now.

--James

[Michal Vodicka]

Let the choice on programmer/user. As other question suggests, having editing core with well defined API would solve it. CMAC should be kept in any case, it is easy language for simple tasks.

OTOH, editor implementation without core should remain available as source code regardless of language used and it should be written in CMAC + 1 selected language. For reference, easy customization a bugfixes.

[MewUser]

I rely heavily on CMAC code to perform a variety of tasks. CMAC is the main reason that I chose MultiEdit back in the DOS days of 1989!!! I have used it for the last 20 years.

If for some reason CMAC is dropped, then it MUST be importable into some other language to perform the same functionality as in MultiEdit.

[reb]

Don't want to have to rewrite our legacy CMAC scripts.

[dynalt]

CMAC is fine for a dedicated language and for its purpose of implementing much of MultiEdit.

There are (at least) 2 sides to maintaining your own scripting language, and only you can say which applies more:

1) Maintaining a language in addition to an application is quite a load. Most who choose to embed another language do so to avoid the additional development. I have seen applications start to evolve a language for a single application and end up spending so much effort on language design that the product suffered.

2) Having a language dedicated to the problem domain can be a definite competitive advantage. In Crafting An Editor, Richard Stallman highly recommends building an editing engine and a supporting language and then building most of the editor in the language.

MultiEdit needs an extension language. Having the source for much of the editor available is excellent. If maintaining CMAC doesn't strain resources, keep it.

I prefer Ruby over the other choices, but when I presented the option to the developer of another editor, he pointed out that Ruby threading doesn't play nicely with Delphi Threads. (There is an embedding for Ruby into Delphi available). This developers choice was Lua.

I am reading Programming Lua now. It is amazing how much is possible by using only a few constructs, but the language certainly has some challenges. For one thin, string are immutable and string manipulations can become quite complicated. I am not certain that Lua is as good as CMAC for implementing MultiEdit, though it may do for adding the occasional macro.

[John Martzouco]

I rely heavily on CMAC code to perform a variety of tasks. CMAC is the main reason that I chose MultiEdit back in the DOS days of 1989!!! I have used it for the last 20 years.

If for some reason CMAC is dropped, then it MUST be importable into some other language to perform the same functionality as in MultiEdit.

I agree wholeheartedly with this opinion.

I have a highly customized version, and if I can't move that forward with very little effort, I won't.

I chose ME because of CMAC and the very flexible, completely programmable character that the product has. I've invested a huge amount of time making it do more for me, and I can't afford to lose that.