How should the editing core support external extensions?

[DanHughes]

We are wanting to know if our CMac macro language being tightly integrated into the editor is important or would it be better to create an API around the editing core that permits access to it from other languages than CMac.

[AndyColson]

I think one language is fine, and I can see it being simpler on the project than trying to maintain some middle ground API usable from many languages.

As long as the built-in language is usable and sane, I don't see why people cant pick it up and use it. People learned cmac, after all, it wasn't hard to pick up.

Here is where Lua also makes sense. We can say the time you spend learning Lua can be put to use in other programs that use Lua.

Support wise it also makes sense. If someone posts a question about a macro they wrote in Python, I'll never answer it. Wont even read it. I think its better to be a master of one rather than useless in many.

-Andy

[samej71]

One of the really nice things about ME is the fact that much of the editor's guts are included in the package in its CMAC source form and a user can edit that code to tweak existing functionality in the editor.

For example, the patch I received to add a "compile files" button to the "file has changed on disk" dialog; or the patch I added to add a few seconds of leeway to using timestamp change detection for network drives.

How will this work in an API model? Will the "source" still be available to modify? Or will this only allow people to essentially program extensions and macros outside of "core" functionality?

I wouldn't want to lose the ability to really get "under the hood" to make changes.

Yes, UltraEdit has a lot of eye-candy and there are days I wish ME had a more modern-looking appearance, flexibility (resizable dialogs, etc), and some of UE's features, but *nobody* has the power and core flexibility to add/change functionality like ME has, and nobody listens and adds features requested by users like ME, either (IMO).

--James

[Clay Martin MWI]

Ditto to James.

Lots of features are nice, but being able to modify how the editor does this or that is vital to a large diverse user base. Sometimes what you need puts you in the minority of users. The editor's developer can't cater to every minor request. These are best handled by the individual user modifying the code to do what they need.

That said, ME has been built on and built on for years. Major changes to the core will "break" a lot of the existing cmac implemented functionality, and it should. Much old code has be patched and patched to the point that large blocks of legacy code probably are not even executed any more as they relate to other code which is not used or reflects the "old way" of doing something. Also I'm sure that many data handling/event tracking/internal communication methods currently used are not the best choice, but reflect the fact that that was how someone chosen (best choice at the time) to do it originally, and over time there was not the resources to go back and recode a bunch of other functions just to make all conform to a new/better way of doing something.

It's quite likely that with a OO style cmac replacement, that the total lines of code on the "cmac" side of the editor would drop, and disposing of the legacy code and recoding from scratch would not seem so daunting.

Right now adding things like unicode support are held back by the restrictions of using the old core. Don't hold the new core back by imposing the restriction of using the old cmac wrapper. Yes there should be a user modifiable wrapper around the core. But modern hybrid cars are not created by adding solid state electronics to a Model T.

[samej71]

I agree with Clay.

If ME is going to take a big leap forward, and it sounds like that might be what's going to happen, then I'd say it's an excellent time to revamp the macro language. No need to keep backward compatibility with the language if so much else is going to change, any existing macros would need to be fixed up anyway. I'm sure everyone (or most everyone) will be willing to fix-up their personal library of macros for the sake of progress. Time to throw off all the shackles.

I haven't written too many, but I'd gladly change/fix/rewrite the macros/changes I have in a new or updated language.

--James

[Michal Vodicka]

Having editing core with well defined API is great idea. It would allow almost everything according to everybody's choice. Current CMAC sources are full of Win32 calls. It'd be easier to write such a code natural way in C or C++. CMAC is nice simple language for manipulating with strings but doesn't have sufficient tools to express more complicated data structures. Core API would allow coexistence of simple macros written in CMAC with more complicated extensions written in other languages.

In addition, it wouldn't be a big change. Compiled CMAC macros already use core very similar way so why don't extend it?