Hi,
I'm sending my stack of patches against geany again, this time as individual patches. Here's the full list:
[PATCH 01/19] Prevent -Wmissing-prototypes report warning when compiling a plugin
[PATCH 02/19] Add signals for project options dialog opening and closing
[PATCH 03/19] Make the project menu accessible by plugins
[PATCH 04/19] Make it possible to change project patterns by plugins
[PATCH 05/19] Don't be annoying when not necessary
[PATCH 06/19] Make it possible for plugins to change the base directory of msgwindow
[PATCH 07/19] Open the file in the msgwindow even if no linenumber is specified
[PATCH 08/19] When closing tab, return to the document at the top of the MRU list
[PATCH 09/19] Use wider entry for project file path
[PATCH 10/19] New utils function to get relative path from one directory to another
[PATCH 11/19] File name in the project settings dialog shouldn't look it is editable
[PATCH 12/19] Use relative paths in the project files
[PATCH 13/19] Remove the "set" button from the project properties dialog
[PATCH 14/19] Rewrite tab switching queue
[PATCH 15/19] Do not insert --include= when the search pattern entry is empty
[PATCH 16/19] Use project patterns in the FIF dialog
[PATCH 17/19] Make the tab switching dialog a bit more useful
[PATCH 18/19] Use standard include paths for "open selected file"
[PATCH 19/19] Use per document indent sizes
Only some of them are required by gproject - others are just suggestions for improvements. I didn't explicitly distinguish between these two types of patches but it should be pretty clear from the description. There have been some minor changes since my last post - mainly the change of the FIF dialog to contain combo box for pattern selection and there are also some new patches - the detailed description is in the individual emails. Of course many of the patches are suggestions only so further discussion is welcome.
Cheers,
Jiri
On Thu, Sep 16, 2010 at 19:27, Thomas Martitz
<thomas.martitz(a)student.htw-berlin.de> wrote:
> On 16.09.2010 02:23, Lex Trotman wrote:
>>
>> Hi Jiri,
>>
>> I couldn't get this to work at all, it printed "calling indent this
>> line" all the time but didn't indent :-(
>>
>> I only had half an hour so I couldn't investigate much.
>>
>
> I have the same experience. Auto-indentation doesn't seem to work anymore
> (e.g. when hitting enter after on a line that ends with {, or when typing
> }).
I have just re-tested it again and it works on my machine (I have
forgotten one trace in the code - that's what you see in the console).
A quick question: have you read the commit log?
This patch makes it possible to specify several regex patterns for every
filetype which determine under what condition the indentation is performed.
The pattern variables are specified under the [settings] section of the
given filetype and their value is the regex to be used. The variables are
as follows:
* indent_this_line_regex - the match is performed after every keystroke
and if the regex matches, the indentation is performed on the current
line
* indent_next_line_regex - the match is performed only when enter is
pressed. The indentation is applied on the next line
* unindent_this_line_regex - like indent_this_line_regex but
unindents instead
* unindent_next_line_regex - like indent_next_line_regex but indents instead
Comments and strings are detected from the lexer so these can be ignored
inside the patterns. For instance these are very basic rules for GNU
indent style:
indent_next_line_regex=^.*\\{[[:blank:]]*$
unindent_this_line_regex=^[[:blank:]]*\\}$
indent_this_line_regex=^[[:blank:]]+\\{$
unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$
By commenting-out the last two lines you get ANSI indentation style.
If you replace \\{ and \\} with begin and end, respectively, you
get analogous rules for pascal. Notice the double-escaping of { and } -
the first escape sequence is for the keyfile ini format (so for the
regex itself \\ becomes \).
This means that in order to make it work e.g. for C, you have to edit
~/.config/geany/filedefs/filetypes.c
(or the corresponding file under /usr/local/share/geany) and add
indent_next_line_regex=^.*\\{[[:blank:]]*$
unindent_this_line_regex=^[[:blank:]]*\\}$
indent_this_line_regex=^[[:blank:]]+\\{$
unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$
under the [settings] section (+ restart geany). Please let me know if
it works (but also in the opposite case ;-).
Jiri
>
> Best regards.
> _______________________________________________
> Geany-devel mailing list
> Geany-devel(a)uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
Dear Geany devs,
Some time ago I received the attached patch though this list (from
Enrico?). I really love the added functionality to prevent duplicate
automatically added quotes and brackets.
Can this be added to Geany itself? Ideally this would be activated
with a checkbox in prefs > editor > completions.
-tnx!-
Harold
Hi,
I just tried running ./autogen.sh and got this:
checking for GIO... configure: error: Package requirements (gio-2.0)
were not met:
No package 'gio-2.0' found
...
make[1]: *** [config.status] Error 1
I think this may be due to build/treebrowser.m4 not disabling itself if
GIO is not found.
Nick
Hi all.
I attach three patches:
1. Keybindings to insert new line after/before current
2. Snippet keybindings support
3. Automatically insert additional indentation in XML/HTML files if
previous line ends with an opening tag
They must be unrelated and can be applied independently of each other.
Some of the patches have drawbacks. Before "polishing" them, I want to
know whether they are useful and may go to trunk.
The drawback of the first patch is that I doubt it's so useful. I know
Vi[m] provides shortcuts for these actions ('o' and 'O' in normal
mode), but their necessity is questionable for me. I implemented this
to ease XML editing with tag autocompletion turned on. Suppose you
need to write to consequent <li>'s. Without this patch you need to
press End+Enter after writing the first <li> to place the cursor where
you need to start the second. With my patch, you only need to press
one shortcut you can assign in Preferences > Keybindings :)
The drawback of the third patch is that it's not completed. If user
likes to leave HTML tags like <br> "unclosed", she would be disturbed by
automatic indentation caused by my patch, so a check box in Preferences
is desirable. I'll code it as soon as we decide this patch can go to
trunk.
Speaking about the second patch, here is an example of assigning a
keybinding (I currently use it in my user snippets.conf):
# special group to define keybindings
# keybindings' format resembles the one used in Preferences >
# Keybindings tab
[Keybindings]
block_cursor=<Alt>bracketleft
Keybindings may be assigned either in user or global snippets.conf (I'm
not sure if the latter is useful). Another decision I made is to allow
keybindings for snippets in [Special] section (like "block_cursor" used
above). While "block_cursor" snippet is not very useful when you have
to type its name, it is useful when you just have to press a shortcut.
And, as usual for me, all of these patches lack user documentation…
Best regards,
Eugene.
Dear devels
What would you think about implementing a 'narrowing' feature in Geany?
Currently, the functions that are longer than a screen are very hard
to track with simple scrolling. One thing that helps is matching
braces, but only to a degree. Even if you highlight the braces by
placing the cursor on one of the two, you may still need to start
searching for the end of the function, and you may still easily miss
it. (I think there is a binding that allows to go to the second brace
directly, but that's still not it.)
Another way to deal with this would be to add a 'narrowing' option.
I've first heard of this on the LyX list [1], with a reference to the
commercial EmEditor [2] (scroll to 'narrowing' to see some
screenshots). For example, Geany could narrow down---keep the needed
part in the usual background but grey-out all the rest---when placing
the mouse on braces. (Or, this could be provided as a c-menu item when
the cursor is on the bracing. Alternatively, the narrowing mode could
be activated after selecting several lines and clicking on a menu
item.) Whichever the implementation, this feature can be very helpful
to improve workflow and reduce the mental workload necessary to
inspect/edit specific parts of the code.
Do you think this would make sense for Geany? Regards
Liviu
[1] http://www.mail-archive.com/lyx-users@lists.lyx.org/msg80540.html
[2] http://www.emeditor.com/modules/feature1/rewrite/tc_35.html
--
Do you know how to read?
http://www.alienetworks.com/srtest.cfmhttp://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
On Wed, 27 Oct 2010 21:18:07 +0300
Dimitar Zhekov <dimitar.zhekov(a)gmail.com> wrote:
> 1. handle_integer_setting() uses gboolean *setting. It works, because
> gboolean is actually int, but I think that should be gint *.
Now fixed.
> 2. ui_editable_insert_text_callback() checks only the first character
> (assuming typing?), so you can, say, paste 1boza in Go to line.
I can't reproduce this using Go to Line.
> GeanyInsertNum contains a callback with full check, similar what is
> required +-number.
>
> 3. It would be nice to have the Document -> Indent Width -> #
> commands bindable to keys. Personally I don't use Ctrl+# for sending
> selection to custom commands...
I think it would be better to have a single keybinding that prompted
for the indent width rather than (re)assign those shortcuts.
Nick
Looks good, i like the idea of 'about:config'`s style.
Is it possible to change value?
And now about the requiring restart, i think that this problem can be soled simply if the variable name is prefixed for example with '*', I think that nobody change hidden preferences every 5 minutes ;)
Nice try Mitko, go ahead!!!
________________________________
I should have copy and pasted the truth.
-------- Оригинално писмо --------
От: Dimitar Zhekov dimitar.zhekov(a)gmail.com
Относно: Re: [Geany-devel] Unhide preferences
До: Geany development list
Изпратено на: Събота, 2010, Октомври 23 17:36:45 EEST
Hi,
This is a screenshot of the (not yet complete) Various tab.
The main function is:
void stash_setup_treeview(GPtrArray *group_array, gboolean variable,
GtkTreeView *tree, GtkLabel *label, GtkContainer *container);
group_array - obvious
variable - display/edit the groups marked as "variable" [write_once]
or all.
tree - obvious
label - if not NULL, displays the currently selected setting name.
container - if not NULL, when a setting is selected, an edit widget is
created, based on the setting type and inserted into container. If
NULL, there is no editing.
Currentry prefs.c calls stash_setup_treeview(pref_groups, TRUE,
widgets-obtained-from-the-Preferences-dialog). But we may call it with,
say, an array of plugins groups and FALSE. :)
Hunting the VTE/vc usage took me some time, I'll call it a day.
Unfortunately, vc requires some fixing.
--
E-gards: Jimmy
<BR/><BR/>-----------------------------------------------------------------<BR/>
<a href="http://a.abv.bg/www/delivery/ck.php?oaparams=2__bannerid=3784__zoneid=63__o…" target="_blank">
Вижте последните новини във Vesti.bg!</a>
I've found one more issue with Geany's "Safe file saving" option. When using g_file_set_contents(), file ownership and permissions are replaced with those for a new file. That fully conforms to GLib documentation (http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html#g-fil…), but is not good sometimes (e.g. editing an executable script file).
I propose to use GIO API (GFile) instead of g_file_set_contents; the patch is attached. This solution, however, raises some questions:
- It does work for my system (Ubuntu 9.10), but will it work for others, especially Windows? It seems that GIO is also available on Win32, but it requires some testing
- This cannot be named "Safe" file saving, as it does not create a backup first (we can call g_file_replace_contents with make_backup = TRUE, but it would not delete this backup file when the operation completes). Maybe there should be some other configuration option to use (or not to use) this setting? Or should I replace "unsafe" file saving with GIO functions instead of replacing "safe"?
Or even more - make this option work like in GEdit (which, I suppose, uses g_file_replace_contents for both cases, with make_backup=TRUE in "safe" case), adding the corresponding checkbox to preferences dialog?
What do you think?
Hi,
While working on unhide prefs, I noticed that different checks are
used to verify if the instance has VTE. In detail:
vte_info has a load_vte field, which corresponds to the "Load virtual
terminal support" setting in the preferences dialog. The most obvious
way to check for VTE, and also completely wrong: the preference can
be (un)checked at any time.
When the preferences are loaded on startup, load_vte is checked, and
if true, VteConfig *vc is allocated. So load_vte && vc != NULL seems
like a better check, but that ignores the -t (--no-terminal) option.
Also on startup, vte_info.have_vte = load_vte && !--no-terminal, and
in vte.c, have_vte = FALSE if VTE can not be loaded. So checking
have_vte is the right thing.
---
Following is a short list of load_vte and vc checks, and load_vte
usage (drop me a note if you need details):
build.c: prepare_run_script(), build_run_cmd(): checks load_vte && vc
run command in vte if one exists and "Execute programs in VTE" is set
Should be has_vte: one can't execute programs in VTE if -t...
keybindings.c: cb_func_select_action(): checks load_vte
on Ctrl+A and if VTE is focused do vte_select_all()
Should be has_vte. If instance is started without vte, and the dialog
preference is set, this crashes.
prefs.c: prefs_init_dialog(), on_prefs_button_clicked(): uses load_vte
set/get the "Load virtual terminal support" check button state - OK.
callbacks.c: on_send_selection_to_vte1_activate(): checks load_vte
handler for Edit -> Commands -> Send selection to terminal
Should be has_vte or no check. The command is removed on startup if
!load_vte, but crashes if -t is specified.
keyfile.c: save_dialog_prefs(): check load_vte && vc
meaning something like "save the preferences if loaded", but ignoring
the case when they can not be changed and so also require no saving.
keyfile.c: load_dialog_prefs(): read and check load_vte
allocate vc and read the other vte settings only if load_vte, but
ignoring -t (the option is local to main.c)
main.c: apply_settings(): checks load_vte
removes the Send selection to terminal command, but see callbacks.c
main.c: load_settings():
vte_info.have_vte = (no_vte) ? FALSE : vte_info.load_vte - OK.
---
What I plan to do:
1. Replace if (load_vte [&& vc != NULL]) with has_vte as needed.
2. Add some "use have_vte not load_vte to check for VTE" comment to
load_vte/have_vte.
3. Make the loading/saving of VTE settings unconditional. Avoiding
load/save economizes only a very short time, and the current checks
whether the settings should be load/saved are wrong anyway.
4. Make vc non-pointer? This way, it'll be clear that vc != NULL is
not a valid check. OTOH, vc-> crashes if vc is not allocated, which
is good, but the current allocation condition is wrong.
That would be about 140 "s/vc->/vc./" changes.
Request for comments.
--
E-gards: Jimmy