Avoid time interval for regular checks for file changes

[phisigma]

When an opened file is changed in the background by another program, this is normally not reported immediately, but checked by default every 30 seconds (see Preferences → Files).

This behavoir is annoying as it is possible, at least under Linux, to update the file at once when it is changed. GEdit does so, for example.

I don’t know, but guess, that this is possible even under Windows. I ask you to add this feature (if necessary only for Linux) and update the configuration dialog accordingly.

[elextr]

Using the operating system file monitoring was incorporated into Geany some time ago, but it was buggy and nobody could get it to be reliable (multiple notifications rather than missing notifications IIRC), so it was turned off. Nobody has worked on it since so clearly it isn't a widely needed feature. I think the code is still in place, so if somebody needs it, they can investigate the code and try to fix the issues.

[codebrainz]

If you re-compile Geany with USE_GIO_FILEMON defined in the CFLAGS (or CPPFLAGS or whichever), it should activate the experimental code that uses OS file-monitoring, if you feel like testing/fixing it.

[phisigma]

Tried but the README file doesn’t seem to be correct, there is no file ./configure. The geany code seems to be very C like, so probably no fixes from me, sorry.

Nevertheless, it possibly may not be a “widely needed feature”, but the current solution is obviously a workaround. I hope someone feels appointed to this task.

[elextr]

Tried but the README file doesn’t seem to be correct, there is no file ./configure. The geany code seems to be very C like, so probably no fixes from me, sorry.

The README is the instructions for the source distribution tarball (which includes several things not in git), not for git builds. Its unfortunate that the README appears on the github front page. The documentation needs fixing, it is captured in #756 but nobody has done it yet.

The crucial difference is that you need to generate the configure file using ./autogen.sh the first time after a new clone.

Nevertheless, it possibly may not be a “widely needed feature”, but the current solution is obviously a workaround. I hope someone feels appointed to this task.

Geany is open source software, all contributors are volunteers, so nobody can be "appointed" unless they do it themselves, and the fact that nothing has been done since the code was added says nobody is interested/needs it enough to appoint themselves.

[elextr]

it is captured in #756 but nobody has done it yet.

Actually the need to use autogen.sh is mentioned in README since commit apologies to @b4n

[phisigma]

The crucial difference is that you need to generate the configure file using ./autogen.sh the first time after a new clone.

I gave my best, but now I give up. Could’t get ./autogen.sh running.

Nevertheless, it possibly may not be a “widely needed feature”, but the current solution is obviously a workaround. I hope someone feels appointed to this task.

Geany is open source software, all contributors are volunteers, so nobody can be "appointed" unless they do it themselves, and the fact that nothing has been done since the code was added says nobody is interested/needs it enough to appoint themselves.

There may be a misunderstanding due to my only medium abilities in the English language: I meant that I hope that somebody (by himself!) feels to work on it, not that he or she may be appointed by someone else. Sorry!

The fact that there is already a serious try for this enhancement makes me a little bit confident, as it simplifies the preferences dialog.

[elextr]

Could’t get ./autogen.sh running.

What do you actually mean not "running", does it give you an error? If so what? Does it complete but no configure is built? ...

[codebrainz]

The fact that there is already a serious try for this enhancement makes me a little bit confident

Testing and to discover how to overcome the multiple signals for the same event is mostly what's needed before it can be enabled by default, I think.

If I remember correctly, the main problem was that when saving a file, it would trigger a modification event from that very save, causing the infobar message to pop back up after saving. You can't just disable monitoring, save, and then re-enable monitoring, as the actual event comes back from the kernel "some time" later, which, if memory serves, was often/always after re-enabling monitoring. If Geany waits too long to re-enable monitoring, it could miss events, so basically we'd need the alternate methods of checking (timer, tab-switch) still, and in such a case, the monitoring events won't come right away, thus defeating the purpose of file monitoring, to some extent.

We should look at other apps that use inotify/GFileMonitor to see how they handle it, maybe there's a trick that the current code isn't using to avoid this situation.

[elextr]

Monitoring is quite difficult, even the Linux kernal inotify documentation contains many warnings about delays, and errors, and races, and network filesystem issues.

Also its difficult to exclude our own modifications since we don't actually know what they are, non-atomic saving overwrites the original file, atomic saving writes a new file and renames over the original file, and GIO saving tries atomic saving, but if that doesn't work falls back to non-atomic.

[codebrainz]

In particular, from the man page of inotify:

... there is no easy way for a process that is monitoring events via inotify to distinguish events that it triggers itself from those that are triggered by other processes.

And...

... it does not catch remote events that occur on network filesystems. (Applications must fall back to polling the filesystem to catch such events.)

[elextr]

@frankstaehr even if all that has scared you from testing the notifications, I would like to find out why you can't run autogen.sh. It works just fine as far as we know, so having somebody who has reported a problem gives us a chance to fix it if there is something wrong, since others may have the problem and just go away and not report it.

[phisigma]

What do you actually mean not "running", does it give you an error? If so what? Does it complete but no configure is built? ...

There is no “real” error. It just says

**Error**: You must have `glib' installed.
You can get it from: ftp://ftp.gtk.org/pub/gtk

but there is no package glib in my repository (and I’m not interested in downloading any). Probably the package has a similar but other name. And by the way, the link is not valid.

So altogether, most instructions for compiling/configuring are outdated. This makes it difficult for newbies like me. Furthermore, there seems to be no need for testing this specific feature due to the above mentioned technical issues, that have to be solved first (if this is done at all).

[elextr]

Ok, thats saying you didn't read the "Requirements" section of the README where it says you need the development packages for GTK and its dependencies to compile Geany. You probably have the runtime part, but not the development package. I understand why some distros split the development part from the runtime part, but it doesn't help to get you going.

The error message isn't ours, autogen.sh is a tool from the autotools project that writes and then runs the configure script, the message is from the configure script that autogen.sh wrote. I guess autotools is out of date with its links, or your distro is supplying an old version.

It always a tension as to how much existing knowledge a README should assume. Its purpose is to allow people building from source to do so, not to be an education into how to build software. But sure it can be a learning curve if you havn't done much building from source before.