ons, 10 03 2010 kl. 11:54 +0000, skrev Carnë Draug:
> On 10 March 2010 00:48, Søren Hauberg <[email protected]> wrote:
> > tir, 09 03 2010 kl. 22:45 +0000, skrev Carnë Draug:
> >> *On continuation lines
> >> ... is also identified as a continuation line character
> >> continuation lines characters are ignored if they are between single
> >> quotes only
> >
> > It is good that '...' is treated as a continuation, but why aren't they
> > ignored when between double quotes?
>
> If I got it right, it seems that I can't use them with single quotes.
>
> # this works
> a = "this string should continue ...
> here"
> # this does not work
> a = 'this string never gets ...
> here'
You're right; sorry.
> >> *On comments
> >> comments can be made after the continuation line characters
> >> added shebang line (it's no longer just a comment line)
> >
> > Great. Looking at the file I see the following oddities with respect to
> > comments:
> >
> > <metadata>
> > <property
> > name="mimetypes">text/x-octave;text/x-matlab</property>
> > <property name="globs">*.m</property>
> > <property name="line-comment-start">%</property>
> > <property name="block-comment-start">^%{$</property>
> > <property name="block-comment-end">^%}$</property>
> > </metadata>
> >
> > This only contains Matlab-style comments. Shouldn't it also include
> > Octave-style comments, i.e. "#" instead of "%"?
> >
> > Also, it would be great if Octave-style block comments could be
> > supported.
>
> This block has nothing to do with the syntax highlight. I believe it's
> where the text editor comes to get info on how to comment code
> automatically.
That seems like a pretty good reason to use Octave-style comments here.
If I were to use some fancy editor feature for commenting out large
quantities of text, I would want the editor to use Octave-style
comments.
> >> *On functions
> >> added all functions (I hope).
> >
> > Do we really want to do this? It seems like a very hard maintenance task
> > to keep this up to date.
>
> It takes less than 5min I think.
Yes it takes 5 minutes for you. The problem is the GtkSourceView
maintainers. They try to keep backwards compatibility meaning that if we
remove a function from Octave, they will not remove said function from
the syntax highlighter. I agree with their logic, but it has the
potential downside that we end up highlighting functions that doesn't
exist. If you add all currently available functions to the highlighter
then the chance of this happening increases quite a bit.
That being said, I like it when built-in functions are highlighted, so
I'm not quite sure what the best approach is here.
> >> and "pkg" (mapped it to preprocessor).
> >
> > Why does 'pkg' get a special treatment? Why not just treat it like a
> > function?
>
> Like I mentioned, I took the perl lang file as an example (because
> it's the only language that I know). In perl, there's the "use" and
> require" functions that loads specified modules, functions and checks
> for the Perl version being used. So I did the same with pkg here. Is
> there any other octave function that behaves similarly?
You are thinking in terms of
pkg load my_package
right? I guess I can see the point in that.
> >> *On metadata
> >> added block comment "start" and "end" to the list (can someone test
> >> this please? I don't know any editor that uses this)
> >
> > I don't know what this means?
>
> Explained above what this metadata block does. However, I don't have a
> text editor that tries to insert these block comments automatically so
> I don't if it works correctly and identifies regexp or if it will
> literally place a ^%{$ at the start of the first line that the user
> wants to comment.
I use gedit, so I don't think I can be of much help. I still think we
should use Octave-style comments, though.
> >> *On operators
> >> there's syntax for operators now. I tried to be careful with the
> >> transpose operator. Should map all of them
> >> what's the thing with - and +? When do they define the signal
> >> instead
> >> of being operators? Should they be considered numbers in those
> >> situations?
> >
> > I don't understand the question. Could you provide an example?
>
> b = {2 + 3} # plus sign is highlighted as operator
> b = {2 +3} # plus sign should be highlighted as number?
> b = 2 +3 # plus sign is highlighted as operator which is correct.
> But if I had set up tp recognize the line before as number JUST by
> checking if there's no space between it and the next number, it would
> incorrectly be highlighted as number. If someone can tell me exactly
> when + and - is what, I could try to write a regexp for that.
I actually think this matches with the way Octave parses things.
Consider the following piece of code
a = [-1 +2]
which is the same as
a = [-1, 2]
so I guess it makes sense to parse the signs the way they are right now.
> >> *On strings
> >> added a printf regexp that should identify the formatting
> >
> > Cool! Could this be extended to also cover 'sprintf', 'fprintf', 'error'
> > and 'warning' ?
>
> If they have the same syntax as printf, it's already working.
Great!
> Actually, anything between double quotes that tries that get that
> highlight.
Why not single quotes as well?
> Should I change that? Or should I keep so it's possible to
> store a format in a variable like this
>
> format = "now, be should be %g\n"
> fancy_var = 5
> printf(format, fancy_var)
>
> If they are not exactly the same, what are the differences?
I think your current approach sounds just fine.
> >> * some reserved keywords, like NaN are also functions. Should I refine
> >> the regexp to see if they are followed by parenthesis and are
> >> therefore functions instead of a constant
> >
> > That sounds too complex too me (without really having any benefit)
>
> Isn't the whole point of this to have the code highlighted to
> distinguish stuff like constants from functions for example? That's
> the benefit.
But NaN is indeed a function. When you write
a = NaN
you are actually calling the 'NaN' function.
> >> * should I list all the pkg options instead of just highlight
> >> everything after pkg?
> >
> > I don't understand the question.
>
> Like I mentioned before, I used Perl as example. They have a list of
> stuff that can come after the "use" and "require" functions. Not a
> list of all modules, only most of pragmas. I just made it to highlight
> everything that comes after pkg until the end of the line. I should
> probably make a list of only the pkg commands instead. What about the
> name of the different packages?
I think just highlighting the rest of the line is fine. You really don't
want to list all possible packages in there. Think maintenance (both on
your part but also on the GtkSourceView maintainers part).
Søren
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
