Re: [xwiki-devs] [GSOC]syntax highlighting probleam
Hi Venkatesh, On Jun 12, 2008, at 10:40 AM, Venkatesh Nandakumar wrote: [snip]
1. Syntax Highlighting, to a large extent, though there have been problems, as pointed out by Malaka, *bold~~combined~~bold* doesn't give the required effect, and secondly, the complex use of '*' in the wiki syntax makes it a bit difficult to differentiate between actual *bold* usage versus listing uses, maybe we would have to create own custom regex-based rules for it later. For other tags, its been simple and straightforward.
Do you really need to parse it yourself? We have a parser in charge of doing this so you don't have to care at all about these problems. That's unless the system you use for syntax highlighting uses regexs (in which case I think it should be changed). Thanks -Vincent
2. Content Proposal, type <the first character of syntax> and drop- down of possible syntaxes, when selected, moves cursor to correct position of entry of text. Key-combination also brings down the menu. Also valid for applying styles to selected text. 3. As a minor addition, context information. ( though very partially) 4. Indentation strategies (very partial implementation till now) 5. minor - Hyperlink detection and linking within {quote} and a hyperlinks
I've also divided the document into partitions,(as of now, pre,code,table,<dl> and default) for possibility of different content proposal/content assist/syntax highlighting.
I have not integrated any of the code with the xeclipse plugin's code. What I have created as of now, is just another eclipse-plug-in.
Venkatesh
On 12 juin 08, at 10:48, Vincent Massol wrote:
Hi Venkatesh,
On Jun 12, 2008, at 10:40 AM, Venkatesh Nandakumar wrote:
[snip]
1. Syntax Highlighting, to a large extent, though there have been problems, as pointed out by Malaka, *bold~~combined~~bold* doesn't give the required effect, and secondly, the complex use of '*' in the wiki syntax makes it a bit difficult to differentiate between actual *bold* usage versus listing uses, maybe we would have to create own custom regex-based rules for it later. For other tags, its been simple and straightforward.
Do you really need to parse it yourself? We have a parser in charge of doing this so you don't have to care at all about these problems. That's unless the system you use for syntax highlighting uses regexs (in which case I think it should be changed).
This is something related to the Eclipse text-infrastructure which uses its own techniques for identifying text elements, and the way it does is a way that it is not the standard way. The basic framework provides some "rules" that are used for chopping the text into partitions that are assigned a given type. For example, XML comments can be processed by using: new MultiLineRule("<!--", "-->", "XML_COMMENT_PARTITION"); that basically associates everything between <!-- and --> to the type "XML_COMMENT_PARTITION". I think that in principle a "standard parser" output can be integrated into this framework, but this has to be investigated because it might not be so simple. As I said in a previous mail, Malaka might try to think about it as the next step of his project. For sure this would be nice because we would use a single "authoritative" parser. WDYT? Cheers, Fabio
On Jun 12, 2008, at 11:11 AM, Fabio Mancinelli wrote:
On 12 juin 08, at 10:48, Vincent Massol wrote:
Hi Venkatesh,
On Jun 12, 2008, at 10:40 AM, Venkatesh Nandakumar wrote:
[snip]
1. Syntax Highlighting, to a large extent, though there have been problems, as pointed out by Malaka, *bold~~combined~~bold* doesn't give the required effect, and secondly, the complex use of '*' in the wiki syntax makes it a bit difficult to differentiate between actual *bold* usage versus listing uses, maybe we would have to create own custom regex-based rules for it later. For other tags, its been simple and straightforward.
Do you really need to parse it yourself? We have a parser in charge of doing this so you don't have to care at all about these problems. That's unless the system you use for syntax highlighting uses regexs (in which case I think it should be changed).
This is something related to the Eclipse text-infrastructure which uses its own techniques for identifying text elements, and the way it does is a way that it is not the standard way. The basic framework provides some "rules" that are used for chopping the text into partitions that are assigned a given type.
For example, XML comments can be processed by using: new MultiLineRule("<!--", "-->", "XML_COMMENT_PARTITION"); that basically associates everything between <!-- and --> to the type "XML_COMMENT_PARTITION".
I think that in principle a "standard parser" output can be integrated into this framework, but this has to be investigated because it might not be so simple.
As I said in a previous mail, Malaka might try to think about it as the next step of his project. For sure this would be nice because we would use a single "authoritative" parser.
yes, exactly. That's the point. Let's hope it's possible. It probably is as otherwise it seems doing syntax highlighting for complex syntaxes is probably pretty hard. Thanks -Vincent
WDYT?
Cheers, Fabio
participants (2)
-
Fabio Mancinelli -
Vincent Massol