Hi!
I saw this code in src/symbols.c at line 1917:
while (sci_get_style_at(sci, start) != fn_style
&& start < max_pos) start++;
If start >= max_pos then sci_get_style_at will be called (with out of
bounds value?) and then the loop will bail out.
I suggest that the condition is reordered as:
while (start < max_pos
&& sci_get_style_at(sci, start) != fn_style)
start++;
Then sci_get_style_at will only be called if start is less than max_pos.
It is just my humble suggestion.
Best regards,
Daniel
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
Hi folks,
I saw that the SM-branch is merged with trunk on a regular basis, but
not sure what's the current status of that branch. Can someone help me
out there?
Cheers,
Frank
--
http://frank.uvena.de/en/
Hi,
As you may have noticed, when cursor is in the "virtual space" (beyond
eoln), our status bar always shows the last "real" column. This small
patch adds a new %v (and %V) format specification, which displays a
"virtual" column number, as if the line extends to the cursor position.
I haven't included sci_get_cursor_virtual_space() is the plugin
interface for now.
Since the virtual position normally requires 3 SSM()-s, and is less
likely to be used than the line and column, I placed the calls into
add_statusbar_statistics() instead of ui_update_statusbar().
--
E-gards: Jimmy
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
>
@Matthew: That sounds like a good idea (after the release)
@Lex: That makes sense. After this weekend I'll still have time, but
it'll be more sparse. I'd like to be a part of it; so let me know what
we/I need to do to get this going. Thanks!
Josh
Hi plugin maintainer of geany-plugins,
As 0.21 is near I like to ask you to update your documentation for your
plugin. Some of them are pretty out of date and not very useful to the
user.
Please check that they include the latest information as e.g. authors
mail addresses, web pages, features, know issues, bug tracker links
etc..... But also make sure the user is understanding how the plugin
works and how he can make usage of it.
Thanks in advance,
Frank
P.S. I'm honestly personally thinking about to don't include a plugin
which is not having a minimum of good documentation to upcoming
releases...
--
http://frank.uvena.de/en/
Hi,
I was messing around with Geany code to see what it would take to
compile it against GTK+ 3 (just for fun). There doesn't seem to be too
many changes needed, with one *massive* exception: the old code
generated by old glade versions.
At some point in the (possibly distant) future, Geany will (I think)
either need to switch to using GtkBuilder or just hack-by-hand the
`interface.c` file (eww), since the old Glade version generates what
will be deprecated code, and newer Glade versions don't generate code.
Has anyone thought about what would be needed to switch from using the
current generated C UI code to using GtkBuilder? You can actually open
the old Glade file in Glade3 and resave it as GtkBuilder XML (with minor
issues), but it seems like there would need to be a whole lot of work to
actually use it.
At a glance, it seems like most widgets are accessed through
`ui_lookup_widget()`, so it seems like it would make sense to have that
function somehow call `gtk_builder_get_object()` to find the widget. If
all the Glade widgets are lookup up through this single function, that
will probably work to our advantage. I'm not sure how else widgets are
accessed, or how many are added outside of the `interface.c` file (vte?)
or if that matters.
It seems like the callbacks should get connected when
`gtk_builder_connect_signals()` is called since they seem to stick
around fine in the GtkBuilder XML file. I guess this part might not be
too much problem.
I was hoping to start gathering some ideas on the best way to make this
transition, even though it may be far off in the future. It seems to me
like it will require quite extensive changes, potentially producing tons
of non-obvious bugs popping up in obscure corners of the code.
Maybe I'm over-estimating the scope of the change. Is there some
silver-bullet approach that will make this trivial?
Cheers,
Matthew Brush
Hi,
0. Not having the Lex imagination, and not wanting to integrate a Real
Parser into Geany and push it onto the users, I ended up with a pretty
simple universal parsing proposition - mostly a combination of what
we already have.
1. A message is parsed using:
regex: Extended syntax regular expression with subexpressions.
line_idx: 1-based index of the line number subexpression. If zero,
Geany will read the first two (or three, if there is a third) matches,
and check whether the first or second match is purely digits. If so,
it'll try to use the matches as <line> [column] <filename>, or as
<filename> <line> [column].
If line_idx is non-zero, the matching text must start with a number,
and the following additional 1-based subexpression indexes may be
specified:
file_idx - File name index. If 0 (not recommended), the current editor
file name will be used. If non-zero, the matching text must be
non-empty.
column_idx - Column # index, 0 = none. Ignored if the matching text
does not start with a number.
warn_idx (error_regex only) - Warning index, 0 = none. If the matching
text is not empty, the parsed message will be considered a warning
rather that an error.
2. Some examples:
"^([:]+):([0-9]+): "
file_idx=1, line_idx=2
the standard grep-line syntax
"libtool *--mode=link| from ([:]+):([0-9]+)[,:]([0-9]+[,:])?$" \
"|^([:]+):([0-9]+):([0-9]+:)? (warning: )?"
file_idx=1, line_idx=2, col_idx=3, warn_idx=4 :)
gcc/g++ syntax, ignoring libtool --mode=link (see msgwindow.c)
3. Recommendations for writing regular expressions:
The default file_idx is 0, so if you specity line_idx > 0, be sure to
set file_idx > 0 too (unless the message does not contain a filename).
For more precise parsing, try to match the start or end of line, or
some unambigous text.
Exclude the delimiter following an subexpression: "[^:]+:" instead of
".+:" (note that Geany assumes colon-less document names).
4. Rationalle for an explicitly specified line/column # to start with
a number instead being purely digits:
You can always specify a purely-digit subexpression.
For some messages, it may be easier to define the line and column
including some trailing text in the subexpression.
5. Initial implementation:
The buildin parsing will match the current behaviour, with some
small improvements.
The list model should either be removed and left to filename-line-
[column] parsing, or used to store the parsing results. Personally I
prefer the former. Combining the parts into a string and parsing them
back seems a bit awkward, but such things happen in programming.
6. Possible extensions:
More than one user-defined regex and set of indexes: error_regex_1,
line_idx_1 etc.
When building, attempt all default expressions, and check if the
filename matches the well-known extensions for this expression. For
the 1st line in a build output, the current-file-type-expression is
tried first. For the next lines, the last successful (best-matching)
expression is tried first.
copy_idx - Index of the text to be copied on right-click Copy, 0 if
none. If the matching text is empty, the entire line will be copied.
Allow the plugins to define their own expressions for the messages
tab (which will make the list model obsolete).
RFC.
--
E-gards: Jimmy
Hi plugin maintainer,
A couple of month ago we discussed about adding more code quality to
the plugins. During this discussion we added the make check target to
autotools build environment for geany-plugins project to get a more
pedantic compiler, preventing segfaults, memory leaks and other
unwanted behavior.
However, a long time passed by since we did the discussion and I'm not
very happy about the progress we made. Still a lot of plugins do have a
huge number of compiler warnings in special on AMD64 architecture. So
I'm asking you with having 0.21 in view to fix as many as possible
compiler warnings and errors at your plugins to ensure to have the
users a good release working with. Maybe you can also install check and
cppcheck for some static code analysis.
Cheers,
Frank
--
http://frank.uvena.de/en/