Re: [Geany-devel] Color Schemes Menu Patches
On 04/29/11 09:59, Nick Treleaven wrote: On Sun, 03 Apr 2011 23:54:03 -0700 Matthew Brush wrote: Hi, I have made some minor changes to the Color Schemes menu, I wanted to see if they look ok. One of my concerns is that maybe opening/reading each color scheme file like this might be "too slow", but it seems to only happen once, so I'm not sure whether it's significant. It "feels" fine when I use it with all of the geany-themes color schemes. Sorry for the late response. I think the color scheme menu should probably be replaced with a dialog instead. That way the color scheme files don't need to be read unless the dialog is shown. Although this is not a noticeable performance problem, I think it would be good practice to do this, and using a dialog is more flexible. I have actually started a little bit with this previously, I've added a new tab under Editor tab called Colors, which has a combo box to select a theme, below that is a list view (GtkTreeView) which lists the lexer states for each theme to be edited in the list for; use default, fg color, bg color, bold, italic, underline columns in each row. So far I have only edited the glade file to add the UI elements, I wrote very little actual code for it so far. This would be quite an ambitious undertaking, which is why I didn't proceed much further yet. Tomorrow I will try and find what I have and push a branch to at least serve as some ideas and/or starting point. In the interim, assuming that the performance isn't an issue, and that it only occurs on load (where all the tags for open files and stuff are being loaded anyway), the main patch (0001-...) is, imo, pretty clean and low-impact, could it be applied? It's nice to see a proper name for the themes, like 'Slush and Poppies' rather than something like 'slush_and_poppies.conf' and it allows a description of the theme in the tooltip. The main patch is applied in my 'colorschemes_fixup' branch on GitHub[1] if you want to try it out and also see the state of the merging of geany-themes into the main Geany code. Cheers, Matthew Brush [1] https://github.com/codebrainz/geany/tree/colorscheme_fixup ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Set Filetypes Menu
On 04/29/11 09:34, Nick Treleaven wrote: On Fri, 29 Apr 2011 17:06:46 +0100 Nick Treleaven wrote: On Thu, 28 Apr 2011 20:13:05 -0700 Matthew Brush wrote: - I generally wouldn't consider CSS a markup language, but it probably technically is. IMHO it would be more apt to put it under Miscellaneous. I agree, I think there is little overlap with CSS and document languages like HTML. As Lex and Enrico probably prefer it in the Markup group, I decided to leave it. It may be more practical there. Agree. Lex's point is true, and I think it truly is a markup language, according to Wiki anyway. - I believe LaTex, Markdown, and reStructuredText are Markup Languages. Good point also, and txt2tags. And YAML. Now done. Heh. I actually had put YAML in the above list, but I removed it while revising my message before sending because: 1) It's an acronym for 'YAML Ain't Markup Language'. 2) I've only ever used it (or seen it used) as a configuration or serialization format, rather than for marking anything up. I'm not saying it doesn't fit best under Markup, just why I didn't list it :) I'm gonna try it out later tonight. Thanks Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GObject, new plugin interface .... & Vala bindings
Am 29.04.2011 19:12, schrieb Nick Treleaven: I think this is great. It might be doable to maintain this with Geany's API when ready. This would be a big leap forward for plugin writers, and little/no impact on the existing API. Will Geany's API ever be ready? I doubt so, especially at this development rate. But this vala bindings are great for sure. do discuss any further I'd like to point to an email Enrico sent earlier this year onto this list: http://lists.uvena.de/geany-devel/2011-February/003905.html Originally Geany wasn't designed/coded to work with GObject. Moving to an plugin interface using this would most likely cause rewriting of a lot of code. However, if really somebody of you like to go this further I suggest to start a new branch where all changes can be tracked in. But before we can discuss about the positive/negativ points I just want to ask who likes to take over this task as a kind of lead engineer and project manager to be the lead here having in mind it will most likely not a 5-minute-task? What's the outcome here? I saw a lot of technical discussion followed up by my original posting but nobody took over the rule to bring all the idea into synch. Not sure whether I might did miss something. Just to add my point of view: 1. I think this would be very disruptive to both Geany's core and existing plugins. I also really don't like GObject code in C. Wasn't the idea to implement the GObject interface one by one, maintaining the current one in the meantime (and a bit after)? You can also always do compatibility magic with cpp or some sort. I don't see it disruptive for plugin writers. 2. Would it actually work? Geany is not a shared library, so this might cause problems for dynamic language bindings. Until this and perhaps other issues are dealt with, we should not start on using GObject IMO. (To prove dynamic bindings would be possible, a minimal binding for the current API could be made). It works for all other the programs (e.g. gedit) too, doesn't it? I don't hope you just killed all hope with your mail, we basically already agreed this would be a nice thing to have, no? Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GObject, new plugin interface .... & Vala bindings
On Thu, 28 Apr 2011 09:01:08 +0200 Frank Lanitz wrote: > > During the last weeks a huge number mails at this list was stating to > > make usage of GObject on building up a new plugin interface. It has been > > talked about libpeas and adding support for Vala, Python etc. Before we BTW Colomban started work on Vala bindings without changing the plugin API: http://gitorious.org/geany-vala-binding I think this is great. It might be doable to maintain this with Geany's API when ready. This would be a big leap forward for plugin writers, and little/no impact on the existing API. > > do discuss any further I'd like to point to an email Enrico sent > > earlier this year onto this list: > > > > http://lists.uvena.de/geany-devel/2011-February/003905.html > > > > Originally Geany wasn't designed/coded to work with GObject. Moving to > > an plugin interface using this would most likely cause rewriting of a > > lot of code. However, if really somebody of you like to go this > > further I suggest to start a new branch where all changes can be > > tracked in. > > But before we can discuss about the positive/negativ points I just > > want to ask who likes to take over this task as a kind of lead > > engineer and project manager to be the lead here having in mind it will > > most likely not a 5-minute-task? > > What's the outcome here? I saw a lot of technical discussion followed up > by my original posting but nobody took over the rule to bring all the > idea into synch. Not sure whether I might did miss something. Just to add my point of view: 1. I think this would be very disruptive to both Geany's core and existing plugins. I also really don't like GObject code in C. 2. Would it actually work? Geany is not a shared library, so this might cause problems for dynamic language bindings. Until this and perhaps other issues are dealt with, we should not start on using GObject IMO. (To prove dynamic bindings would be possible, a minimal binding for the current API could be made). Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Color Schemes Menu Patches
On Sun, 03 Apr 2011 23:54:03 -0700 Matthew Brush wrote: > Hi, > > I have made some minor changes to the Color Schemes menu, I wanted to > see if they look ok. One of my concerns is that maybe opening/reading > each color scheme file like this might be "too slow", but it seems to > only happen once, so I'm not sure whether it's significant. It "feels" > fine when I use it with all of the geany-themes color schemes. Sorry for the late response. I think the color scheme menu should probably be replaced with a dialog instead. That way the color scheme files don't need to be read unless the dialog is shown. Although this is not a noticeable performance problem, I think it would be good practice to do this, and using a dialog is more flexible. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Set Filetypes Menu
On Fri, 29 Apr 2011 14:26:35 +1000 Lex Trotman wrote: > And to add one, why is R a script and all others in that menu source, > since its the scripting menu? Now changed to source file. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Set Filetypes Menu
On Fri, 29 Apr 2011 17:06:46 +0100 Nick Treleaven wrote: > On Thu, 28 Apr 2011 20:13:05 -0700 > Matthew Brush wrote: > > filetype names are not translated IIRC. Although the *title* is translated, which is what we were talking about (oops). > > There's also a few other quirks I've noticed in the 'Set Filetypes' menus: > > > > - I generally wouldn't consider CSS a markup language, but it probably > > technically is. IMHO it would be more apt to put it under Miscellaneous. > > I agree, I think there is little overlap with CSS and document > languages like HTML. As Lex and Enrico probably prefer it in the Markup group, I decided to leave it. It may be more practical there. > > - I believe LaTex, Markdown, and reStructuredText are Markup Languages. > > Good point also, and txt2tags. And YAML. Now done. > > - I don't know COBOL but I think it's a programming language isn't it? > > > > - NSIS and CMake files, while domain-specific, are still > > scripting/programming languages. > > - 'SQL Dump file' seems a bit odd, since it's a file containing language > > constructs and is "run" by the db engine, maybe it should be 'SQL file' > > or 'SQL source file'. > > - The wording 'Miscellaneous Languages' makes you think the contents of > > the submenu will contain (programming) Languages, but a config, diff, or > > gettext file for ex, doesn't really seem to be a language. The word > > 'Languages' could be removed from that menu item, which would imply that > > the contents of that menu will be 'Filetypes', more generally. These all done also. Thanks for the suggestions. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Set Filetypes Menu - group names
On Thu, 28 Apr 2011 20:13:05 -0700 Matthew Brush wrote: > Hi, > > I just noticed the change[1] in wording of the set filetypes menu which > was something that had (slightly) bothered me before, since I personally > consider most of the scripting languages as programming languages as > well. This is why I changed it, scripting is programming. > I'm not sure that the word "Compiled" is the best choice though, > since it's kind of vague: > > Is Vala a compiled language because it's compiled into C code? > Is Python *not* compiled because it's compiled into bytecode? > Is Java a compiled language? > > I'm sure you can see what I mean, there's a lot of gray area using the > term Compiled, since many languages can either be compiled to machine > code, interpreted by a VM/runtime, compiled then interpreted, compiled > to one format then another, compiled just in time, and so on. Obviously all source code is compiled at some point. The Compiled group all have one thing in common - separate compilation is normally required before execution. This is still true for Java. Python compiles on the fly, and is obviously thought of as a scripting language rather than a compiled one. > Unfortunately I don't really have much for alternative terms, but a few > possibilities for better categorization could be: > > - By the current categories, but putting filetypes under each one they > fit in. that depends on how you interpret compiled. > - By changing Scripting to Interpreted and then shuffling some filetypes > around to reflect the way the languages are usually compiled/run. D can be interpreted or compiled, but not scripting. It's normally compiled, but the point is this categorisation is not much better than the status quo. > - By the current categories, no change, since users will get used to > where to find their languages pretty quickly. > > - By Static vs Dynamic Typing Some are both e.g. Haxe. > - By programming language paradigm (ie. oop, functional, etc), and then > each programming language could fall below more than one menu item if > they are multi-paradigm. I think this is too complicated. > - By just Programming Languages, so that the Compiled and Scripting > menus get merged. This could make the menu long/scroll. SciTE does > this but with fewer languages. I really don't see what's wrong with the current separation, after a first glance at each it should be easy to understand. > - By alphabetic order, with a menu item for each letter of the alphabet > unless no filetypes fall under a letter, then don't show it. This could > be ugly in terms of code/i8n and appearances. IIRC another editor is > doing this (Notepad++?). filetype names are not translated IIRC. Not sure this proposal is better. > There's also a few other quirks I've noticed in the 'Set Filetypes' menus: > > - I generally wouldn't consider CSS a markup language, but it probably > technically is. IMHO it would be more apt to put it under Miscellaneous. I agree, I think there is little overlap with CSS and document languages like HTML. > - I believe LaTex, Markdown, and reStructuredText are Markup Languages. Good point also, and txt2tags. > - I don't know COBOL but I think it's a programming language isn't it? > > - NSIS and CMake files, while domain-specific, are still > scripting/programming languages. Ok. > - 'SQL Dump file' seems a bit odd, since it's a file containing language > constructs and is "run" by the db engine, maybe it should be 'SQL file' > or 'SQL source file'. I know a file containing SQL is often the result > of dumping a database, but is it the only time you would end up with > such a file? > > - The wording 'Miscellaneous Languages' makes you think the contents of > the submenu will contain (programming) Languages, but a config, diff, or > gettext file for ex, doesn't really seem to be a language. The word > 'Languages' could be removed from that menu item, which would imply that > the contents of that menu will be 'Filetypes', more generally. > > I could be wrong on these, they're just my observations. None of these > are a big deal, but it was something I questioned probably even the > first time I opened Geany and every time I select a filetype since. Agree also on all these points. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Set Filetypes Menu
On Thu, 28 Apr 2011 21:09:18 -0700 Matthew Brush wrote: > I missed the the commit[1] before the previous one I mentioned, which is > a pretty cool feature if it does what I think it does. Is this > documented yet or is still a work in progress? Is it meant to let the > user reorganize/rename the menu items in the Set Filetypes menu? No, I should have been clearer. I edited the ChangeLog to read: Make filetype group *membership* configurable > I notice the default filetypes_extensions.conf has 'Typoscript' in > [Groups] which throws a warning on geany -v and that Genie and Scala Now removed, thanks. > show up under Compiled in the Set Filetypes Menu which is cool, but > there's still a 'Custom Filetypes' menu item that pops out an empty menu. I planned to remove that, which I've now done. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Set Filetypes Menu
> Is there a (scintilla) lexer for reStructuredText? With a quick look at > lexer names, I didn't see one. No, the ReST filetype does not have syntax highlighting. > > With that same quick look, I came across the lexer LexTxt2tags.cxx and > looked at that a little--it looks like some of the stuff there is (or > could be easily adaptable for my lexer for Foswiki / TWiki. What is > that lexer for--is there a markup language named Txt2tags? > > Oh, ok, I googled, yes there is, and I guess I'll spend a little time (a > few minutes) looking at that. (For Lex: it will save me from thinking > about lexing UTF-8, recursive descent parsers, switch / case > statements, and if / else chains ;-) Yes txt2tags and markdown are both lightweight markup languages, similar to wiki markup but of course annoyingly different in detail, just like wikis. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Set Filetypes Menu
On Friday 29 April 2011 12:26:35 am Lex Trotman wrote: > Hey Matthew, > > - I believe LaTex, Markdown, and reStructuredText are Markup > > Languages. Is there a (scintilla) lexer for reStructuredText? With a quick look at lexer names, I didn't see one. With that same quick look, I came across the lexer LexTxt2tags.cxx and looked at that a little--it looks like some of the stuff there is (or could be easily adaptable for my lexer for Foswiki / TWiki. What is that lexer for--is there a markup language named Txt2tags? Oh, ok, I googled, yes there is, and I guess I'll spend a little time (a few minutes) looking at that. (For Lex: it will save me from thinking about lexing UTF-8, recursive descent parsers, switch / case statements, and if / else chains ;-) > > - I don't know COBOL but I think it's a programming language isn't > > it? > > Well, it was in the 1970s, but I do remember someone asking about it > recently so it must be still used. Actually, it was also in the 1950s. Or, at least, the first specification was completed in December, 1959, and it is still used, a lot--there is a lot of legacy code out there. But not (used) by me! ;-) And, just for the record, no, I'm not that old. I'm actually the same age as Jack Benny. (Should I explain the joke / humor? Jack Benny was a comedian who, whenever he was asked his age, claimed to be 29.) Randy Kramer ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Plugins quality
Am 28.04.2011 09:47, schrieb Matthew Brush: > On 04/28/11 00:10, Frank Lanitz wrote: > >> However, I recognized tons of compiler warnings which did make me upset. >> I know, many of them might not be any dangerous but I really like to ask >> you to to have a look onto it and fix where possible/useful. > > My plugin's 'make check' output, unlike its source code, is clean. This wasn't onto some special plugin but whole plugins project in general. I don't see it as single task for a single maintainer, but as a common task for whole project to keep overall quality high inside all plugins. >> P.S. Well, I'm, not sure for how long make check didn't work, but based >> on commits I would say for a couple of weeks. Does actually anybody of >> you use this? > > I do, though I haven't actually worked on the Devhelp plugin in some time. > > BTW, for me the 'make check' fails with, not sure if it's supposed to > fail the build on these cases or not: > > make[3]: Entering directory > `/home/mbrush/Projects/Geany/geany-plugins/geany-plugins/pretty-printer/src' > > /usr/bin/cppcheck -q --template gcc --error-exitcode=2 . > ./PrettyPrinter.c:110: error: Common realloc mistake: "xmlPrettyPrinted" > nulled but not freed upon failure > ./PrettyPrinter.c:183: error: Common realloc mistake: "xmlPrettyPrinted" > nulled but not freed upon failure Did you use clean sources? Which is you system as on my Debian unstable with AMD64 there have been no issues Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
