| Re: xemacs syntax highlighting problem [message #33572] |
Thu, 16 January 2003 07:32  |
![Paul Van Delst[1] is currently offline](theme/default/images/xoffline.png.pagespeed.ic.XRkd1fkXye.png "Paul Van Delst[1] is currently offline")
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Carsten Dominik wrote:
>
>>>> >> "s" == s <Sebastian> writes:
>
> s> Hi all,
> s> I have a little syntax highlighting problem with my xemacs IDLWAVE mode:
> s> When using linebreaks like
> s> wBase = WIDGET_BASE( /COLUMN, $
> s> TITLE=('Mytitle'), $
> s> GROUP_LEADER= myLeader)
> s> the keywords in the continued lines (TITLE and GROUPLEADER) are
> s> highlighted correctly when I open the file.
> s> But once I edit something in these lines (e.g. change 'Mytitle' to
> s> 'AnotherTitle'), the highlight goes away.
> s> When I move the comma from the end of the lines to the start of the next
> s> lines, like:
> s> wBase = WIDGET_BASE( /COLUMN $
> s> ,TITLE=('Mytitle') $
> s> ,GROUP_LEADER= myLeader)
> s> everything works fine.
>
> s> Any idea whats wrong and how I can fix it?
>
> It cannot be fixed. When editing, [X]Emacs looks only at the current
> line to update syntax highlighting. This is mainly an efficiency
> question - you don't want to scan the whole buffer after every
> character typed.
>
> When there is no comma before the keyword, there is no way to tell (by
> looking at the current line only) if it is a keyword or a variable
> assignment.
>
> On the other hand, when opening a new file, the whole buffer is
> fontified in one go, and in this case the engine notices
> continuation lines and highlights correctly.
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.
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.
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
Ph: (301)763-8000 x7274
Fax:(301)763-8545
|
|
|
|
| Re: xemacs syntax highlighting problem [message #33573 is a reply to message #33572] |
Thu, 16 January 2003 05:13  |
Carsten Dominik
Messages: 45
Registered: February 1998
|
Member |
|
|
>>>> > "s" == s <Sebastian> writes:
s> Hi all,
s> I have a little syntax highlighting problem with my xemacs IDLWAVE mode:
s> When using linebreaks like
s> wBase = WIDGET_BASE( /COLUMN, $
s> TITLE=('Mytitle'), $
s> GROUP_LEADER= myLeader)
s> the keywords in the continued lines (TITLE and GROUPLEADER) are
s> highlighted correctly when I open the file.
s> But once I edit something in these lines (e.g. change 'Mytitle' to
s> 'AnotherTitle'), the highlight goes away.
s> When I move the comma from the end of the lines to the start of the next
s> lines, like:
s> wBase = WIDGET_BASE( /COLUMN $
s> ,TITLE=('Mytitle') $
s> ,GROUP_LEADER= myLeader)
s> everything works fine.
s> Any idea whats wrong and how I can fix it?
It cannot be fixed. When editing, [X]Emacs looks only at the current
line to update syntax highlighting. This is mainly an efficiency
question - you don't want to scan the whole buffer after every
character typed.
When there is no comma before the keyword, there is no way to tell (by
looking at the current line only) if it is a keyword or a variable
assignment.
On the other hand, when opening a new file, the whole buffer is
fontified in one go, and in this case the engine notices
continuation lines and highlights correctly.
This is pretty much the only bug in IDLWAVE where I have really no
idea how to fix it - as much as I would like to. The only viable
workaround is what you have already discovered, but that is ugly (I
think...).
You can restore the correct fontification at any time with
M-x font-lock-fontify-buffer
If you want to do this often, bind it to a key. I have:
(define-key global-map [f2] 'font-lock-fontify-buffer)
Hope this helps
- Carsten
|
|
|
|
| Re: xemacs syntax highlighting problem [message #33695 is a reply to message #33572] |
Thu, 16 January 2003 23:58 |
Carsten Dominik
Messages: 45
Registered: February 1998
|
Member |
|
|
>>>> > "PvD" == Paul van Delst <paul.vandelst@noaa.gov> writes:
PvD> Why can't the fontification be based on a "context" buffer (dunno
PvD> what the proper term would be). That is, you update syntax
PvD> highlighting based on the immediate context of what surrounds the
PvD> line in question? I have no idea how one would specify the extent
PvD> of the context, though.
In principle this should not be a problem. Font-lock could easily be
told to look at two line, for example. In practice, the decision to
only look at the current line happens in font-lock, a package separate
from IDLWAVE, and we have no control over it. As far as I know, there
is no configuration option available to change this behavior.
- Carsten
|
|
|
|
| Re: xemacs syntax highlighting problem [message #33698 is a reply to message #33572] |
Thu, 16 January 2003 21:16 |
J. Fischer
Messages: 2
Registered: January 2003
|
Junior Member |
|
|
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.
> 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. The patterns described by
a beginning and ending ' simply need an "error expression" to make it
stop. Confirm the NEdit documentation. You have to determine what can't
be or normally won't be (highlighting needn't be a syntax parser, it
shall only help to reduce errors) inside '' (for example if '' should be
contained in a single line, then you would give $ as error expression,
or does the language you are using have comments? Do they normally occur
inside '').
Hope you got the point.
Cheers,
Joerg
|
|
|
|
| Re: xemacs syntax highlighting problem [message #33716 is a reply to message #33572] |
Thu, 16 January 2003 10:01 |
s[1]
Messages: 21
Registered: December 2002
|
Junior Member |
|
|
Thanks for the answers,
that explains a lot to me, I just had a look at idlde and vi to see
whether they are smarter, but they both don't even try to highlight the
keywords.
Interestingly enough, when I cat&paste several lines, like
TITLE='mytitle',$
GROUP_LEADER=myLeader,$
MBAR=myBar
all lines except the first one get updated.
The "context" to fix this problem would only be the previous line. I
always found the emacs lisp stuff too confusing, but naiv as I am I
would imagine that it can't be too hard to do it, or?
Best regards,
Sebastian
On Thu, 16 Jan 2003, Paul van Delst wrote:
> Carsten Dominik wrote:
>>
>>>> >>> "s" == s <Sebastian> writes:
>>
>> s> Hi all,
>> s> I have a little syntax highlighting problem with my xemacs IDLWAVE mode:
>> s> When using linebreaks like
>> s> wBase = WIDGET_BASE( /COLUMN, $
>> s> TITLE=('Mytitle'), $
>> s> GROUP_LEADER= myLeader)
>> s> the keywords in the continued lines (TITLE and GROUPLEADER) are
>> s> highlighted correctly when I open the file.
>> s> But once I edit something in these lines (e.g. change 'Mytitle' to
>> s> 'AnotherTitle'), the highlight goes away.
>> s> When I move the comma from the end of the lines to the start of the next
>> s> lines, like:
>> s> wBase = WIDGET_BASE( /COLUMN $
>> s> ,TITLE=('Mytitle') $
>> s> ,GROUP_LEADER= myLeader)
>> s> everything works fine.
>>
>> s> Any idea whats wrong and how I can fix it?
>>
>> It cannot be fixed. When editing, [X]Emacs looks only at the current
>> line to update syntax highlighting. This is mainly an efficiency
>> question - you don't want to scan the whole buffer after every
>> character typed.
>>
>> When there is no comma before the keyword, there is no way to tell (by
>> looking at the current line only) if it is a keyword or a variable
>> assignment.
>>
>> On the other hand, when opening a new file, the whole buffer is
>> fontified in one go, and in this case the engine notices
>> continuation lines and highlights correctly.
>
> 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.
>
> 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.
>
> paulv
>
> --
> Paul van Delst
> CIMSS @ NOAA/NCEP/EMC
> Ph: (301)763-8000 x7274
> Fax:(301)763-8545
>
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
