For the record I was testing up to a minute between characters, so if time is a
factor it's not enough of one IMO.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks for the tip, HOME will work for me.
But I still think the bug is valid, as people get so used to their keystrokes,
and I don't see any reason to not make this one consistent with what other
systems do. It seems line-break is considered part of a "contiguous spaces"
virtual keyword, so
A quick shortcut I am used to working is hitting ctrl and the left arrow a few
times, and I end up at the start of the line I am editing. This allows me to do
things like select a few lines and group-indent them, without having to use the
mouse or hit too many keys.
However, in Geany doing
(Thanks for all your replies to my issues @elextr - I know I've been posting a
lot and fixing nothing myself, but I have too many backlogged commitments right
now to start making pull requests.)
This patch resolves the problem, simply by matching the spawn API line limit to
the messaging
Agreed, that makes more sense.
--
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/2247#issuecomment-530174540
If I change the current project's 'base path' setting, refreshing the project
organizer should first re-read that setting before crawling the directory
structure.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Geany is using GtkRecentManager, GNOME's system for sharing recent documents
across apps.
This has the consequence of gedit, and likely many other tools, having files
that were opened in Geany in their recent files list.
Developers work across dozens of files, so the recent files list in apps
I don't believe the given workaround will work. In addition to its own config,
Geany populates GTK's GtkRecentManager - meaning gedit's recent file list is
going to get populate with anything you open in Geany.
--
You are receiving this because you are subscribed to this thread.
Reply to this
I realize this is not a bug, but to me it does deserve some attention for a
couple of reasons:
1) A lot of time has passed since the different coloring was implemented, and
browsers all support the newer "CSS3" properties. There's no reason to
distinguish them and it is unnecessary cognitive
Hi, I'm coming from TextMate 2 on Mac, and TextMate does a great job with
projects - by essentially making it invisible (frictionless).
You just open a folder, and that folder automatically becomes a project.
Geany could easily do something similar in my opinion. I don't know if the
GNOME file
If long lines are matched (e.g. in binary or minified files) then 2 bad things
happen...
1) An internal buffer apparently crops each line, before the length of the line
grepping is wrapping to (apparently)
2) Subsequent lines which grep has wrapped then show on separate lines
The result is a
Currently I can type whole paragraphs, and undo will wipe them all.
I understand this comes from Scintilla and your options may be limited, but to
me it is very jarring. I'd expect undo to work either by some kind of rough
keyword detection algorithm, or just character-by-character.
I think
It would be great to be able to right click on any directory in the organizer
and have an option to create a new file (blank, or from one of the templates)
in there. It'd ask a filename, and if a template had been chosen the default
would be based on the name of that template.
--
You are
When a "regular expression is too large" error happens, you may not see the
cause of the error, because the explanation shows horizontally after the
regular expression, which as we know, is too large.
This error message seems to be generated by PCRE. Perhaps if the error message
is too large
Just a Search->Find operation.
--
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/2244#issuecomment-518058371
This is just a little feature request...
When switching between git branches, files come and go from existence. It's
annoying to have to do a manual refresh for "Find file" to continue working.
What if "Find file" asked me if I wanted to do a refresh if it gets zero
results, and then it would
Cool :).
A couple of notes:
- I do not believe "-M" makes "." match line breaks. My recent test confirms
this, unless I'm going crazy.
- If we're passing in lots of filenames in recursive mode isn't that going to
hit some kind of parameter string limit?
--
You are receiving this because you
Project Organizer has a "Search in full path" checkbox in the "Find Project
File" dialog.
The value of the checkbox is lost when Geany is re-opened, it will go back to
unchecked.
Ideally the value should be remembered, as many (but not all) developers will
have a preference for it being
It would be very useful to be able to search across multiple lines in "Find in
Files". This doesn't work using patterns (\n) or by pasting in the line break
character.
I realize this is all because `grep` doesn't really support multi-line
searches, and it would not be difficult to implement
Indeed, they don't. But it's an issue, at least for me.
--
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/2321#issuecomment-534760566
Well, as per the original post, I would have no problem if Geany was adding
nothing ;-). I already commented it out on my git clone.
I do agree per-project recents would be a good feature, but I see it as a
separate issue.
To correct the record, I haven't talked with the gedit folks (just
I think all these 3 dialogs should share the same 'search for' value and
history.
For example, if I do a search for 'foo' and then decide I want to do a replace
of 'foo' with 'bar', it would be good if the replace dialog had 'foo' in there
already.
(I realize if I leave the last search result
If I do a 'Find in Files' I can fill in the 'Files' setting to limit search to
a particular file pattern (fif_files).
However, if I put in '--exclude' and '--exclude-dir' parameters into 'Extra
options' it won't work. This is because '--include' has to come before
--exclude*, but Geany puts
After discussing the design of GtkRecentManager, I can see actually it's not so
bad - it looks more like gedit has a bug where it's not correctly filtering
(https://gitlab.gnome.org/GNOME/gedit/issues/217). But it was suggested on my
GNOME issue that Geany should not be populating it for files
Closing as I put a merge request through to get gedit fixed.
--
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/2294#issuecomment-540678598
Closed #2294.
--
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/2294#event-2703478661
> I think you could already set pcregrep as the grep tool in Preferences. Then
> in the other options entry [of find in files] you can add any necessary flags
> for multi-line matching.
Thanks, I wasn't aware of the option. It almost works, but I had to tweak the
code:
Thanks.
To clarify, I don't consider the difference in `include` syntax a problem.
After my patch, everything works, it's just the user has to type in different
syntax. I think it works great, I like the additional control you get with
/s/globs/regexps.
--
You are receiving this because you
When you do a "Find in Files" search, it will show the search command in the
first line of the results.
However, this is quite badly broken. It does not include the directory
specifier part of the command, and it doesn't provide escaping (e.g. quoting)
of search terms.
I have fixed it in the
If I open a second instance of Geany, copy something to the clipboard, close
that instance, and then try and paste into that second instance, nothing
happens. This is using the drop-down menu, the context menu, and ctrl+v.
However, I can then paste into other applications and it works fine.
So
Sorry, I should have specified those things, mind fart on my part.
`geany 1.37 (git >= fe7d2f87) (built on 2020-03-21 with GTK 2.24.32, GLib
2.62.1)`
As it says, it is a custom build - but not very custom, and certainly I've not
been messing with GTK stuff.
`
lsb_release -a
No LSB modules are
No.
I'm actually looking into it now, but I don't have a whole lot of time so I
suspect I'll get nowhere.
Issue is likely in Scintilla IMO.
Happens even if I use a clipboard manager and can see the current clipboard
within it!
Happens even if I close all Geany instances and open a new one and
Noted. I can say with my debugging so far that `gtk_selection_data_get_length`
is returning -1 for my test case and `ScintillaGTK::InsertSelection` has a
branch check on `>=0`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
I really tried hard to debug this, and I'm completely stuck.
I can clarify the bug. It's definitely at least partly a Scintilla issue, not
specific to Geany. I can reproduce it in MySQL Workbench (which I've most
definitely not compiled myself).
GTK3 vs GTK2 is not an issue (of note I was on
Fixed upstream https://sourceforge.net/p/scintilla/bugs/2175/ :)
--
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/2503#issuecomment-628943388
I don't know if it is relevant, but my logged in X11 session is vt2, and the
gdm login screen is on vt1. i.e. I can ctrl+alt+f1 and it will go to the login
screen, and it will then click back to vt2 after re-logging in.
This is the 'default' on my system (i.e. I haven't knowingly done anything
Closed #2503.
--
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/2503#event-3389828905
37 matches
Mail list logo
