Devel November 2011

devel@lists.geany.org

21 participants
40 discussions

Fwd: Re: [Geany] A read-only command line option
by Thomas Martitz 07 Nov '11

07 Nov '11

I figured this should probably moved to geany-devel. Best regards. -------- Original-Nachricht -------- Betreff: Re: [Geany] A read-only command line option Datum: Thu, 03 Nov 2011 22:42:42 +0100 Von: Thomas Martitz <thomas.martitz(a)student.htw-berlin.de> Antwort an: Geany general discussion list <geany(a)uvena.de> An: geany(a)uvena.de Am 06.03.2010 12:15, schrieb LUK ShunTim: > Enrico Tröger wrote: >> On Thu, 4 Mar 2010 12:47:35 +1100, Lex wrote: >> >> Hi, >> >>> I'd suggest the simplest solutions, >>> >>> --readonly applies to all files on the command line irrespective of >>> positioning and has no effect on any other files opened by session or >>> menu. This answers 1,2,3,4 (Note POSIX says it must be before any >>> files but GNU allows anywhere) >>> >>> Current behaviour on attempting to re-open a file with different >>> read-only status is that nothing happens, the already open file is >>> raised but not changed. I would leave this as is irrespective of >>> method of second opening (cli or menu) >>> This answers 5,6. >> I complete second this suggestion, not only because it would be simple >> to implement but also because it is simple to understand and so use. >> >> If there are no major objections, I'll implement this in the near >> future (whatever this means in terms of my limited spare time). Of >> course, if anyone is faster than me and posts a patch, that'd be much >> appreciated :). >> >> >> Regards, >> Enrico > It'd be a nice-to-have, convenient enhancement. No hurry. Please take > your time. > As I need it myself now, I implemented it. It was indeed relatively easy to do. I've done it in the exact way as Lex suggested. You can find the according pull request here: https://github.com/geany/geany/pull/11 Please feel free to comment, I hope I did it correctly. It seems to work fine for me. I didn't update the manual because I don't know how to do it. On a related note: IMO the behavor of 5/6 should be changed in a separate patch. Especially if you open from the command line, but also with the file browser, you may get unwanted behavior (even data loss in the extreme case) if you opened a file in read-only mode but it didn't do it because it was already opened (I would switch to readonly for non-readonly files, but not the other way around, i.e. play safe). Best regards. _______________________________________________ Geany mailing list Geany(a)uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany

1 0

Geany Plugins testing repository
by Jiří Techet 05 Nov '11

05 Nov '11

Hi, I've created a repository for testing geany-plugins conversion from svn to git here: https://github.com/techee/geany-plugins After consultation with Frank, it converts only the combined geany-plugins repository, not the individual plugins so the history starts 11.6.2009. This is the command I used: svn2git https://geany-plugins.svn.sourceforge.net/svnroot/geany-plugins --trunk trunk/geany-plugins --tags tags/geany-plugins --branches branches/geany-plugins -m --authors ./authors.txt The rest of conversion was very similar to Geany's conversion so there's not much more to describe. Please have a good look at it and let me know if something needs to be changed. Especially please check if all the committer info is correct. There's already one suggestion from Frank to drop commit 12dcf0 - i'll do it during the final conversion. Cheers, Jiri

3 3

Geany Plugins SVN Commit URLs
by Matthew Brush 05 Nov '11

05 Nov '11

Hi, I haven't heard too much about the Git conversion of Geany Plugins, but I wanted to offer a suggestion that might improve the commit messages compared to Geany's. In the Geany's Git repository there's links back to the SVN repository in the commit messages (the links are broken BTW). I was wondering if it would be better to have these links point to a place we have more control over, for example using a Geany commit, instead of this in the commit message: git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5970 ea778897-0a13-0410-b9d1-a72fbfd435f5 We could have something like this: git-svn-id: [ea778897-0a13-0410-b9d1-a72fbfd435f5](http://svn.geany.org/svnroot/geany/tr… That way we could make the links work and be able to move the old SVN repository without breaking all the links in the commit message. I guess we'd need a little redirect script or something on geany.org. Note also the use of Markdown link syntax, which might render better on Github (not sure). I guess it's too late to do this for Geany's Git repository, but we could maybe consider something like this for Geany Plugins if the software can support it? Just an idea. Cheers, Matthew Brush

6 15

sm-branch repository
by Lex Trotman 04 Nov '11

04 Nov '11

Hi Jiri, Your sm-branch repository referenced here http://article.gmane.org/gmane.editors.geany.devel/5576/match=sm+branch does not seem to contain any sm code? Cheers Lex

2 2

Geany problems with unknown encodings names
by Lex Trotman 04 Nov '11

04 Nov '11

Dear Encoding specialist (or Colomban by default :) The thread [1] has exposed a problem with the way Geany handles encodings that it gets from the extraction regexes and from the locale. The reference thread shows that Geany gets an encoding CP1252 from the locale, this is fine for reading the file since iconv and therefore g_convert recognises it and loads it fine. Places where Geany just uses the string such as the status bar also work fine. But Geany does not recognise CP1252 (Geany only knows WINDOWS-1252) so places that use the encoding index default to UTF-8. So Geany saves the encoding in the session file as UTF-8 which is incorrect. The document->set encoding menu also defaults to UTF-8 because it uses the index to select the option. Geany could fix the sessions by just saving the encoding name not an index, but the menu is a problem and may need an "unknown (no change)" option. Or Geany could refuse to use encodings that it doesn't recognise, but that is somewhat restrictive :( And I don't know what other parts of Geany may also be affected. Any other ideas? Cheers Lex [1] http://article.gmane.org/gmane.editors.geany.general/6285

3 4

Mapping from Scintilla to Geany filetypes
by Lex Trotman 04 Nov '11

04 Nov '11

Hi All, Prompted by ML discussions that showed that Geany's Tcl styles didn't match Scintilla's, I checked scintilla.iface against highlighting.c. The following are where I *think* there are mismatches. Mostly they are things added in newer scintillas which don't have an equivalent in Geany. Someone who understands these languages should check and fix highlighting.c and the filetypes files appropriately for the language. D language, Scintilla has added SCE_D_WORD[67] TCL has added SCE_TCL_WORD[678], SCE_TCL_COMMENT_BOX and SCE_TCL_BLOCK_COMMENT ASP Javascript has added SCE_HJA_REGEX Ruby sets the style for SCE_DATASECTION twice? Lisp has added SCE_LISP_KEYWORD_KW and SCE_LISP_MULTI_COMMENT Asm has added SCE_ASM_COMMENTDIRECTIVE Caml has added SCE_CAML_KEYWORD3 and SCE_CAML_WHITE Sql has added SCE_SQL_USER[1234], SCE_SQL_COMMENTDOCKEYWORDERROR, SCE_SQL_COMMENTDOCKEYWORD and SCE_SQL_COMMENTLINEDOC Cheers Lex

1 0

Make document_save_file() show the Save As dialog when necessary
by Nick Treleaven 04 Nov '11

04 Nov '11

Hi all, I've just made a commit which changes plugin API behaviour, which I think is necessary. Please see the full log message below for justification. It's possible plugins may need updating, but after a quick grep it seems perhaps only the core Save Actions plugin. For auto-saving it may want to ignore documents without an absolute path to avoid showing the Save As dialog. I'll make this change next. Note that file templates and other features (geanyVC?) create documents with a filename but no path, hence this change. Remembering to show the Save As dialog in all code for the same reason was not reliable enough. That code can now be removed, but won't cause users any problems if left. On 02/11/2011 15:27, Nick Treleaven wrote: > Branch: refs/heads/master > Home: https://github.com/geany/geany > > Commit: de559ef5d4150e2485ef3ffb865e9c9d3249bcd8 > https://github.com/geany/geany/commit/de559ef5d4150e2485ef3ffb865e9c9d3249b… > Author: Nick Treleaven<nick.treleaven(a)btinternet.com> > Date: 2011-11-02 (Wed, 02 Nov 2011) > > Changed paths: > M src/build.c > M src/callbacks.c > M src/dialogs.c > M src/document.c > > Log Message: > ----------- > Make document_save_file() show the Save As dialog when necessary > > Previously an error message was shown if doc->file_name is NULL. > > The Save As dialog is now shown if the document does not have an > absolute path. This is because the user should confirm where to save > the document in this case. > > Although this changes plugin API behaviour, it seems the best way to > ensure the Save As dialog is always shown when needed so the user > knows where the document has been saved.

2 4

[RFC] Geany Plugin Names
by Matthew Brush 03 Nov '11

03 Nov '11

Hi all, Is anybody opposed to removing the "geany" and "Geany" prefix from the plugins in Geany-Plugins. I mean at least for the directory name in the source tree, README/Site, and PLUGIN_SET_INFO() name? It's always bothered me when I go into *Geany's* plugin manager and see plugin names like "GeanyFooBar". Obviously the plugin is for Geany and the "Geany" prefix makes the plugin not ordered correctly. Same goes for the SVN/Git repository source tree directory names. For example: Geany-Zencoding plugin could be "Zencoding" under the directory in the repo called "zencoding". This is like many plugins already, for example: addons, codenav, debugger, devhelp, gproject (sorta :), pretty-printer, shiftcolumn, spellcheck, tableconvert, treebrowser, updatechecker, webhelper, and xmlsnippets. IMO these would be reasonable renames for the others: Old Name Plugin Info Name Directory ======== ================ ========= GeanyDoc Documentation?[1] doc or geanydoc GeanyExtrasel Extra Selections extrasel Geanygdb GNU Debugger[2] gdb GeanyGenDoc Documentation Generator gendoc GeanyInsertNum Insert Numbers[3] insertnum GeanyLatex LaTeX (Addons) latex GeanyLipsum Lorem Ipsum Generator lipsum GeanyLua Lua Plugins lua GeanyMacro Macro Recorder macro GeanyNumberedBookmarks Numbered Bookmarks numberedbookmarks GeanyPg Privacy Guard pg or gpg GeanyPrj Project Manager?[4] prj or project GeanySendMail Send Mail sendmail GeanyVC Version Control vc or vcs --[coming soon]--------------------------------------------------- GeanyMultiTerm Multi-Tabbed Terminal multiterm GeanyPy Python Plugins python GeanyZencoding Zen Coding zencoding ================================================================== [1] Could we merge Devhelp and GeanyDoc? [2] Could we replace in favour of Debugger? [3] Should this go in Addons? [4] Could we merge GProject and GeanyPrj or are totally different? ================================================================== Anyway, just a thought to make things more consistent and less redundant. It seems like while converting and moving to Git would be an ideal time to do this. Feel free to +1, -1, comment or ignore. Cheers, Matthew Brush

12 30

Newsletter: Issue 4 to be released soon
by Frank Lanitz 02 Nov '11

02 Nov '11

Hi folks, Again about two month passed by and a new issue of the newsletter is right on the way to get reach finish line. I'm targeting upcoming weekend or early next week for release. Well, if you like to add something, a couple of days are still left to send us your content for the newsletter. Feel free to check out https://github.com/geany/newsletter for current status of work and give some feedback. Cheers, Frank -- http://frank.uvena.de/en/

1 0

Geany-Plugins 0.21.1 released
by Frank Lanitz 01 Nov '11

01 Nov '11

Hi all, Due a little issue with source tarball of 0.21-release of Geany-Plugins 0.21.1 has been released which fixes an issue of non working waf-build system from inside the source tarball. As usual, tarballs and their corresponding GPG signatures can be found at <http://plugins.geany.org/downloads.html>. The Windows installer has not been directly effected by this issue so renewing is not needed. Cheers, Frank -- http://frank.uvena.de/en/

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel November 2011