[Kommander-devel] KTextEditor in Kommander

[Eric Laffoon]

On Tuesday 05 September 2006 1:48 am, Andras Mantia wrote:
> On Tuesday 05 September 2006 11:09, Eric Laffoon wrote:
> > Thanks Andras, this is a big improvement. Unfortunately a few things
> > are not handled well yet. At least one may be a real headache but
> > most should be easy. I'm sure you're way faster at this than me...
>
> Well, it's only about writing the correct rules. ;-)
>
> > 1) functions that don't use method definitions lock highlighting
> > until something else comes along...
> > @dcop()
> > @global()
> > @setGlobal()
> > @exec()
> > @readSetting()...
> > These continue highlighting into the parenthesis and beyond.
>
> Should be fixed, but for some reason here the parenthesis are not bold,
> while for the rest are. I have no idea why, as the rule for them is
> exactly the same...

Hah, I think it's more than that if you look closer... ;-)
>
> > 2) Loop variables (@i) are not handled and I'm not sure how much of a
> > pain they are, but if we could at least stop highlighting on a space
> > after @unknown that would be good.
>
> Same bug as above.

These seem okay now as they stop after spaces, so I'm not sure what you mean 
by same bug.
>
> > 3) This function statement seems to confuse quote and parenthesis
> > highlights @exec(@readSetting(photoviewer, kuickshow)
> > "@String.section(@TreeWidget3.selection(),"\t", 0)")
>
> I enabled highlighting inside the strings, but the above will still be
> incorrect as it's not easy to handle quoted strings inside quoted
> string and usually no language allows that, unless you escape the inner
> quotation marks (or use single quotes instead of double quoted there).
> So I think this part cannot be solved on the highlighting level, it
> should be solved on parsing level.

The actual issue here is that anything inside parenthesis is handled as a 
separate entity and manages quotes consistently whereever it is placed. So 
technically it's not quotes inside quotes as much as functions with quoted 
text inside other functions with quoted text. The reason for this is that 
escaping quotes, while necessary at times, would be really annoying for a 
function based process that inherently ends up nesting so many functions. So 
it's really about a two step parse, vs one.
>
> > 4) Maybe I should apologize for making too much work. ;-) The
> > following is utterly trashed...
> > @if(@String.length(@readSetting(photopath, "")) < 5)
> >   @exec(kdialog --title "khphoto setup" --msgbox "You will need to
> > set your root directory for where your photos are. This only offers
> > this the first time it runs, but it helps it to start faster if it
> > doesn't have to search your whole home directory.")
> >   @writeSetting(photopath, @exec(kdialog --getexistingdirectory
> > --title "Photo Root?"))
> > @endif
> > It appears the period after "are" ends the green function
> > highlighting, but the apostrophe in doesn't starts red quote
> > highlighting which overrides everything for the remainder of all
> > text.
>
> Works fine now.
>
> If you find anything wrong, just tell me. ;-)
>
> Andras
Everything was looking great and I can't tell you how exciting it is. Then I 
started running across something truly odd. Have a look at this...
@TreeWidget1.setText(@exec(find /etc @env(CONFIG_PROTECT) -iname 
"._cfg????_*"))
This is just one example, one of the worst. Many eventually balance the first 
and last parenthesis, but this doesn't. Typically they skip a closing 
parenthesis and then pick it up later. The point is, it's not just what is 
bold, the entire yellow highlight balancing is off. Did I mention I really 
love that feature? How does color highlighting confuse parenthesis matching? 
The apparent cause seems to be Kommander functions like @global( or @env(, 
which is what was fixed. Strange...

BTW not wanting to pull you off the work on Quanta, but given the way we can 
easily parse functions and widgets how much work is involved in auto 
completion?
-- 
Eric Laffoon
Project Lead - kdewebdev module