It would be nice to have an option to only index files listed in the "external directory" that have an #include<...> directive. This would reduce the amount of indexed files to only index files used in context.
--
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-plugins/issues/900
I am currently testing geany a lot, which explains the various issues
created.
Anyway, this time I have a bug report; or, rather than a bug per se, perhaps
a strange behaviour feature instead.
I will try to explain what I did:
- I was trying to search for a specific word/substring in a somewhat
large file (~10.000 lines or so).
- I was clicking on the expander in that search widget, for "Find All"
too.
- There, I was clicking on "In Document". (If you want to see it,
just click on the part that expands that widget downwards.)
Next result was that suddenly the bottom pane flapped upwards
and occupied like 60% of the space. With bottom pane I mean
the notebook-like thing that has the entries such as "Status",
"Compiler", "Messages", "Scribble", "Tasks".
The content in that first tab (Status) showed:
No matches found for "abhn".
(That was the sub-word I was trying to find.)
Alternatively it will show the result of the match when it found
something, which is useful.
Anyway, the bottom pane unfortunately does not have a simple way
for me to move it downwards, so 60% is now occupied with this
status/compiler/messages/scribble/tasks widget and I can not resize
it.
I restarted geany, and that bottom pane did not show up, so I assume
that it can only be triggered (or at the least one way to trigger)
through that search-functionality.
I am not against the functionality as such, but here are two things
or three that I think are not ideal; or could be changed.
1) First, it would be great if we could resize that widget. I was
trying to find an up-and-down arrow appearing but I could not find
one. No clue why. Perhaps my gtk-version is broken, but either way
an up-and-down arrow to resize this would help.
2) Second, and perhaps more importantly ... I did not have any bottom
bane widget at all (actually I was even trying to find vte yesterday,
but I guess I don't have vte installed or geany can not find it, so
I was confused when a bottom pane suddenly showed up altogether).
To me this is by far the most surprising part. Consider that I am
working mostly full screen in a text file. Now I am trying to
search something and I have this cute small search widget. Then
I hit "Document" and BAM, suddenly this strange bottom pane flaps
open to like 60% ... this was unexpected to me. I don't really
dislike it (only that I can not resize it) but it is unexpected
and perhaps not intuitive. First, I would like to suggest to
perhaps make it a bit smaller, right now it really occupies about
the bottom 60%; may be better to occupy only 40% or less by
default. But more importantly, I actually don't think this should
appear at all. IMO it may be better if the search widget itself
could show or indicate whether something has been found or not.
(I have not looked at the code but I assume that it shows up
in "Status" may be indicative that it is somehow registered
there first, and then geany or gtk may assume that the user wants
to see this; which is an ok assumption per se, but it does not
make a whole lot of sense to me when we were already using only
the search-widget).
3) This one probably requires more changes; the whole search
widget interface redesigning. But I don't want to suggest any
big work either. I only find the search widget/interface a
bit confusing. Perhaps this could be a separate issue, like
asking several users of geany how they use it, what they don't
use, what they use a lot, and then eventually make some changes
in the future. The options are fine, in principle, but the
defaults seem a bit strange. For example, right now when I
want to continue to search, I have to select the "Find"
button; the "Cancel" button is the default focus, so when I
hit enter, rather than searching again, that sub-widget
is closed. That confuses me too; was different in my old editor.
I can see people want to prefer cancel, but it may be better
to be able to allow users to tweak it. Or to actually make
an "In Document" search also part of the top-options, rather
the expanded ones, without showing up the status at all. I
usually need to search the whole document so the search
interface is a bit sub-optimal for me right now.
--
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/2148
When overview plugin is enabled, some hotkeys (if not all) like Ctrl+Z (undo) stop to work. Appears both with gtk2 and gtk3 (checked gtk3 before 1.32 and gtk2 with 1.33).
While searching for such bug, before to report, i found thread about split-window pane, not reacting to all keys/events/etc. Found reason is that most of geany code is written with assumption of having only one pane. Just guess, that these two bugs could have same reason.
--
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-plugins/issues/730
How to reproduce:
`i=0 ; while [ "$i" -lt "60000" ] ; do echo '[20-01-2019 JUST TEXT. JUST TEXT. JUST TEXT. JUST TEXT. JUST TEXT. JUST TEXT. JUST TEXT. JUST TEXT.' >> testfile.txt ; i=$((i+1)) ; done`
Next open testfile.txt
CTRL+H and replace [20-01-2019 with [21-01-2019 in whole document.
Now replace [21-01-2019 with [22-01-2019
It will freeze for a long time and load one cpu core for 100%. no ram or io load.
I set it for a night and it replaced all.
--
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/2092
I have a large Java file (4.8MB). If I insert a new <b><big>{</big></b> near the start of this file, the run time for the parser becomes very long (5 minutes or so) - while the parser is running the editor is unusable. Is there some way to prevent this from happening? By parser I mean the code that determines the coloration of the keywords, strings, etc. <b>Thanks!</b>
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/791
So I tried to just get the regex parser compile and run but it turned out that it requires so many changes in ctags itself that it's just impossible to perform without the complete ctags sync. So the first patch is a huge blob which gets all the upstream changes (no way to get this more granular) on top of which I applied the Geany-related changes. Regex parsers using GNU regex work, at least on linux (not sure about Windows - someone has to get it compile there if it doesn't work).
This was hell a lot of work and something I don't want to do in the future in this form. So in the subsequent patches I tried to minimize Geany-related diffs to the absolute minimum, even if it meant adding and compiling more uctags code (which we'll never actually use). I'd say the result is quite nice, the diffs are really minimalistic and easy to locate in the code. The upstream commit against which this is made is
7dd02539554a81aa39b49ce8df9d4511f92d9f4f
which is already several months old but this is the one against which we have the parsers synced (in fact, it's against https://github.com/techee/ctags/commit/915d69794cd90af9a2e577dd57dd888341ee… to have this fix applied). The best way to review this pull request is to make a diff in meld against this commit in uctags - the diff is really small - and also having a look at the patches excluding the first one which is just unreviewable.
I'd really like if this could get merged soon because I don't want to get again to the state where I have to merge multi-year diffs from uctags. My proposal is that I'd prepare a patch at the beginning of every Geany release cycle which syncs it with uctags (by just taking the current uctags code and applying Geany diffs on top of it) so it gets tested during the development cycle. If we make releases 3 times a year, the diffs shouldn't be so huge and much more easily manageable.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2132
-- Commit Summary --
* Sync with upstream ctags
* Enable Cobol test
* Rename Geany ctags diff markers
* Store varType inside typeRef[1]
* Add all ctags writers to eliminate some geany diffs
* Move bufferOpen() to parse.c to eliminate diff in read.c/h
* Reduce diff size in fileNameMatched()
* Reduce number of diffs in main.c
* Use upstream mbcs.h
* Reduce number of diffs in parse.c/h
* Move diffs together in entry.c/h
* Move isIgnoreToken() to lcpp.c/h which we don't sync with uctags
* Eliminate diff in options.c by adding interactive_p.h
* Reuse createTagsWithFallback1() for Geany
* Eliminate bufferOpen()
* Make sure all functions/global vars added to ctags have the "geany" prefix
* Eliminate diff in runParserInNarrowedInputStream()
* Eliminate diff in promise.c by manually enabling Xtag during initialization
* Add some comments
* Make sure all kinds are enabled in ctags for all languages
* Use the builtin ctags writer functionality to pass tags to Geany
* Remove some diffs from parse.c
* Reuse the functionality of createTagsWithFallback()
* Simplify various ctags-api.c implementations using existing ctags functions
* Fix ctags warning because of cobol parser f/file kind which is reserved
* Add simple ActionScript test
-- File Changes --
M configure.ac (2)
M ctags/Makefile.am (34)
M ctags/main/args.c (6)
R ctags/main/args_p.h (6)
A ctags/main/colprint.c (295)
A ctags/main/colprint_p.h (37)
M ctags/main/ctags-api.c (134)
M ctags/main/ctags-api.h (4)
M ctags/main/ctags.h (8)
M ctags/main/debug.c (102)
M ctags/main/debug.h (28)
M ctags/main/dependency.c (349)
M ctags/main/dependency.h (42)
M ctags/main/e_msoft.h (10)
M ctags/main/entry.c (682)
M ctags/main/entry.h (85)
A ctags/main/entry_p.h (68)
A ctags/main/entry_private.c (37)
M ctags/main/error.c (41)
M ctags/main/field.c (952)
M ctags/main/field.h (47)
M ctags/main/flags.c (107)
R ctags/main/flags_p.h (16)
M ctags/main/fmt.c (57)
R ctags/main/fmt_p.h (0)
M ctags/main/general.h (13)
A ctags/main/gvars.h (29)
A ctags/main/interactive_p.h (29)
M ctags/main/keyword.c (18)
M ctags/main/keyword.h (9)
A ctags/main/keyword_p.h (26)
M ctags/main/kind.c (536)
M ctags/main/kind.h (78)
M ctags/main/lcpp.c (72)
M ctags/main/lcpp.h (4)
M ctags/main/lregex.c (2230)
A ctags/main/lregex.h (47)
A ctags/main/lregex_p.h (76)
D ctags/main/lxcmd.c (1227)
M ctags/main/lxpath.c (12)
A ctags/main/lxpath.h (81)
M ctags/main/main.c (194)
M ctags/main/mbcs.h (23)
M ctags/main/nestlevel.c (1)
M ctags/main/nestlevel.h (1)
M ctags/main/options.c (1985)
M ctags/main/options.h (167)
A ctags/main/options_p.h (183)
D ctags/main/output-ctags.c (59)
D ctags/main/output.h (50)
A ctags/main/param.c (57)
A ctags/main/param.h (38)
M ctags/main/parse.c (2988)
M ctags/main/parse.h (246)
A ctags/main/parse_p.h (154)
M ctags/main/parsers.h (3)
M ctags/main/promise.c (223)
M ctags/main/promise.h (12)
A ctags/main/promise_p.h (24)
M ctags/main/ptag.c (84)
R ctags/main/ptag_p.h (9)
M ctags/main/read.c (622)
M ctags/main/read.h (42)
M ctags/main/repoinfo.h (2)
M ctags/main/routines.c (129)
M ctags/main/routines.h (75)
A ctags/main/routines_p.h (107)
M ctags/main/selectors.c (190)
M ctags/main/selectors.h (14)
M ctags/main/sort.c (94)
M ctags/main/strlist.c (106)
M ctags/main/strlist.h (2)
A ctags/main/subparser.h (81)
M ctags/main/trace.h (101)
M ctags/main/types.h (30)
A ctags/main/writer-ctags.c (292)
A ctags/main/writer-etags.c (133)
A ctags/main/writer-json.c (248)
A ctags/main/writer-xref.c (72)
A ctags/main/writer.c (112)
A ctags/main/writer_p.h (81)
M ctags/main/xtag.c (350)
M ctags/main/xtag.h (43)
M ctags/parsers/c.c (4)
M ctags/parsers/cobol.c (2)
M ctags/parsers/erlang.c (1)
M ctags/parsers/go.c (3)
M ctags/parsers/make.c (1)
M ctags/parsers/objc.c (3)
M ctags/parsers/pascal.c (2)
M ctags/parsers/perl.c (1)
M ctags/parsers/python.c (1)
M ctags/parsers/r.c (1)
M ctags/parsers/ruby.c (2)
M ctags/parsers/rust.c (4)
M ctags/parsers/sql.c (2)
M src/tagmanager/tm_parser.c (2)
M tests/ctags/Makefile.am (5)
M tests/ctags/Package.pm.tags (3)
M tests/ctags/bug1938565.sql.tags (2)
M tests/ctags/random.sql.tags (7)
M tests/ctags/refcurs.sql.tags (2)
A tests/ctags/simple.as (44)
A tests/ctags/simple.as.tags (20)
-- Patch Links --
https://github.com/geany/geany/pull/2132.patchhttps://github.com/geany/geany/pull/2132.diff
--
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/2132
I just started to use Geany, coming from Bluefish... it's really a great tool and I wish to tank everyone contributing!
I only noticed a problem when I try commit to a Subversion repository which needs the user to be authenticated. No problem wen I commit to a repository which does not require authentication.
Here is the screenshot of a packet capture between client and SVN server which shows the issue:
I think to be unable to fix without help from someone. Thanks!
--
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-plugins/issues/777
Editor repeat lines.
Last thing what I did was I was searching word (not sure is that causing the problem)
Please see screen capture, middle is the editor and right is same file opened with vim.
uname: Linux Cauldron 5.7.8-200.fc32.x86_64 #1 SMP Thu Jul 9 14:34:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Fedora 32 (x86-64)
Cinnamon 4.6.5
){kind=link}