Hello folks!
Lately I'm working with BBEdit mostly with JavaScript and PHP. While
the built-in JavaScript
language module does a good job in syntax coloring, it does not (at
last for my purposes)
the best to build up a proper function pop-up. Though I have to admit,
it's a function popup,
not an entity popup, so it's doing it's job - but not as I and maybe
other people may need.
Problem is, that especially in JavaScript, you do not only define
functions, but also classes,
data, constants and such. But those are not recognized by the language
module. Therefore an
source code expression like
window.myClass.myAttribute = "some data" ;
will not be in the function popup menu. Why should it? =)
But in very large or complex files, it would be very handy to find
them with the popup menu, too.
OK, that was the first part.
Second is, I do not only develop in those two scripting languages, but
many others. And the one
and only thing, they all share (for me), is how I embed comments: In
HeaderDoc syntax (with
some augmentations by myself, but that's not important now). So in
general, I put always
BEFORE the occurence in source code somewhere a multiline HeaderDoc
comment to describe
an entity. The above code sample would become like:
/*!
@attribute window.myClass.myAttribute
@abstract Contains some data, that absolutely noone needs.
*/
window.myClass.myAttribute = "some data" ;
So, the solution for me was to program a language module for BBEdit,
that does not aim at any
source code parsing, but one, that finds those comments, then searches
the file for the entity
after the comment and adds them to the function popup menu. So far it
works great, and as
soon as I have implemented some Preferences code, to easily write
prefs for the module with
a Terminal and the 'defaults' command, I consider to publish it on my
homepage and maybe some
other nice features (like automated documentation generation somehow
by calling headerdoc).
But here is the problem: With this approach and the current way,
BBEdit is associating language
modules, I need to manually assign all files the 'HeaderDox' language
at the bottom left of a file's
window, which is some kind of annoying.
Second, syntax coloring does not work, because my module does not
(yet) implement it and why
should it?
My proposal, especially to any BBEdit developer, who might read this,
would be, to provide users
an additional menu at the right of the function popup menu, that is
for 'documentation modules',
which are not associated by file extension/source code language, but
by user preference. It should
co-exist with the function pop-up menu.
That way, existing modules that do syntax coloring (especially the
codeless, which are done quite
fast - very handy!), will not be overridden by a module like mine -
and I would not have to do
syntax coloring / make another language module for each language. And
it would use the same
API as the current language modules.
What do you think?
Any ideas to make it better?
Best regards,
Lorenz Hipp
100% IRDiSCH
[email protected]
www.irdisch.de
--
You received this message because you are subscribed to the
"BBEdit Talk" discussion group on Google Groups.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
<http://groups.google.com/group/bbedit?hl=en>
If you have a feature request or would like to report a problem,
please email "[email protected]" rather than posting to the group.
Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>
