| xemacs syntax highlighting problem [message #33575] |
Thu, 16 January 2003 04:09  |
![s[1] is currently offline](theme/default/images/xoffline.png.pagespeed.ic.XRkd1fkXye.png "s[1] is currently offline")
s[1]
Messages: 21
Registered: December 2002
|
Junior Member |
|
|
Hi all,
I have a little syntax highlighting problem with my xemacs IDLWAVE mode:
When using linebreaks like
wBase = WIDGET_BASE( /COLUMN, $
TITLE=('Mytitle'), $
GROUP_LEADER= myLeader)
the keywords in the continued lines (TITLE and GROUPLEADER) are
highlighted correctly when I open the file.
But once I edit something in these lines (e.g. change 'Mytitle' to
'AnotherTitle'), the highlight goes away.
When I move the comma from the end of the lines to the start of the next
lines, like:
wBase = WIDGET_BASE( /COLUMN $
,TITLE=('Mytitle') $
,GROUP_LEADER= myLeader)
everything works fine.
Any idea whats wrong and how I can fix it?
Thanks a lot,
Sebastian
|
|
|
|
| Re: xemacs syntax highlighting problem [message #33692 is a reply to message #33575] |
Fri, 17 January 2003 08:04  |
J. Fischer
Messages: 2
Registered: January 2003
|
Junior Member |
|
|
Paul van Delst wrote:
>> This wouldn't really help to improve efficiency.
>
>
> why not?
>
> Most likely - seeing as I futzed around with the standard nedit patterns when I started
> using it. The nedit documentation is a bit sketchy on examples which is the only way I can
> make sense out of the patterns used.
If you have questions about NEdit's highlighting or want to discuss
delicate things like "context requirements" for a pattern, there is
discuss@nedit.org.
Cheers,
Joerg
|
|
|
|
| Re: xemacs syntax highlighting problem [message #33693 is a reply to message #33575] |
Fri, 17 January 2003 07:06 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
"J. Fischer" wrote:
>
> Paul van Delst wrote:
>> Why can't the fontification be based on a "context" buffer (dunno what the proper term
>> would be). That is, you update syntax highlighting based on the immediate context of what
>> surrounds the line in question? I have no idea how one would specify the extent of the
>> context, though.
>
> This wouldn't really help to improve efficiency.
why not?
>> The efficiency issue Carsten mentions can be a real bugger. I use nedit and it checks the
>> entire buffer every keystroke. Not usually a problem unless you have a lot of lines of
>> code and you type in a string near the top of the file. The first use of ' causes all the
>> following 's to be redefined and the character string syntax highlighting "flips". The
>> closing ' in the line I'm typing corrects the situation but it can take a couple of
>> seconds while nedit cogitates over the matter. Can be a real pain in the rear.
>
> There is nothing wrong about checking the entire buffer. Actually, it is
> the only way to get a efficient (almost) real-time and _proper_ syntax
> highlighting.
>
> This puts a higher responsibility on the patterns design, though. What
> you describe is a badly designed patterns set.
Most likely - seeing as I futzed around with the standard nedit patterns when I started
using it. The nedit documentation is a bit sketchy on examples which is the only way I can
make sense out of the patterns used. I probably buggered up a perfectly designed pattern.
> Hope you got the point.
Um, I think so.
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
Ph: (301)763-8000 x7274
Fax:(301)763-8545
|
|
|
|
| Re: xemacs syntax highlighting problem [message #33696 is a reply to message #33575] |
Thu, 16 January 2003 23:59 |
Carsten Dominik
Messages: 45
Registered: February 1998
|
Member |
|
|
>>>> > "s" == s <Sebastian> writes:
s> Thanks for the answers,
s> that explains a lot to me, I just had a look at idlde and vi to see
s> whether they are smarter, but they both don't even try to highlight the
s> keywords.
s> Interestingly enough, when I cat&paste several lines, like
s> TITLE='mytitle',$
s> GROUP_LEADER=myLeader,$
s> MBAR=myBar
s> all lines except the first one get updated.
Yes, when you insert a block of text, all is inserted and then
fontified. So the engine sees the comma before the 2nd and 3rd keyword.
- Carsten
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
