ons, 10 03 2010 kl. 20:21 +0000, skrev Carnë Draug:
> On 10 March 2010 18:53, Søren Hauberg <[email protected]> wrote:
> > 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.
> >
> I guess the middle point will have to suffice then. On the list of
> functions that should be removed from the one I made (or added to the
> current one), could someone suggest them? I'm but a simple basic user
> of Octave, with less than a month experience and in a field that has
> very small needs.
Hmmm, this is kinda hard to do. Which functions are important enough and
which aren't? I don't think we'll ever get general agreement on this.
So, I guess your current solution is the best you can do. Sorry for
adding confusion here.
I had a quick look at your list and you should at least remove 'end'
from the list of functions.
> Also, If a certain user wants all functions listed, he would have to
> do it himself which is not that hard. Maybe a comment could be added
> to instruct a user on how to do it.
I don't think we should ask users to make local modifications of these
files (even if it is easy). For some time I have been thinking about
making a proper Octave plugin for gedit. The next version of gedit
should allow for tab completion and inline documentation, both of which
I'd love to have in my editor, so an Octave plugin would be nice. I
guess it would be possible to allow users to add a list of functions
that should be highlighted via a plugin. This might be better??
It should be said that if I start working on this, then it won't be
until the next version of Ubuntu is out as I won't have access to the
latest gedit till then.
> > I use gedit, so I don't think I can be of much help. I still think we
> > should use Octave-style comments, though.
> >
>
> I also use gedit. When I choose a bunch of lines to be commented
> automatically, it comments every single line. I just added those two
> lines because there's the option and there may be users who like it
> and it doesn't cost me anything. And aren't, since version 3.2, block
> comments an octave feature/style of comments?
Yes, you can do block comments in 3.2. In Matlab you can write
%{
This is a comment
%}
which also works in Octave. We, however, also allow
#{
This is a comment
#}
which I think should be the default. So, something like
<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>
(untested, but hopefully you get the idea)
> Maybe I should change the name of the context to avoid
> misinterpretations. Just in case someone tries to change it further in
> the future.
"printf-format" would probably be a better name.
> >> Actually, anything between double quotes that tries that get that
> >> highlight.
> >
> > Why not single quotes as well?
> >
>
> I just tend to think that if it's between single quotes, everything is
> ignored. One thing that I noticed only now that you mentioned, is that
> the escape character works between single quotes but only in printf.
>
> a = "Escape is working\n"
> printf ("Escape is still working\n")
>
> a = 'Escape is not working\n,'
> printf ('Escape is working again')
>
> I guess I should make the escape and printf work inside single quotes
> as well. What are the functions that make escape work inside single
> quote?
I think 'printf', 'fprintf', 'sprintf', 'error', and 'warning' are the
only functions that come with Octave which supports this directly. Just
as a simplification, I would say you should just try to get the format
working inside single quote strings without concern of how the string
was used.
> > But NaN is indeed a function. When you write
> >
> > a = NaN
> >
> > you are actually calling the 'NaN' function.
> >
>
> So should I make NaN be highlighted as a function or as reserved
> constant as it was before? From what you say, then my opinion is it
> should be highlighted as function.
Actually, all of the constants (pi, eps, ...) are functions these days.
I didn't think too much about it, but I guess it is nice to have them
differently formated than normal functions, though. So, to me it is fine
to leave it as it is. Again, sorry for any confusion I've caused.
> > 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).
> >
>
> What about also highlight the possible arguments for pkg but don't
> highlight the name of the packages? It would be up to the user to make
> sure he typed that name right. Commenting everything until the end of
> the line doesn't seem very correct.
If you write
pkg load image
then it is perfectly fine to just highlight the rest of the line. If
you, however, call 'pkg' like a function, i.e.
pkg ("load", "image")
then technically the rest of the line should not be highlighted as there
could be another function call on the same line, i.e.
pkg ("load", "image"); plot (1:10);
If you can deal with this, then it would be nice, but I don't see it as
being a high priority.
Søren
P.S. When I open an Octave file in gedit it defaults to formatting it
like it was Objective-C (that language also use the .m extension). If
you're going to talk to the GtkSourceView developers, it would be nice
to hear if this is a problem that can be dealt with.
------------------------------------------------------------------------------
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
