Yes, we have to. Just because we made no modification doesnt mean we don't have to provide the source we used to compile the binary. Pointing to another repository isn't sufficient, as far as the GPL is concerned.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/560#issuecomment-193745533
In theory we'd have to keep the same source we used for compiling in case someone asks for it. Re-distributing an existing binary distribution doesn't have this problem (though it's also some kind of a grey area).
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/560#issuecomment-193741865
Yeah, compiling `grep` with MSYS2 is as easy as `configure && make && make install`, woohoo.
The only additional dependency it creates is `pcre` but this is ok I guess.
Now the question is: would it be ok to include a pre-compiled grep.exe in this script or add a few lines to the script to download, unpack and build `grep` on the fly to make it more transparent where it comes from?
I'd vote for the latter option but it will increase runtime of the script signifanctly because compiling `grep` will take some time (to be exact it is rather running `configure` which is slow).
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/560#issuecomment-193653266
Since saving your work is one of the most important actions of an editor I think it deserves an issue for itself, rather than continuing comments on a closed and not entirely related issue #921. But please refer to that for discussion to date.
Some points to consider:
1. As I said above, saving is important, but everybody should remember that the Geany buffer is still there to be saved somewhere else if there is a problem. Many people lose data when they panic and close Geany without saving elsewhere, save locally, save to a usb stick, just save *somewhere* dammit!!! Sadly we can't help with user brainfade problems.
2. There is an expectation among users that they should have the convenience of editing remote files as if they are local, without the effort of mounting remote file systems. And the default configuration of some distros seems to have changed away from doing that mounting automatically (see #921 for eg). So this is a possible enhancement to Geany capabilities if someone wants to provide an implementation proposal, eg by extension of the GIO saving system, use libCURL etc.
3. Geany currently has three ways of saving files with varying characteristics in terms of overhead and safety in case of save failure, which is always a possibility with networked saves (and much more rarely with local saves)
* simply writing the file using libc calls which is simple, fast, entirely within our control but is unsafe,
* using Glib file saving which is safe but loses metadata, or
* using GIO which is just as unsafe as standard calls due to a long standing bug (last comment 2014 the previous one 2011), but if no fault occurs it does not lose metadata and handles many varying systems, and IIUC can also be made to do the remote stuff.
The save methods above do cover many varying system configurations and use-cases, but as you can see none of them is perfect. Is that ok, or do they need to be improved before enhancements are considered?
The purpose of this issue is for both the status quo and future directions to be discussed so we have a plan against which any future proposals can be considered.
Some points in no particular order:
* do we need to support remote access directly, sure there are lots of grumbles, but none of them have suggested that they contribute to the improvements, and the regular contributors don't seem to need the feature, so why bother (harsh but important to consider)
* is there a better (portable) library to do the saves fast and safe without much effort by Geany contributors
* the Geany team is small and doesn't have access to the networked configurations that many people seem to expect to work, so the testing will be minimal, and we don't even know all the combinations of use-cases that are out there to know where effort is best spent, so any solution will be "use at your own risk, you are doing the testing"
* the periodic metadata checks Geany does need to be re-considered for remote files due to the delay it can cause
* perhaps Geany should support a small manageable set of use-cases itself, and that may simply be the current libc writes, and delegate all others to libraries like GIO on a users risk basis.
All thoughts and suggestions welcome.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/942
```console
Making check in po
make[1]: Entering directory `/home/travis/build/b4n/geany-plugins/_build/po'
make[1]: *** No rule to make target `../../multiterm/src/config.c', needed by `geany-plugins.pot'. Stop.
make[1]: Leaving directory `/home/travis/build/b4n/geany-plugins/_build/po'
make: *** [check-recursive] Error 1
```
71fa02ef2f0f846d42a3082136fd236b0da49ab6 listed the *.c* in *POTFILES.in*, but those are only generated when MultiTerm is actually built.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/390