Thank you,
Might be a good time to review the following issues:
https://github.com/geany/geany/issues/301
https://github.com/geany/geany/issues/1388
--
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/ge
As promised post release.
--
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/1246#issuecomment-315687050
Merged #1246.
--
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/1246#event-1165970784
@elextr Seeing as the release has been postponed, might be a good time to merge
this 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/pull/1246#issuecomment-313852021
@vfaronov thanks for testing, since we are only a week away from the next
release (if it goes ahead) I'll hold off from committing it just now, OP or
others prompt me after release if I forget.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
So I promised to test this.
I’m not using this feature on a day-to-day basis for reasons I [explained
previously](https://github.com/geany/geany/pull/1246#issuecomment-298176055),
but I did test this PR specifically. I checked things like:
- Windows
- remote files (SFTP mounted via Thunar (GVfs
I do Git checkouts/rebases often, and the need to reload every document is
quite a nuisance. In fact, for the past few months I’ve been using a small
private plugin that does the equivalent of #1471.
I will be running with this change to see how it works for me. I will also try
to test it brief
@gdm85 as far as I know, none of the major distros apply patches to change
Geany's preferences. Also, due to the way Geany stores its preferences (writes
them all to user-config dir with no concept of "unset" or "defaulted"), once an
existing user opens Geany once, they will always have that def
My last 2c on defaults: another way to decide the change is to "observe" what
major distros (I am thinking of Debian, Ubuntu, Arch) do: if distros with most
users are applying patches to change a default option value, then at some point
(it might take one or more years) one can safely decide to
@elextr sure. I have only tested it with changes to 1 file and multiple files
so far, no crashes. I will use this from now on so expect me to report back if
I see some problem.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
@gdm85 as you will notice on #301, the OP is looking for testers whose workflow
will involve this change. Since you are going to merge it into your copy of
Geany and therefore presumably use it, maybe you can become the tester to help
get this PR committed.
--
You are receiving this because y
I think the defaults should preserve the historical way Geany has worked so far
(one can make exceptions to this for "major" releases and/or reasons); this is
just to not break the workflows of all those users that do not come here to
complain or express their opinion :) Likewise, I would not di
> Ah, I was not aware resources were slack. I saw all the activity around the
> release and thought it would be a good idea to remind the maintainers about
> this pr.
Its no problem to ping PRs, they do sometimes get forgotten.
> If resources continue to be a problem then maybe a change of styl
Ah, I was not aware resources were slack. I saw all the activity around the
release and thought it would be a good idea to remind the maintainers about
this pr.
If resources continue to be a problem then maybe a change of style is
necessary. Perhaps a well-formed pull request could be pushed to
@shiftee from time to time all open source projects that are not corporately
supported have periods when available resources have a dip. People can be
working on other projects that they didn't think would take anywhere near as
long!!! (guilty). People are interrupted by real life (guilty). Pe
Would anyone be able to test this in the next few months?
--
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/1246#issuecomment-290008765
Hurry up, it's getting cold :)
--
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/1246#issuecomment-288328832
Sounds good. Does anyone have the time to test it in that case?
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/pull/1246#issuecomment-286673441
hmmm, not sure, on re-reading the thread it appears that @codebrainz and I have
ended up agreeing to have the option off by default, I think.
LGBI
In which case it just needs someone to test it and commit it.
--
You are receiving this because you are subscribed to this thread.
Reply to this
So what is the current status of this PR?
--
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/1246#issuecomment-284741356
> It would be nice if Scintilla offered a circular redo-buffer to limit memory
> usage.
Older editors used to do that for memory reasons, but its rare to get the size
right, even ignoring complete reloads we are talking of here. Normal edits are
rarely a problem, so the buffer size doesn't nee
Yes, both are valid depending on the value of
file_prefs.keep_edit_history_on_reload.
Keeping it as an option defaulting to false is probably best.
It would be nice if Scintilla offered a circular redo-buffer to limit memory
usage, I find the default behaviour strange:
> Scintilla has multiple
> It looks to me like we can remove the auto_reload option and make it automatic
without data loss.
@shiftee two ways you can lose data with this scheme:
1) a modified file that has been saved (so the buffer is clean) and is then
changed on disk may lose the changes that are still in the buffer
> It looks to me like we can remove the auto_reload option and make it automatic
without data loss.
I agree, but for the moment it's probably wise to keep it as is since it may
cause high-memory usage.
> Am I correct in assuming you would prefer a finer-grained version of
> file_prefs.keep_edit
The current state of the pull request looks like this.
```
if( buffer.is_clean )
if( auto_reload )
if( file_prefs.keep_edit_history_on_reload ) //default=true
possibleHighMemoryUsage();
else
possibleDataLoss();
We support like 20 different options and code paths for simply saving a file, I
don't see an "if" statement to disable monitoring such a big deal in comparison
:)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gith
> That's why in the first sentence you quoted I said "...if enabled by default
> (or always)...".
It would only be relevant to the "always" case, and always is not acceptable
IHNSHO.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
That's why in the first sentence you quoted I said "...if enabled by default
(or always)...".
--
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/1246#issuecomment-249770103
But people who did NOT have the auto-reload turned on then would get multiple
messages, unless you tied the type of monitor to the reload option. But that
doesn't sound sensible, you are now supporting two monitor methods for what
gain?
--
You are receiving this because you are subscribed to
No, but like I said in the last sentence you quoted, it seems like the feature
in this PR would circumvent it.
If you just saved a file and then get an FS event immediately it doesn't matter
since the buffer is clean and there won't be any nagging UI. Except for the
previously mentioned misbeha
> A nice byproduct of this feature, if enabled by default (or always) is that
> we could potentially start using proper file change notifications
> (GFileMonitor and friends which is already in the code but disabled). It
> needs testing but it seems like it would circumvent the double-notificati
A nice byproduct of this feature, if enabled by default (or always) is that we
could potentially start using proper file change notifications (GFileMonitor
and friends which is already in the code but disabled). It needs testing but it
seems like it would circumvent the double-notification probl
> I have said I don't think it should affect the chances, and you have said you
> disagree, so its up to somebody else to determine then.
I don't much care if it's done as part of this PR or not, but if it's not,
there will be a period where the master branch will contain a potential
landmine o
> > Ok, well, unless @shiftee wants to make it so, thats not part of this PR
> Why is dealing with bad interactions between features not part of a PR unless
> the submitter (solely) wants to make the change?
The submitter can always say they don't want to do something, thats always
their choice.
> Ok, well, unless @shiftee wants to make it so, thats not part of this PR
Why is dealing with bad interactions between features not part of a PR unless
the submitter (solely) wants to make the change?
> But until its done the default should be off.
I agree, but it can be done as part of this
> No I want it on, but I don't want each auto-reload to store the whole buffer
> in the reload history.
Ok, well, unless @shiftee wants to make it so, thats not part of this PR. But
until its done the default should be off.
--
You are receiving this because you are subscribed to this thread.
> So you actually want auto-reload off by default then.
No I want it on, but I don't want each auto-reload to store the whole buffer in
the reload history.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/
> The difference is currently you have to manually (or in my case accidentally
> manually) reload, whereas if you have a file written to often (like multiple
> times per second) like the log file example, or even just switching VCS
> branches while many files are open a bunch of times, the memor
> Clearly you don't accidentally checkout an old version over your changes as
> often as I do :(
It won't, well at least Git won't allow you to change branches with modified
files, also Geany wouldn't lose your changes unless the buffer was clean. If it
the buffer was clean, just use Undo to r
On 27 September 2016 at 11:41, Matthew Brush
wrote:
> VCS or something changed the file on disk doesn't mean I want to lose the
> buffer contents
>
> You won't lose it, it's stored in the undo history automagically.
> Moreover, in this specific case of VCS, I usually would want it to
> auto-reloa
> VCS or something changed the file on disk doesn't mean I want to lose the
> buffer contents
You won't lose it, it's stored in the undo history automagically. Moreover, in
this specific case of VCS, I usually would want it to auto-reload since I want
to be working on the correct version of the
Defaulting to on changes the current safe behaviour without any warning. Just
because the VCS or something changed the file on disk doesn't mean I want to
lose the buffer contents. Currently you will never lose the buffer contents
without your explicit approval.
--
You are receiving this bec
We could probably have the preference defaulted to on, since it's most users
would probably expect this behaviour, it doesn't clobber any changes (only
happens if the buffer is clean), and it's more inline with the removal of
reload confirmation and storing reloads in the undo buffer automatical
elextr approved this pull request.
--
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/1246#pullrequestreview-1524571
@shiftee pushed 1 commit.
5c85d81 Improve auto-file-reload manual entry
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/geany/geany/pull/1246/files/a8fc73c2477daaeb7eb960b2a74013e3486f1a2c..5c85d81d711a17635fb357d21ded5f78780fe9f6
elextr commented on this pull request.
> @@ -2601,6 +2601,10 @@ gio_unsafe_save_backupMake a backup when
> using GIO unsafe file f
keep_edit_history_on_reload Whether to maintain the edit history when
trueimmediately
reloadin
@shiftee pushed 1 commit.
a8fc73c Add auto-file-reload feature to manual
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/geany/geany/pull/1246/files/8c62c98517443ecc9eb6e1634ff72cb9cc3b61a7..a8fc73c2477daaeb7eb960b2a74013e3486f1a2c
elextr requested changes on this pull request.
Looks ok by inspection, but the new preference needs to be documented in the
table of various prefs in the manual.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://git
48 matches
Mail list logo