> but not so well documented, and requires some hacker skills.
Thats the idea of https://github.com/geany/www.geany.org/pull/40, any last
minute suggestions how to improve it are welcome.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3063#issuecomm
> we can't please all the people all the time
So the best way is to give the user convenient tools that allow to customize
the program to the maximum possible extent. With Geany, it's possible, but
not so well documented, and requires some hacker skills. :)
--
Reply to this email directly or
My 2 cents (remember I'm not a Windows user) is that we can't please all the
people all the time, especially with themes. If the techee-tweaked theme
solves the Adwaita bloat that is the actual OP, then lets merge it, most
importantly along with the wiki article about how to change it, and a li
> I'm close to give up on this.
Would be a shame.
> It's more like that @nrikonomov's comment kills our efforts to find a better
> solution for most users.
I'm not sure what exactly @nrikonomov meant, I thought that with the "project
killing" comment he meant the use of those "250,250,250 shad
@eht16 commented on this pull request.
> @@ -8,296 +7,368 @@
#
# This script should be run in the top source directory.
#
-# Parses all files given on command line for Python classes or functions and
write
-# them into data/tags/std.py.tags (internal tagmanager format).
+# Parses all files i
@eht16 commented on this pull request.
> # If called without command line arguments, a preset of common Python libs
> is used.
#
# WARNING
-# Be aware that running this script will actually *import* modules in the
specified directory
+# Be aware that running this script will actually *impor
@eht16 pushed 1 commit.
706ee56f0f0b2c09744c380b033b2ff44682a95e Fix doc typos
--
View it on GitHub:
https://github.com/geany/geany/pull/3039/files/d350dad27a45656cd9c84a0ac9dfb3a0412d6604..706ee56f0f0b2c09744c380b033b2ff44682a95e
You are receiving this because you are subscribed to this thread
> Is there a reason that Python tags are in ctags format and php tags in
> tagmanager?
Before #3039, Python tags were also in tagmanager format and so are the PHP
tags.
As said in https://github.com/geany/geany/pull/3488#issuecomment-1537369732, I
would switch the format to ctags for the PHP t
@eht16 commented on this pull request.
>
# write tags
script_dir = dirname(__file__)
tags_file_path = join(script_dir, '..', 'data', 'tags', 'std.php.tags')
-with open(tags_file_path, 'w') as tags_file:
+with open(tags_file_path, 'w', encoding='iso-8859-1') as tags_file:
@eht16 commented on this pull request.
> (arg_list, TA_ARGLIST),
(return_type, TA_VARTYPE),
(scope, TA_SCOPE)]:
if attr is not None:
-tag_line += '{type:c}{attr}'.
@eht16 pushed 1 commit.
721550ca76caa155dc3ea2c7e0edb4710ef6c7e9 Port create_php_tags to Python3 and
generate new PHP tags file
--
View it on GitHub:
https://github.com/geany/geany/pull/3488/files/36ccb38776e6c1439900b39c79b5a20a535c0969..721550ca76caa155dc3ea2c7e0edb4710ef6c7e9
You are receiv
I'm close to give up on this.
It's more like that @nrikonomov's comment kills our efforts to find a better
solution for most users.
Aprt from that, I completely with what @elextr said in
https://github.com/geany/geany/issues/3063#issuecomment-1539252949.
--
Reply to this email directly or view
The first commit roughly ports the `mkindex.py` to work with Python3 and
regenerate the broken `index.json` (it got broken in #57
0c0a8c28bcd3479e472f6125f3362c679cfc895b).
The broken `index.json` caused an error on the theme index page on the Geany
website (https://www.geany.org/download/theme
@ntrel pushed 1 commit.
067914790722ea0d99e4d072ba4c5bb8be8cfa18 D: parse template instance types with
parameter list
--
View it on GitHub:
https://github.com/geany/geany/pull/3479/files/d3fa78adb5747a9612261433a817a47566c1366e..067914790722ea0d99e4d072ba4c5bb8be8cfa18
You are receiving this b
> Maybe we have a different understanding of "signature", in my mind its the
> whole type, return (remember an override can be any covariant type, its not
> necessarily exactly the same as the `Iface::` declaration), qualifying
> scopes, name, and parameters, but IIUC you are using "signature" a
Maybe we have a different understanding of "signature", in my mind its the
whole type, return (remember an override can be any covariant type, its not
necessarily exactly the same as the `Iface::` declaration), qualifying scopes,
name, and parameters, but IIUC you are using "signature" above jus
Anyway, I would have to try and use it without the file and line and see if I
can adapt to it, so I can have a better idea of whether the file really is
useful or just a habit I have.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3475#issuecomment-154
> I would have thought they would be `bool Foo::maybedosomething(int n)` and
> `bool Bar::maybedosomething(int n)` not the same?
It wouldn't, that's what I wrote (emphasis mine):
> Having the signature is fairly irrelevant: it's gonna always be the same.
> **What's interesting is the symbol nam
Ahh, what is shown as the signature of the two implementations in in your
example, I don't have the PR applied?
I would have thought they would be `bool Foo::maybedosomething(int n)` and
`bool Bar::maybedosomething(int n)` not the same?
--
Reply to this email directly or view it on GitHub:
h
BTW, this is giving weird results when going to anything that doesn't have a
tooltip (e.g. anything that doesn't look like a callable), e.g. a type.
Especially weird when called on a class name, as it'll look something like
this, mixing names and nothing:
* `foo.hxx:42: `
* `foo.hxx:44: ns::Foo
@elextr it mostly does, but that's not my point. My point is that if you have
an "interface" implemented by several classes:
```C++
class Iface {
public:
virtual bool maybeDoSomething(int n) = 0;
};
class Foo : public Iface {
public:
virtual bool maybeDoSomething(int n) override { return n
> actually more often than the signature (as again, very often it's interface
> implementations rather than overloads, so the signature is the same
Well, goto declaration vs goto definition is supposed to separate the interface
from the implementation, but I havn't actually evaluated how well th
> Then Geany should not tell Scintilla to highlight local type names.
In general the majority of C++ types are in header files so they are not local
to my mind. But i'm not sure what you mean by local type names? And simply
removing semantic information from some names isn't really a helpful s
> I made https://github.com/geany/geany/pull/3495 to limit the width, does that
> help?
I'll give it a try, thanks
> Whats the point of showing file:line? The goto symbol will go to it, and if
> the user knows file:line they won't be using goto symbol, what is important
> is to be able to sele
> Scintilla semantic styling (keywords, types, and the rest) for names is global
Then Geany should not tell Scintilla to highlight local type names.
> final and override are only keywords in specific contexts
Seems like they aren't keywords in the Scintilla sense.
> if there tags are loaded lo
Whats the point of showing file:line? The goto symbol will go to it, and if
the user knows file:line they won't be using goto symbol, what is important is
to be able to select the correct version of the symbol to goto.
--
Reply to this email directly or view it on GitHub:
https://github.com/ge
> I got many cases where the popup now spans most of my screen width, making
> the thing a bit hard to use quickly.
I made #3495 to limit the width, does that help?
> Also, although useful, the signature is so big and prominent that the
> filename is almost buried and harder to find
With tha
Follow up to #3475.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3495
-- Commit Summary --
* Limit Go to Tag menu width to 80
-- File Changes --
M src/symbols.c (2)
-- Patch Links --
https://github.com/geany/geany/pull/3495.patch
> what was the reasons for you to abandon it?
Because looking for a signature is far more common for me than looking for file
and line.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3475#issuecomment-1542082357
You are receiving this because you are s
> I'll look a tad into modules out of curiosity one day, but does that mean
> that a kind of header equivalent is generated by the compiler, so that it can
> be installed and imported?
Presumably somewhere internal to compiler data files somewhere I guess ...
oooh, that google is good https://g
Help solve the annoyance of invisible autocompletion selection bar, which keeps
on coming up, usually after update geany related packages or else
Please guide to the thorough solving action
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3494
You are
> So if we set the filescope/local/whatever flag for `.cpp` files that will
> make the symbols exported with the module invisible elsewhere, but they
> should be visible.
Just looking quickly at https://en.cppreference.com/w/cpp/language/modules
suggests that there will be an `export` keyword,
> Just to flesh out how C++ modules impact this. […]
I'll look a tad into modules out of curiosity one day, but does that mean that
a kind of header equivalent is generated by the compiler, so that it can be
installed and imported?
--
Reply to this email directly or view it on GitHub:
https://
I've been running this (well, almost… see below :grin:) for a couple days and
it seems to work nicely
My "small" patch on top just because:
```diff
diff --git a/src/tagmanager/tm_ctags.c b/src/tagmanager/tm_ctags.c
index a5cb9531e..16e2ebf04 100644
--- a/src/tagmanager/tm_ctags.c
+++ b/src/tagman
Despite the heroic efforts of the Uctags crew and @techee and others there are
some limitations that Geany can't overcome when using assistance features in
C++.
Since its come up a few times in various issue/PR discussions I thought it
might be useful to summarise the fundamental limitations im
35 matches
Mail list logo
