ENIGMA Development Environment

Interesting. I accept your theory, then.

I'll brief you on the little stuff I know:

ID's start after some high number like 100000 so that they don't conflict with object IDs. This allows you to do things like:
object.x = 5
instance.x = 10

On game restart, all the instance IDs are bumped up, so that the lowest instance ID is higher than the highest instance ID of the last run. Because of this, it's bad practice to reference instance IDs directly, or to try to hang onto them after game restart.

I can't tell you about the behavior of persistence, but it's very easy to inspect and find out for someone who has a copy of Game Maker installed.

I have some suggestions. Note that they should be options, not enforced.

1. When you copy and paste a code from somewhere, the editor automatically formats the code according to the rules set by the user in LateralGM.

2. Allow the user to use tabs in the auto-formatting script rather than spaces.

3. When you select several lines of code and start from the longest line, the editor shouldn't violently jump all the way back to the left when moving the mouse out of the long line. What if I just wanted to select a snippet of the code in that line? This happens all the time in GM. It should only move left or right when you move the mouse to the side of editor window. Moving up and down is still done the traditional way, though.

4. The code editor checks the syntax X seconds after the user stops typing.

1: This is a later-down-the-road suggestion. We'll consider it.
2: Probably will be implemented as an option when we get there.
3: I think we resolved this by allowing the caret to remain in virtual post-line space, but be drawn at min(caret.x,line.length).
4: Sounds easy enough.

Some of these are LGM, some are code editor, some are a combination:

• Expand/Collapse brackets (), {}, [], begin/end
  
• Fix indenting
  
• Refactoring(Rename variable, Rename Script, Extract Method)
  
• Auto-complete - see MonoDevelop for ideas(for instance, in MD "Case" matches "camelCase", etc.)
  
  • If the above situation about camelCase is accepted, then some customization would be nice(camelCase vs underline_separated, etc.)
    
• Breakpoints
  
• Tab indents selection(in GM, tab doesn't indent selection, it replaces it)
  
  • Shift+Tab unindents selection(or current line, or whatever)
    
• Script documentation support(Like /** @argument0 Instance to receive foobar */)
  
• Code style editing(replace begin/end by {} and vice-versa, remove all then statements, add ; to the end of lines where a ; is implicit, remove all unneeded ;, option to convert all "if (foo) stmt;" to "if (foo) { stmt; }", etc.) Note that after applying ANY of these changes, the code effect should be EXACTLY the same. This is an important detail to consider when implementing ; addition/removal.
  
• Code warnings like Eclipse and NetBeans and auto-fix.
  
• Option to auto-remove whitespaces at end of lines
  

1: Obviously planned.
2: Define "fix"
3: In consideration for later.
4: Will require clarification/investigation. The LGM code editor already has Ctrl+Space which looks for function names matching the typed text or abbreviated by it (e.g. sm<ctrl+space> suggests show_message)
5: Will consider for later.
6: Obviously planned.
7: Will consider for later.
8: In consideration for later. Will mostly be the job of ENIGMA, I believe.
9: In consideration for later.
10: Good idea.

At this point, can we just have an external code editor option?  Geany has all of these and it would be nice to have them before they're actually implemented.

Already an option. Preferences property "externalScriptEditorCommand" in LateralGM. By default, it's set to NULL indicating 'use internal'. Can be overridden by Java preferences (I posted a tutorial on how to do that manually somewhere. Not sure where now, though.)

https://enigma-dev.svn.sourceforge.net/svnroot/enigma-dev/trunk/plugins/shared/jna.jar

Stick that in enigma-dev/plugins/shared/

They're very similar. One of the major differences you'll run into is the namespace and the full object-orientedness.
This looks like it might be useful:
http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/main.html
The biggest trick behind java is just to know how to use the JavaDocs, because a Java developer accesses them 500x a day.
http://download.oracle.com/javase/6/docs/api/

//P is the properties, essentially solving the data tier. Resource is the Logic tier.
public abstract class Resource<R extends Resource<R,P>, P extends Enum<P>> implements
Comparable<Resource<R,P>>,PropertyValidator<P>
{
 public abstract R makeInstance(ResourceReference<R> ref);
 protected abstract PropertyMap<P> makePropertyMap();
 public abstract Kind getKind();
 public BufferedImage getDisplayImage() { return null; }
}

//Presentation tier. Becomes visible immediately after instantiation
public abstract class ResourceFrame<R extends Resource<R,P>, P extends Enum<P>> extends MDIFrame {}
Add another abstract class for saving and loading?


This is basically the way LGM is already set up, except that we currently handle all saving/loading in two classes, GmFileWriter and GmFileReader. This means that we'll simply need to split up the file reading/writing into individual resource saving/loading.

I like it. I think we'll come to an agreement that will make us both happy.