Re: [Pallavi-users] My own lexer and in Python (not C)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
 <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
 
 
Dusty Phillips wrote:
<blockquote
 cite="mid:7ec...@ma..."
 type="cite"> 
 <pre wrap="">wxSTC doesn't associate a lexer with an extension. Currently there is
a plugin in Pallavi that scans filesystems and sets the lexer based on
the file extension. It should be possible to either adapt this plugin
or create a similar one that calls another plugin instead.
 </pre>
</blockquote>
OK with me. 
<blockquote
 cite="mid:7ec...@ma..."
 type="cite"> 
 <pre wrap="">With Pallavi's design, I don't think you'd want to create a single
monolithic plugin that retains control like this. Pallavi is very
modular; I think you would probably rather have a plugin that sets up
a few listeners (for keystrokes, focus events, etc). When an event
comes in on these listeners, I would suggest checking to see if the
currently focused buffer is "managed" by your plugin (ie: has a
.design extension), and then do the lexing on it.
 </pre>
</blockquote>
I have to think about that. Since listeners seem to register globally
(rather than for the active window), then the possibility for a number
of listeners to the same event can mean conflict. 
<blockquote
 cite="mid:7ec...@ma..."
 type="cite"> 
 <pre wrap="">I would suggest having separate plugins for each of these activities
as well. Pallavi has no support for the latter two features yet, but
it would be neat if a language-agnostic plugin could be designed to do
this. In my mind such a plugin would NOT have structural information,
but would rely on a separate plugin to provide this kind of
information based on the language.
 </pre>
</blockquote>
In the "trusty's own lexer"code, the OnStyleNeeded handler does all
three tasks in the same breath! 
I am not sure what you mean by structural information. To do syntax
highlighting one needs some kind of tokenization. To do meaningful
auto-completion, one needs to know the context (module, class, method,
etc.) and that does mean structural information. 
 
<blockquote
 cite="mid:7ec...@ma..."
 type="cite"> 
 <pre wrap="">I think it is feasible, though all the core support may not be
available yet. Again, it comes down to listeners -- You could have a
plugin that checks each time a textview is focused to see if it is one
that is managed. If it is, it could then add the menu entries and
ensure the tree-control is visible, if not, it can do the reverse.
 </pre>
</blockquote>
Yes, "managed" is the keyword. Although it is possible to do it this
way, I would rather see a clean methodical solution, involving, in
addition to "plugin' also "managers", which are plugin containers,
associated by the system with file extension, overriding lexers. 
<blockquote
 cite="mid:7ec...@ma..."
 type="cite">
 <pre wrap="">
As for within my plans, I do have it in mind to provide lexing support
for more languages than scintilla provides. </pre>
</blockquote>
I believe the problem with that is that - if I got it right - to add a
lexer (an enumeration, really), you must touch a C h file and recompile
the system, which seems to be beyond the power of python. 
 
&nbsp;&nbsp;&nbsp; Avner. 
</body>
</html>