> success = document_save_file_as(doc, utf8_filename);
>
> + if (orig_file_name)
> + {
> + if (success)
> + {
> + gchar *orig_file_name_locale =
> utils_get_locale_from_utf8(orig_file_name);
> +
> + if
>
> g_return_val_if_fail(!EMPTY(utf8_filename), FALSE);
>
> if (doc->file_name != NULL)
> {
> - if (rename_file)
> - {
> - document_rename_file(doc, utf8_filename);
> - }
> + if (remove_orig_file &&
Oh shoot, this doesn't produce the same result as the current implementation.
I completely forgot about metadata, with this implementation all files given
new names are new files, so they have new file metadata. Owner and permissions
may change, but specifically the execute bit won't be
Yeah, probably the tooltip.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1190#issuecomment-241946055
If there's important details the user must know about the implementation, we
could add them to the manual, or even if really important, to the button's
tooltip.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I don't understand.
I mean if the "Rename" button in the "Save As" dialog still results in the
current document contents being written to the new filen and the old file no
longer existing, it should be left "Rename". If it produces a different outcome
in the success case, then there should be
> 1) it no longer renames, thats stupid, please read my #1180 rant for why.
If it no longer performs a rename (that is, gives a file a new name), then a
whole new feature should be added, the rename feature is extremely useful and
shouldn't be dropped.
--
You are receiving this because you
1) it no longer renames, thats stupid, please read my #1180 rant for why.
2) since the implementation is different, it seems reasonable that the label
needs to be different, so the change is needed. Given the translation "churn"
we do without thought, I doubt this will matter. And I don't see
I have not reviewed the internal semantic change yet and don't much care, as
long as it still lets me give my files a new name (and never leaves me without
old or new file on disk on error), but I don't like the change to 'Save and
Remove Original' for a number of reasons: 1) it obfuscates what
> success = document_save_file_as(doc, utf8_filename);
>
> + if (orig_file_name)
> + {
> + if (success)
> + {
> + gchar *orig_file_name_locale =
> utils_get_locale_from_utf8(orig_file_name);
> +
> + if
>
> g_return_val_if_fail(!EMPTY(utf8_filename), FALSE);
>
> if (doc->file_name != NULL)
> {
> - if (rename_file)
> - {
> - document_rename_file(doc, utf8_filename);
> - }
> + if (remove_orig_file &&
Oh, ok, well, GP-473 isn't in 1.28, so it will be 1.29 (targeted at Nov 12)
plus @hyperair release delays.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1151#issuecomment-241932535
As discussed in https://github.com/geany/geany/pull/1180.
This mechanism is more consistent in the context of "Saving", and is easier to
understand with respect to how it works, so I hope it gets adopted.
You can view, comment on, or merge this pull request online at:
> + GPtrArray *ret;
> +
> + sort_options.sort_attrs = NULL;
> + /* tags_array isn not needed by tm_tag_compare(), but for
> tm_search_cmp() */
> + sort_options.tags_array = NULL;
> + sort_options.first = TRUE;
> +
> + foreach_ptr_array(s, i, q->names)
> + {
> +
@kugel- pushed 2 commits.
75ef096 tagmanager: refactoring tm_query
2805e1f tagmanager: tm_query: allow prefix matching for scope as well
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@konsolebox pushed 1 commit.
837eb0c Use stock icon
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/geany/geany/pull/1163/files/cf9c0e657f84dbe421a8d624e240fcd942b1e0ab..837eb0ce657161780be6494c9b7cc9c2ff148727
> + GPtrArray *ret;
> +
> + sort_options.sort_attrs = NULL;
> + /* tags_array isn not needed by tm_tag_compare(), but for
> tm_search_cmp() */
> + sort_options.tags_array = NULL;
> + sort_options.first = TRUE;
> +
> + foreach_ptr_array(s, i, q->names)
> + {
> +
Closed #850.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/850#event-764880086
@codebrainz Thanks, that's the functionality I was referring to when I opened
this -- I am going to close this now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1189.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1189#event-764642618
@b4n pushed 2 commits.
cd5c383 Don't dedup tags used for calltips in order to support overloading
342e636 Make sure to sort get_tags_for_current_scope() result
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Oh, havn't even looked at #1188 yet.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1177#issuecomment-241714817
Oh, okay, sorry, I assumed you were trying #1188 which does add it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1177#issuecomment-241714339
Nope, not in current Geany, still both. Or is it some extra magic you added in
the patch as well as making scope completion apply to calltips?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I mean rename `Foo` to `FooImSureThereIsOnlyOne` and it'll work.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1177#issuecomment-241713315
> it looked like you are relying on autocomplete's algorithm by cunningly
> renaming it
what does this mean?
Anyway, your example works for me *if there is only one `Foo` in the
workspace*. I'm not very sure why I might pick up the wrong `Foo` if there are
more even though I pass
Ctrl+L focuses the *Go to line* entry in the toolbar if it's visible
instead of opening the extra dialog.
Doesn't it do this for you?
If you wanna force opening the dialog, you can remove the *Go to line* entry
from the toolbar (in the preferences under *Interface → Toolbar*).
--
You are
> + match = tag->type & q->type;
> +
> + /* Remove tag from the results. tags are unowned so removing is
> easy */
> + if (!match)
> + g_queue_unlink(, node);
> + }
> +
> + /* Convert GQueue to GPtrArray for sort, dedup and
> + GPtrArray *ret;
> +
> + sort_options.sort_attrs = NULL;
> + /* tags_array isn not needed by tm_tag_compare(), but for
> tm_search_cmp() */
> + sort_options.tags_array = NULL;
> + sort_options.first = TRUE;
> +
> + foreach_ptr_array(s, i, q->names)
> + {
> +
Hi,
I am running Geany 1.27 with GTK 2.24.30, GLib 2.48.1 on Ubuntu Gnome 16.04.
When I try to go to a specific line with CTRL+L, that does not work ! I have to
use the Menu "_Search => Go to Line..._" ... which is a real pain !
If anyone has a clue, how to solve this problem, I will be
Am 23.08.2016 um 09:27 schrieb Jiří Techet:
>
> Another goal is to eventually use this in the existing tag search/query
> functions.
>
> For C this new API is more or less useless because the filtering can easily
> be done by directly looking at the tag values and IMO it's more explicit and
> Well… I don't quite love the proposed query API, but well, I don't know. But
> it's not too crazy -- well, not more than a DB API would be crazy at least.
>
> But maybe you could show real use cases of why this kind of API is good and
> fits everyone?
Below is the python code of that I can
One more vote for seeing uses of this. I'm a little worried about adding more
API before anyone actually uses it (especially API like this which is just a
facade for what is already accessible). I understand the performance problem
but the question is how many people will want to create python
> + match = tag->type & q->type;
> +
> + /* Remove tag from the results. tags are unowned so removing is
> easy */
> + if (!match)
> + g_queue_unlink(, node);
> + }
> +
> + /* Convert GQueue to GPtrArray for sort, dedup and
> +
> + if (match && q->type >= 0)
> + match = tag->type & q->type;
> +
> + /* Remove tag from the results. tags are unowned so removing is
> easy */
> + if (!match)
> + g_queue_unlink(, node);
> + }
> +
> + /*
> + {
> + tags = tm_tags_find(q->workspace->tags_array, s->str,
> s->len, );
> + foreach_c_array(ptag, tags, ntags)
> + g_queue_insert_sorted(, *ptag,
> tag_compare_ptr, _options);
> + }
> + }
> +
> +
> + GPtrArray *ret;
> +
> + sort_options.sort_attrs = NULL;
> + /* tags_array isn not needed by tm_tag_compare(), but for
> tm_search_cmp() */
> + sort_options.tags_array = NULL;
> + sort_options.first = TRUE;
> +
> + foreach_ptr_array(s, i, q->names)
> + {
> +
> +gint tm_query_add_lang(TMQuery *q, TMParserType lang)
> +{
> + g_array_append_val(q->langs, lang);
> +
> + return 0;
> +}
> +
> +
> +/** Set the tag type filter of a query.
> + *
> + * The query results will be restricted to tags match any of the given types.
> + * You can only set this
> + */
> +GEANY_API_SYMBOL
> +TMQuery *tm_query_new(const TMWorkspace *workspace, gint data_sources)
> +{
> + TMQuery *q = g_slice_new(TMQuery);
> +
> + q->workspace = workspace;
> + q->data_sources = data_sources;
> + q->names = g_ptr_array_new();
> + q->langs =
39 matches
Mail list logo
