Emerald Editor Discussion
July 20, 2017, 01:35:13 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1] 2 3 4
  Print  
Author Topic: Core syntaxes  (Read 38208 times)
0 Members and 2 Guests are viewing this topic.
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« on: May 12, 2006, 12:24:54 pm »

This isn't really a key development topic, so I've brought to a separate home.

Anyhow. I think the following should be considered the most required/core syntax files and should be made available as standard, even in minimalist EE packages:

* HTML/XHTML (also includes DHTML)
* PHP
* JavaScript
* ASP
* VBScript (the work in developing this can be taken forward to build a generic VB or even a generic BASIC syntax guide)
* C/C++
* Perl

Any others which are crucial/must-haves for EE? I cite the above, by the way, based on what I gather most people currently use CE for.
Logged

"Cleverly disguised as a responsible adult!"
Feldon
Gem Cutter
****
Posts: 106


« Reply #1 on: May 12, 2006, 01:41:36 pm »

If you design a syntax system thats modular and easy to replicate, and document it, thats all you'll need to do.  Hopefully a bunch of less-experienced programmers who are looking for something to do can throw together the syntax stuff without wasting the dev-teams time.

You could probably do a similar thing with language (as in french, italian, etc) files too.

Thats a good list for what we should focus on first.  I might add Sun Java to it though and possibly Python.
Logged
dsvick
Beta Testers
Senior Miner
***
Posts: 52



WWW
« Reply #2 on: May 12, 2006, 02:28:05 pm »

Yes, I'd include Java as well. The 'serious' coders may stick with Eclipse or some other IDE but people that code in a variety of languages or who might not want to spend the time getting to know a more complex IDE would surely use EE for it. And the syntax files for it would not be all that different from C.

Another possible one to add would be vbs, I've got visual studio at work and never use it, because it is just too much overhead and other un needed stuff when I'm writing a simple asp or vbs script. And, again, the syntax would be pretty close to asp. This one would probably not be used as much as Java though.

Other ones to consider in the future: Ruby, Lua, and D.
Logged

Dave
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #3 on: May 13, 2006, 11:53:26 pm »

I'd add an XML highlighter that could be used for straight XML storage and it would be the basis for (X)HTML, but the HTML may have context-sensitive highlighting.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #4 on: May 14, 2006, 10:43:14 pm »

Well, the XML format is sufficiently vague you can't do a whole lot with it, generally speaking. XML does not define a schema as standard to say which tags are allowed and which aren't (a la X/HTML), so to effectively highlight an XML file, you would need to pass the DTD to Emerald to tell it how it should go about highlighting an XML document.

A highlighter based purely on tag syntax is feasible, but generally you can tell if tags are closed correctly, and without a DTD you couldn't tell really if they were nested.

Any thoughts, anyone?
Logged

"Cleverly disguised as a responsible adult!"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #5 on: May 14, 2006, 11:17:55 pm »

You don't need a DTD to format XML properly. You'd first make sure that you highlight all tags in angle brackets, attributes that are quoted, and then self-closing tags (). Nesting really doesn't seem to be that hard (you'd do the same kind of stack logic that would be done to match braces in C/Java or def/end in Ruby).

XML editors don't highlight specific tags unless there's a DTD. It's only meant to delineate tags and attributes from data, which is helpful. However, if a DTD was present (like in HTML or XHTML (and if the DTD isn't present, we can guess at it because of a root tag)) then specific colorations could be applied.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #6 on: May 15, 2006, 12:38:33 am »

Well, the current system under CE is to look for special characters, and also for keywords. Special characters can change editing colours (e.g. quotes, comments), while the keywords are used to specify individual tags.

If it highlights everything that is a tag, that should be easy enough. I'm sure other formats must do something similar, so it could be added to the parser. As for the highlighter adding in specific highlighting for DTDs, it is definitely doable, but I'm a little wary of bloating the code.

Currently there are no plans to add a full DTD parser, simply to work on the premise of keywords (like CE)

As for my thoughts on nesting, I'm not entirely sure what I was thinking, because thinking about it, without a full parser (which this isn't trying to be) nesting is largely irrelevant. EE isn't meant to be a proper IDE as such, but a general purpose editor, and I'm not sure how deep it should go into a specific language for its support.

I suppose it depends on the trade-offs between speed, size and functionality. Personally, I quite like the current CE system.
Logged

"Cleverly disguised as a responsible adult!"
Feldon
Gem Cutter
****
Posts: 106


« Reply #7 on: May 15, 2006, 01:39:41 am »

I think if we do decide to go with XML, there should be some tangible benefits for doing so.  And those benefits should outweigh any loss in performance.

Given that, we should maybe think about what some of those benefits might be.  Also, are there any reasons the syntax file would be used outside of EE's internal code?  Here are a few ideas:

a) a simple auto-completion wizard might just auto-complete keywords in the currently used syntax file.  For example, you're working on a PHP file and type in "mys".  The auto-completion wizard might then recommend "mysql_query(" as the potential completion.

b) a complete-function wizard (similar to Excels formula wizard).  For example, you type in "mysql_query(" and EE might bring up a tool-tip style box that explains the arguments the function requires (with the current argument bolded like in Excel).  For this to work the syntax file would also contain information such as whether the keyword is a function, and if so, other information such as the function arguments.

c) You might want to make the syntax files available for viewing on-line, perhaps as part of a manual.  In this case, if they were in XML format they could be easily parsed as such and have CSS rules applied to it for a nice display.  If they were in our own .ini format, we would have to use php or some other server-side code to parse them first.

Any other potential uses?  Any other reasons for using syntax files outside EE's internal code?

If there aren't a lot, or at least none very compelling, then I say stick with whatever performs best! Smiley
Logged
hhppyysobad
Prospector
*
Posts: 2


« Reply #8 on: May 15, 2006, 09:29:59 am »

hi Peter,

Can you also consider syntax for Gauss, winrats, stata, matlab, and oxmetrics languages.
These leanguages are all for theose econometrician and mathematician. And there are only few editor that truely supported these language. Emerald would become one of favour editor for these people (econometricians and mathematician) if these languages are being turely supoted.

cheers!
Logged
JoBe
Guest
« Reply #9 on: May 16, 2006, 11:13:49 am »

I vote for a TCL/TK syntax file and offer to do one once the syntax system is decided.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #10 on: May 16, 2006, 12:37:25 pm »

To answer the recent questions:

hhppyysobad, I see no reason why we can't look at Guass, winrats, stata, etc. Matlab was supported in CE if I remember rightly, so I see no real reason to discontinue such support. Plus it widens the potential userbase, which can only be a good thing.

JoBe, I also see no reason why TCL/TK shouldn't be supported.

Fenton: A lot of very good points here. Let me see if I can't provide an answer of an equal standard!

Quote
...we do decide to go with XML, there should be some tangible benefits for doing so. (snip)
Quite right. I don't want to add the extra processing time and code for XML if we can use a simpler format. On the flip side, it might help future development. I say might since if we put enough thought into the syntax format, we shouldn't have to worry too much about expandability.

Quote
Also, are there any reasons the syntax file would be used outside of EE's internal code?
There are reasons that this might be done.
1. Customisation. One of the strongest parts of CE was that the syntax system was set up so anyone could add syntaxes without too much work, and these could be shared. If they are integrated into the internal code, the option becomes removed.
2. Dual-coding. If we were to consider the above and allow external support files for custom scripts, you still have a certain amount of double-code in there, because you still have to handle any natively-supported syntax files, then support external ones.

On to your other ideas:

a) a simple auto-completion wizard might just auto-complete keywords in the currently used syntax file...
I don't see why not. If you keep it literally to autocomplete known words, that shouldn't be too hard to implement in theory.

b) a complete-function wizard (similar to Excels formula wizard).  For example, you type in "mysql_query("...
This has been suggested but it is very much an "on the fence" debate. On the one hand this would be a very useful feature (assuming the syntax file is complete enough to understand) but I am concerned as to the extra size that the program, and the syntax files, would have to be to accommodate this.

I also wonder whether this would take EE out of the line of "programmer's text editor" into "wannabe IDE", and if so it might turn people away rather than draw them in. It may be that "less is more," as some might say.

c) You might want to make the syntax files available for viewing on-line, perhaps as part of a manual...
Would there be much use for this? Many people I've known don't really care how it works, as long as it works. However, if the demand is there, XML would be a benefit, since XSLT or CSS could be applied instead of a pre-parse in PHP. (The server does run PHP and Python, and very shortly, Perl as well, and this is the sort of thing Perl would excel at)

I'm still not convinced that XML would handle a) or b) any better than a custom format, which can almost certainly be parsed and applied quicker than parsing and applying XML data. Normally I'd advocate the standardised formats etc, but I think here that speed, and size, will win out over the extra functionality that XML would provide - I simply don't think XML is best suited to this sort of application.

Every point is open for debate, and I'd rather us spending a few days debating it, and boiling it down to whatever will work best (or fastest or whatever is appropriate) before we build, since some things like this are pretty central to EE, and need to be set in stone *before* developing. Once set, we can implement it faster, we can implement it more effectively and make it work really well.
Logged

"Cleverly disguised as a responsible adult!"
Zhrakkan
Official Mascot!
Beta Testers
Gem Cutter
***
Posts: 177



WWW
« Reply #11 on: May 16, 2006, 02:08:04 pm »

Arantor wrote:

2. Dual-coding. If we were to consider the above and allow external support files for custom scripts, you still have a certain amount of double-code in there, because you still have to handle any natively-supported syntax files, then support external ones.

Question....
If ALL syntax are actually external to the program, will that slow down the app?
Logged

News Manager and Unofficial Mascot
Join the Emerald Editor Project - Message Me!
Emerald Editor - "A Jewel of an Editor"
-----by the way, that name is pronounced "Za-Rack-In"
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #12 on: May 16, 2006, 03:00:16 pm »

Is there no existing open XML standard for syntax files?  I would think that other editors would have done that by now.  This would allow users to switch from editor to editor and bring along their syntax files with them.  I would lean toward XML--it seems that would help simplify collaboration.  Also, it would be easy for users to edit XML files.  If you *really* want to make adding new syntaxes (and updating old ones) easy, then couldn't you provide a simple form for this?

What if the syntaxes were stored in XML, but loaded into a custom format in memory (or a temp file) when a specific syntax was selected (i.e., document was opened or syntax chosen from list for the current file) ?

Even if you don't use XML, it sure would be nice if there was a way to convert syntax files between editors.
Logged
Zhrakkan
Official Mascot!
Beta Testers
Gem Cutter
***
Posts: 177



WWW
« Reply #13 on: May 16, 2006, 03:18:21 pm »

I would imagine, regardless of format, this website will have all the neccesary information to create a Syntax File.
Logged

News Manager and Unofficial Mascot
Join the Emerald Editor Project - Message Me!
Emerald Editor - "A Jewel of an Editor"
-----by the way, that name is pronounced "Za-Rack-In"
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #14 on: May 16, 2006, 07:59:58 pm »

Zhrakkan, that is a very valid point. I think, though, having them outside would be ultimately more beneficial than having them inside the program.

For example, CE currently has over 100 syntaxes available with the core release. If we include the code for all 100 in the executable itself it will be slower since it'll have to load each of them every time, when the program starts, and it does defeat one of the selling points of EE.

Having some of them included might speed it up a little, but I don't believe built-in syntaxes would be much faster (I'm thinking at the tiny fractions of a second level here) than having them all separate. If nothing else it's one less module of code to maintain.

On the subject of XML, there does not appear to be an existing standard, XML or otherwise, to which we could adhere. I don't want to get into the realms of definining a "standard" since I don't want to create a situation whereby we create a standard that only we are standard to (think of a certain, large, operating system manufacturer based in Redmond)

I'm hearing a lot of support for XML, and while I do not personally believe that it is ideal for this use, it is a viable alternative. I do, however, want to avoid any intermediate steps, hence my support for a flat file, one that can be loaded in and used almost straight away, without any intermediate parsing.

There aren't many other editors out there that support customisable syntax highlighting, the only two I can think of other than EE are our beloved Crimson Editor, and Notepad++. CE uses a flatfile method, and defines words as being of one or more types, which then is then used by the highlighter to determine which colour it uses.

Meanwhile, Notepad++ defines it as an XML file, which does perhaps support its use. It defines the information in XML tags (using mostly empty tags, e.g. ) but otherwise the basic format is somewhat similar. I get the feeling, looking at it, that a non-XML-like purpose has been kind of shoehorned into an XML format.

Whatever we do end up using, this website and the program documentation will - of course - have all the information required to build a Syntax File.
Logged

"Cleverly disguised as a responsible adult!"
Pages: [1] 2 3 4
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.259 seconds with 18 queries.