JoshEdit: Difference between revisions

From ENIGMA
Jump to navigation Jump to search
No edit summary
 
No edit summary
 
Line 1: Line 1:
JoshEdit is a code editor written in [[Java]] designed for use with [[LateralGM]], primarily to replace the old editor which used an old (and small) version of [[JEdit]] that was difficult to maintain and improve.
JoshEdit is a code editor written in [[Java]] designed for use with [[LateralGM]], primarily to replace the old editor which used an old (and small) version of [[JEdit]] that was difficult to maintain and improve. Its implementation in LateralGM is currently branched in the [[JoshEdit branch]].


For a list of suggestions, see [[JoshEdit:Suggestions]]. Many of these suggestions have become part of the official specification for the program, and will be outlined here.
For a list of suggestions, see [[JoshEdit:Suggestions]]. Many of these suggestions have become part of the official specification for the program, and will be outlined here.

Latest revision as of 11:36, 6 May 2013

JoshEdit is a code editor written in Java designed for use with LateralGM, primarily to replace the old editor which used an old (and small) version of JEdit that was difficult to maintain and improve. Its implementation in LateralGM is currently branched in the JoshEdit branch.

For a list of suggestions, see JoshEdit:Suggestions. Many of these suggestions have become part of the official specification for the program, and will be outlined here.

For a list of bugs and tasks that need to be done, see JoshEdit:Todo.

The official developers for JoshEdit are User:JoshDreamland and User:IsmAvatar.


The rest of this article is probably out of date.

Name Ideas

JUCE: Java Unobtrusive Code Editor

Highlighting specification

The lexer has to be able to put a line at a token and affiliate any open states with it. Major ones being open strings and comment blocks. I am unfamiliar with JFlex but idealize it as being able to tell me exactly what token I'm on, given a line and column. If that's the case, and it does so in reasonable time (not O(N)), then we're in good shape. Unless the whole tree needs reconstructed each time I enter a quote. Someone ask TGMG; he is likely to be an invaluable asset given his past experience with Java lexers. Otherwise I'll write my own, and the thing won't be very extensible (though I may try).

Formatting specification

For the sake of the ENIGMA project, formatting must be handled through a class implementing an interface CodeFormatter. It will implement functions like syntaxCheck() and getIndentAfter(). In ENIGMA's case, LGM will outsource to the ENIGMA DLL, which (precisely as Rusky foretold, for once) will reuse its previous lex to suggest formatting. Rules for that can be implemented later; the stress here is to get core fetch functions hooked up.

Is it the job of JFlex or of ENIGMA to determine which argument is being typed in at present?

Communication

The aforementioned component will, for ENIGMA, need to implement a new, much better communication system than we have currently employed. It should offer the following:

  1. The current SyntaxError construct. Error message, line, position, absolute index; for the case of a real syntax error.
  2. A warning structure. It should contain the following:
    1. A permanent warning ID for blacklisting purposes (So ignorant users can choose not to hear about the gaping holes in their games).
    2. The warning message, with as much detail as possible while keeping concise
  3. A suggestion structure, to be coupled with either of the above. This structure should contain the following:
    1. The line/position which begins the proposed change and the line/position that ends it.
    2. The full text of the replacement, including unchanged code.
    3. A description of what change was automatically performed; as specific as possible without being AI-complete
    4. Possibly a weight value for likelihood of this fix to solve errors (for threshold purposes when running compatibility passes on old GM games)
    5. Possibly an ID for blacklisting

Default

There's no way in hell I'm coding a full everything parser in Java with syntax checking and code formatting, Maybe some day I or someone else will; for now, LGM should, by default, use a class implementing CodeFormatter and defining blank methods.