Atom probably didn't use the ctags parser, it used
[this](https://github.com/julia-vscode/LanguageServer.jl) which is written in
Julia, so probably has access to the actual compiler smarts.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3341#issuecom
OK thanks for the clarification. I just seem to recall the Atom editor listing
all variables defined.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3341#issuecomment-1321008587
You are receiving this because you are subscribed to this thread.
Messag
@techee
> OK, I didn't think about this and yes, I can imagine it could get quite
> annoying (plus possibly slow) seeing calltips when writing your own __init__
> functions (I don't think invoking __init__() directly is common in Python).
`__init__()` needs to be manually called on super class
LGBcusoryI and CI passes, so I would say merge it (since CI is already broken,
it can't make it worse :-) and trigger all PRs to re-CI and see what happens.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1197#issuecomment-1320992799
You are rece
The Julia docs say "Currently, type declarations cannot be used in global
scope" [here](https://docs.julialang.org/en/v1/manual/types/#Type-Declarations)
So the ctags parser used by Geany is technically correct in not considering it
a declaration.
More generally languages with "assignment is de
If one creates a Julia file and writes some code into it, one would expect all
declared variables to be shown in the symbols list on the left. However, this
is not the case, for instance in this code here:
```
a::Int8 = 3
function f(x)
return 2x
end
```
the variable `a` is not shown in the s
I just went through the patch and it seems OK to me except the minor comment
above. (I'm not the right person to review anything related to
autoconf/automake but I'd say if it works, it's alright)
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/
@techee commented on this pull request.
> else
new_dir_path = g_build_filename(directory_ref, new_dir, NULL);
/* Build the new file list for completion */
completion_list = build_file_list(new_dir_path, new_dir);
gtk_entry_completion_set_model (completion, compl
>> Adding arguments to classes would make calltips look different for
>> user-written code and global tags which I think is confusing.
> Yes. I didn't even realize the difference but yes, other users might notice
> and be confused.
On the other hand we could change the calltip code to show the c
@elextr @techee @kugel- anyone for review? I guess we all agree that we want a
succeeding CI again :).
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1197#issuecomment-1320873119
You are receiving this because you are subscribed to this thread.
@eht16 commented on this pull request.
> + log "Signing Geany binary files"
+ for binary_file_pattern in ${GEANY_RELEASE_BINARY_PATTERNS[@]}; do
+ for binary_file in $(ls ${binary_file_pattern}); do
+ sign_file ${binary_file}
+ done
+
> > Hmm, this would add an **init** tag for each class in the generated tags
> > file only to satify this special logic for Python (and D).
>
> True, but this is how the command-line ctags works. And it also works this
> way for user-written code. So for
>
> ```
> MyClass(
> ```
>
> you get ca
12 matches
Mail list logo
