GNOME Bugzilla – Bug 648494
octave 3.4 highlight
Last modified: 2011-04-25 18:13:54 UTC
Created attachment 186509 [details] [review] improvement to octave.lang Hi octave released a new stable version a few months ago. I took the change to update the octave lang file. Attached is the diff from what I found on the git repository. I made many changes to the syntax rules which are now much more complete. Also contacted one of the original developers of the syntax (who is currently using my upgraded file). There's many new highlighted functions and I took care to select only the ones that are very unlikely to be removed in future versions of octave. I also tried to use as many classes as possible which is a bit hard since I couldn't find documentation for them. I looked into some of the other lang files to see the classes available. That said, I hope the file does help improving gtksourceview. Carnë
Hi As the original developer of the Octave syntax highlighting in Gedit, I just wanted to give this a thumps-up. Carnë's work clearly improves the current situation. Søren
Review of attachment 186509 [details] [review]: ::: data/language-specs/octave.lang @@ -27,3 +28,3 @@ <property name="mimetypes">text/x-octave;text/x-matlab</property> <property name="globs">*.m</property> - <property name="line-comment-start">%</property> + <property name="line-comment-start">#</property> Why this change? is # supported by matlab? I seem to recall that this file should try to support both octave and matlab (since we have no way to distinguish). adding new keywords will not hurt matlab too much, changing what is inserted when commenting out code will. @@ +44,3 @@ + <style id="operator" _name="Operator" map-to="def:operator"/> + <style id="package-manager" _name="Package Manager" map-to="def:preprocessor"/> + <style id="printf-format" _name="Printf Format" map-to="def:special-char"/> does octave/matlab really have "printf" or is this misnamed? @@ -33,9 +34,16 @@ - <style id="comment" _name="Comment" map-to="def:comment"/> - <style id="floating-point" _name="Floating Point" map-to="def:floating-point"/> - <style id="string" _name="String" map-to="def:string"/> ... 6 more ... + <style id="base-n-integer" _name="Base-N Integer" map-to="def:base-n-integer"/> + <style id="boolean" _name="Boolean" map-to="def:boolean"/> + <style id="builtin" _name="Builtin" map-to="def:builtin"/> ... 13 more ... name is visible in the UI and translatable: should be "Variable" @@ -53,1 +57,2 @@ <include> + <context ref="block-comment"/> why is this including recursively? @@ +114,3 @@ + <!-- Unlike double quoted string, single quote strings in octave do not + allow continuation lines.--> is this true also in matlab?
Hi My point-of-view is very biased, but let me try to present it anyway: GNU Octave and Matlab are two different languages. They both have features the other does not have. GNU Octave is Free Software; Matlab is not. The Octave developers actually tries to contribute to gtksourceview; I do not know if Matlab developers/users do. I get the impression that you (gtksourceview developers) want to treat Octave and Matlab as the same language and want the same syntax file to describe both. I get the impression that you do not want to accept language features that are in Octave, but not in Matlab. Does the opposite also hold? Will you accept language features that are in Matlab, but not in Octave? Will you only accept language features that both languages support? For Octave+Gedit users, the current recommended solution is to manually install Carnë's syntax file, which I find to be a bit of a shame. However, if you will not accept Octave-specific features then this is our only option :-( Regarding the specific questions (sorry for the poor formatting; I do not know of a better way): [Question 1] :: data/language-specs/octave.lang @@ -27,3 +28,3 @@ <property name="mimetypes">text/x-octave;text/x-matlab</property> <property name="globs">*.m</property> - <property name="line-comment-start">%</property> + <property name="line-comment-start">#</property> Why this change? is # supported by matlab? I seem to recall that this file should try to support both octave and matlab (since we have no way to distinguish). adding new keywords will not hurt matlab too much, changing what is inserted when commenting out code will. [Answer 1] Matlab does not support # as a comment-starter; Octave (and practically all other scripting languages in the world) uses it as standard (it allows for shebang's on Unix systems). [Question 2] does octave/matlab really have "printf" or is this misnamed? [Answer 2] Matlab does not have printf (they want you use fprintf without a file descriptor, which is just strange...); Octave has it. [Question 3] @@ +114,3 @@ + <!-- Unlike double quoted string, single quote strings in octave do not + allow continuation lines.--> is this true also in matlab? [Answer 3] Yes. Søren
With regards to the matlab vs octave discussion, here is my position - if there is a good way to distinguish octave files and matlab files we'd be more than happy to have both matlab.lang and octave.lang. This would of course be easier if octave didn't use .m :) As a matter of fact gtksourceview has infrastructure to be able to be able to share the common parts without duplication. Actually I'd be even ok with the split files even if there is no way to automatically pick one. The user will just get one of the two, but he can manually select the other. - If we instead keep them in a single lang file, I am ok with adding octave-specific keywords (ideally split in their own <context> tag so that they are easy to isolate if we decide to split the files). All I am asking is to make some reasonable compromises so that the file works in both cases: for instance as far as I understand "%" for comments works in both cases, while '#' just in one, so I'd prefer to use the first. With regard to my other comments, note that they are specific issues not related to matlab vs octave: for instance for the "printf" context what I was asking was if the name assigned to the context is intentional or if it is just due to the cut&paste from C.lang
(In reply to comment #2) > Why this change? is # supported by matlab? I seem to recall that this file > should try to support both octave and matlab (since we have no way to > distinguish). adding new keywords will not hurt matlab too much, changing what > is inserted when commenting out code will. > Changing this means I can't uncomment octave code from the other people on the project. (In reply to comment #2) > @@ +44,3 @@ > + <style id="operator" _name="Operator" > map-to="def:operator"/> > + <style id="package-manager" _name="Package Manager" > map-to="def:preprocessor"/> > + <style id="printf-format" _name="Printf Format" > map-to="def:special-char"/> > > does octave/matlab really have "printf" or is this misnamed? octave does have printf. I don't know about matlab. (In reply to comment #2) > @@ -33,9 +34,16 @@ > - <style id="comment" _name="Comment" map-to="def:comment"/> > - <style id="floating-point" _name="Floating Point" > map-to="def:floating-point"/> > - <style id="string" _name="String" map-to="def:string"/> > ... 6 more ... > + <style id="base-n-integer" _name="Base-N Integer" > map-to="def:base-n-integer"/> > + <style id="boolean" _name="Boolean" > map-to="def:boolean"/> > + <style id="builtin" _name="Builtin" > map-to="def:builtin"/> > ... 13 more ... > > name is visible in the UI and translatable: should be "Variable" I'm sorry, I don't understand what's wrong there. Could you then correct it if it's just change a word, please? (In reply to comment #2) > @@ -53,1 +57,2 @@ > <include> > + <context ref="block-comment"/> > > why is this including recursively? That's the way block comments work in octave. They're recursive. (In reply to comment #2) > @@ +114,3 @@ > > + <!-- Unlike double quoted string, single quote strings in octave do not > + allow continuation lines.--> > > is this true also in matlab? Matlab only accepts one kind of strings. Octave has double and single strings and they're interpreted slightly different. As you can see, there's plenty of differences between the languages. Plenty of reasons to split them in 2 files. (In reply to comment #4) > With regards to the matlab vs octave discussion, here is my position > > - if there is a good way to distinguish octave files and matlab files we'd be > more than happy to have both matlab.lang and octave.lang. This would of course > be easier if octave didn't use .m :) Actually, objective-C also uses .m so octave and Matlab files are opened with objective-C syntax highlight (seems the mime is not working very well). Splitting this in 2 files would still force the user to manually select the language (or remove the objective-C lang file) (In reply to comment #4) > - If we instead keep them in a single lang file, I am ok with adding > octave-specific keywords (ideally split in their own <context> tag so that they > are easy to isolate if we decide to split the files). All I am asking is to > make some reasonable compromises so that the file works in both cases: for > instance as far as I understand "%" for comments works in both cases, while '#' > just in one, so I'd prefer to use the first. It's highlighting comments in both % and #. The problem is on using the automatic comment and uncomment. If you select % then you can't use them on octave projects since most of octave developers will be using #. I think they can be splitted. If I remeber correctly, you can have 2 lan files, with different <metadata> and load only the <context> that are commmon. If you split, you don't need to compromise there.
(In reply to comment #4) > With regards to the matlab vs octave discussion, here is my position > > - if there is a good way to distinguish octave files and matlab files we'd be > more than happy to have both matlab.lang and octave.lang. Can we do this? I don't think there is a good way make the distinction at the moment, but personally I'm okay with picking highlighting manually (Gedit has a quite nice GUI for this). My problem is that I am not a Matlab user, so I would simply not be comfortable with contributing a 'matlab.lang' implementation (also, it really isn't my itch to scratch). > This would of course be easier if octave didn't use .m :) I feel your pain, brother :-) > As a matter of fact gtksourceview has infrastructure to be able to be able to > share the common parts without duplication. I confess: I am lazy :-) Can we start with having two independent .lang files and then slowly start the sharing? As I mentioned before, I am not comfortable working on the Matlab side of things, so it's kinda hard to figure out what should be shared. Søren
by the way, does this obsoletes the https://bugzilla.gnome.org/show_bug.cgi?id=613378 report? It seems to me that that report reached the same conclusion: the two lang file should be split.
Ok, I bit the bullet, split the file and committed them. Please double check if everything is correct. http://git.gnome.org/browse/gtksourceview/commit/?id=f25a00aefa97fcd47a73ee9d40c93eb2a4d2dc5b Thanks for the patience and sorry for the delay, but as you saw it was not a straightforward patch and not being familiar with matlab/octave I kept procrastinating :-)
*** Bug 613378 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > by the way, does this obsoletes the > https://bugzilla.gnome.org/show_bug.cgi?id=613378 report? Yes, it does. (In reply to comment #8) > Ok, I bit the bullet, split the file and committed them. Please double check if > everything is correct. > > http://git.gnome.org/browse/gtksourceview/commit/?id=f25a00aefa97fcd47a73ee9d40c93eb2a4d2dc5b > > Thanks for the patience and sorry for the delay, but as you saw it was not a > straightforward patch and not being familiar with matlab/octave I kept > procrastinating :-) Seems good with me. Thank you for taking care of this.