Emerald Editor Discussion
March 25, 2017, 02:47:50 am *
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
  Print  
Author Topic: Enhancement Discussion: Syntax  (Read 29322 times)
0 Members and 1 Guest are viewing this topic.
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #15 on: July 29, 2008, 08:43:41 pm »

good point.. thinking on it option 2 would be best for compat
Logged
hetman
Miner
**
Posts: 17


« Reply #16 on: July 30, 2008, 10:28:56 am »

Yeh, that was my other concern. Which is why I would have preferred the deprecation approach keeping both around for a while. The new scheme was meant to make the syntax specification interface more consistent for the user (and documentation).

Anyway, if you feel this will result in too much clutter we can stick with the old options. I would change the scheme a little so it's more consistent with the options already there though. Here's my suggestion:

These stay unchanged:
$VARIABLEHIGHLIGHTINSTRING
$VARIABLEPREFIX $VARIABLEENCLOSEDBY $SPECIALVARIABLECHARS

These are the new options:
$VARIABLEHIGHLIGHTINSTRING2 $VARIABLEHIGHLIGHTINSTRING3
$VARIABLEHIGHLIGHTINREGEX $VARIABLEHIGHLIGHTINREGEX2 $VARIABLEHIGHLIGHTINREGEX3

$VARIABLENOTAFTERCHARS
$VARIABLEPREFIX2 $VARIABLEENCLOSEDBY2 $VARIABLENOTAFTERCHARS2 $SPECIALVARIABLECHARS2
$VARIABLEPREFIX3 $VARIABLEENCLOSEDBY3 $VARIABLENOTAFTERCHARS3 $SPECIALVARIABLECHARS3

$REGEXQUOTE
$REGEXQUOTATIONMARKRANGE
$VARIABLEHIGHLIGHTINREGEX



If you want to go with this scheme let me know and I'll make a patch against rev 247 (otherwise I can just supply the chunk of code that needs updating if that's easier).

How are the proposed changes looking other than the option name issue?
Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #17 on: July 30, 2008, 11:07:43 am »

Yes lets go with that. If you patch against the latest build then I'll commit.

Changes look ok I haven't seen any issues (though being honest I haven't been using CE much lately)..

Logged
hetman
Miner
**
Posts: 17


« Reply #18 on: July 30, 2008, 01:34:17 pm »

Alright, bug 167 has a patch there against rev247 along with updated description. I've patched and compiled OK from the online version so hopefuly this will go a lot smoother this time around Smiley
Logged
hetman
Miner
**
Posts: 17


« Reply #19 on: August 18, 2008, 09:33:21 am »

Hi. Sorry to nag. How's the commit going? Also need an update on whether I can get that Python doc-string fix in.

Is there going to be anyone around to do commits if I start submitting bug fixes?
Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #20 on: August 18, 2008, 03:10:21 pm »

Sorry I've been away on holiday.

I'll try and do it tonight.
Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #21 on: April 25, 2009, 05:26:09 pm »

Erm. Again with the late response, but I also liked option 1 better than option 2, but understand the compat issues. What say when we do a major version increment, we switch to option 1 only? So at 4.x we mention that 3.x syntax files won't work anymore?
Logged
hetman
Miner
**
Posts: 17


« Reply #22 on: April 26, 2009, 06:35:18 am »

Yeh, that's probably not a bad idea rageboy. Well, I've been waiting over half a year now to get these into the actual source tree so it's not looking very promising, lol. Perhaps I should just fork the project but give the amount of activity on this one I'm not sure there'd be that much interest for it anyway. Hmmm.
Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #23 on: October 28, 2009, 06:23:50 pm »

Sorry heman.

I stopped helping maintian the project about that time iirc due to personal life changes.
Logged
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #24 on: October 30, 2009, 07:01:47 pm »

I'll look into the issues of this thread now. I don't remember seeing it before. Personally, I prefer to have neither 1 nor 2, but keep it like hetman had it with both available. That way backwards compatibility is preserved, but the documentation doesn't have to be obscure.
Logged
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #25 on: October 30, 2009, 09:39:16 pm »

Just an update. I decided to review how the syntax highlighting works right now (without the patch). Then I'll make a list of all the features that would be good to add to get more languages working right. I'll might even include features that we couldn't reasonably implement if the feature seems like it would be useful. I'll then evaluate the design of hetman's changes in the light of my conclusions. I'll post my thoughts before I start implementation (which will be guided in part by hetman's patch).

I want to do this since some of the languages which I use cann't be syntax highlighted properly either. In particular, I know of problems with the syntax highlighting of both Lua and D.
Logged
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #26 on: December 29, 2009, 11:05:24 pm »

I'm probably not going to work on this now, but I'll post some of the thoughts I had about CE syntax engine improvements.

I think most settings should be numbered from 1 to 9. If there is no number it should be the setting for all nine numbers. Ex:

$VARIABLE1PREFIX=@
$VARIABLE2PREFIX=:
# 3-9 could be given but they don't have to be
$VARIABLEHIGHLIGHTINSTRING=Yes <-- this would apply to 1-9 since it is not numbered
$VARIABLE3HIGHLIGHTINSTRING=No <-- this would override the above line for VARIABLE3

Also, $HEXADECIMALMARK needs numbers too since some document types might use # and 0x.

$VARIABLEHIGHLIGHTINSTRING and $VARIABLEENCLOSEDBY need to be documented.

$HEXADECIMALMARK can disable a line comment delimiter. (I had this written in a document but I'm not sure what I meant.)

$HEXADECIMALMARK overrides keywordprefix, but not LINECOMMENTONFIRSTPOSITION

$ESCAPECHAR: should be numbered

$QUOTATIONMARK: (bug) front quotation mark can be escaped.

I think regular expressions would be nice for QUOTATIONMARK. Lua has [[ ]], [=[ ]=], [==[ ]==], etc. as quote delimiters. It would be nice to be able to say [(=*)[ and ]%1] or something like that. Also, D has q"TAG TAG" multi-line quotes where TAG must match. PHP has <<<TAG  TAG; if I remember correctly. These all require at least some type of regex support.

Ranges: The syntax needs cleaned up. GLOBAL, RANGE1, RANGE2, !RNGE1, !RNGE2, !R1&R2, and R1||R2 aren't great options since you have to remember whether to spell range RANGE, RNGE, or R.

Also, !R1&R2 seems to be identical to RANGE2.

$QUOTATIONMARKRANGE should be separated by numbers so different quotation mark types can be in different ranges.

$LINECOMMENT overrides keyword prefix.

$LINECOMMENTONFIRSTPOSITION: This doesn't work if it is the same character a string delimiter. That might be by design though.

(bug) If $BLOCKCOMMENTON is /* and $BLOCKCOMMENTOFF is */, /*/ doesn't end a block comment and */* doesn't start one. Also, the pair ] and ]] doesn't work.

$SHADOWON
$SHADOWOFF: These have the same issues as blockcomment.
When shadowoff is the same as blockcommentoff, shadowoff doesn't work. (In Lua ]] ends a string and it ends a block comment.)

(bug) Block comments within shadows show the blockcommentoff characters in the shadow color, but the blockcommenton in comment color. (There are similar issues with $HIGHLIGHTON/$HIGHLIGHTOFF and ranges.)

$INDENTATIONON
$INDENTATIONOFF: doesn't support begin end since it expects delimiters

$PAIRS#: Matches pairs in comments, but not as part of range delimiters. (PHP uses < and > as range delimiter for tags. I think this prevents them from matching.)
No multicharacter pair sets.
Matches across range boundaries.

$MULTILINESTRINGCONSTANT: Should be numbered so it is specific to string type.

Hetman's patch added $REGEXQUOTE. I think maybe this should just be a $QUOTATIONMARK with a higher number.

Also, D has regular block comments /* */ and nested block comments /+ +/.

I think that's everything.

I attached a test document I used to find this info as well as the crazy high contrast color scheme I was using.



* cedt-test.key (0.04 KB - downloaded 380 times.)
* cedt-test.spc (0.92 KB - downloaded 362 times.)
* test.cedt-test (0.48 KB - downloaded 375 times.)
* test colors.clr (0.22 KB - downloaded 374 times.)
Logged
hetman
Miner
**
Posts: 17


« Reply #27 on: January 26, 2010, 11:35:28 am »

Hi, kind of stumbled back here by coincidence, I didn't realise there would be any more activity on the project.

Looks like I might still need Crimson for a few things so I wouldn't mind doing some work on this.

A few questions, first, where is development on this project being co-ordinated through right now. Have things shifted to sourceforge entirely or are the devs still using this forum as the main hub?

Also, where can I find the source repository. Neither the links here or on sourceforge seem to be working for me. Arantar was meant to add me to the sourceforge project so I could add my syntax highlighting patch my self but then all activity kind of died on the project and I have no idea what's happened to it since.

Regarding your additional comments. I named REGEXQUOTE differently to QUOTATIONMARK because in many languages this often requires additional behaviour. For example in Perl need to distinguish when / is a division and start of regular expression literal. I was going to work an adding this in eventually but the initial patch never made it through.

Regular expression support is also something I thought about, would need to find a decent regex engine and figure out how to plug Crimson's syntax parsing loop into its FSM at a fairly low level to do this efficiently. Then again maybe, efficiency wouldn't be such a huge concern anyway and having the functionality at all would be preferable. Again, never got far enough with this.

I definitely agree the range syntax could be cleaned up.

Regarding naming of things such as $VARIABLE1PREFIX, I was being fairly conservative with that. What I would REALLY like to see so it's more intuitive for the user would be something like $VARIABLEPREFIX[1] etc. Documentation would be more concise then also I imagine, but it would break some of the syntax files out in the wild. I think it's come to a point where evolving this would be a good idea though.

The best way forward would probably be to start with my patch. Then basically go with a gradual evolution from there, perhaps tackles some of those bugs next (depending on how deeply rooted they are in the syntax loop implementation), attempt to add some of the other ideas you mentioned as well as ways to distinguish regex properly. And then perhaps look at how hard it would be to plug in a regular expression engine.

Anyway, I don't mind getting involved with this but I would like to know if it'll be worth investing more effort this time around.

Cheers
Logged
pn8830
Global Moderator
Jeweller
*****
Posts: 252



« Reply #28 on: January 26, 2010, 07:51:54 pm »

hetman,


You are more then welcome do dive in and do whatever you thing you can. Source can be found here. I think migration to sourceforge did not happen yet. http://svn.emeraldeditor.com/viewvc.cgi/

Thanks,
PN.
Logged

Entities should not be multiplied beyond necessity
hetman
Miner
**
Posts: 17


« Reply #29 on: January 31, 2010, 07:26:47 am »

How do I pull from that using a subversion client?
Logged
Pages: 1 [2] 3
  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.128 seconds with 18 queries.