Changed approach to files limited project. Now we keep into the
top-level dir a list of subdirectories to be shown. When in file
limited mode we will not scan subdirectories unless they are in
the list of shown subdirectories.
With the new mechanism the function get_subdirectory_files always
recurse into subdirectories by default but is able to figure out
to stop recursing into subdirectories for files limited project.
The new mechanism is more robust of the previous one. Now the
rescan of subdirectories is compatible with files limited project.
Add a flag core.redraw to force redraw when rescan is done.
Inhibit recursion when files_limit is reached.
Still doesn't work correctly for files limited directories.
Ensure that we call coroutine.yield when scanning recursively.
Do not use a weak-key based on project dir when adding the job for rescan.
Since "dir" was not unique many threads were missing.
Ensure we do not block waiting for events if there are pending rescan.
In theory the dmon based directory monitoring is enough to ensure that
the list of project files is always correct. In reality some events
may be missing and the project files list may get disaligned with the
real list of files.
To avoid the problem we add an additional rescan to be done later in a
thread on any project subdirectory affected by an event of directory of
file change.
In the rescan found the same files already present the thread terminates.
If a difference is found the files list is modified and a new rescan is
scheduled.
If the max number of files limit is achieved when the application
is starting the StatusView is not yet configured so we cannot
show the warning.
We show the warning in the function scanning the directory only if
the StatusView is up. On the other side, when the application starts
it will check if the initial project dir hit the max files limit and
show the warning if needed.
When scanning a subdirectory on-demand ensure files aready present
are not added twice. Files or directory can be already present due
to dir monitoring create message.
Fix check for ignore files when adding a file to respond to a dir monitor
event to use each part of the file's path.
Fix C function to compare files for treeview placement.
Introduce a new field in items generated by TreeView:each_item()
to point "dir" to the toplevel directory entry.
In this was we can simplify the code and know if the toplevel
directory is files limited.
Verity if dmon_watch returns an error.
Add a check if an added file for which we received a create event is
ignored based on the user's config.
Add some explanatory comments in the code.
In the treeview the implementation was checking the files list
to detect if it changed because of a project scan. Since we removed
the project scan we no longer need the check.
Removed the TreeView's self.last table that stores previous files
object by top-level directories.
Since the directory monitoring is now basically working we remove the
project scan thread periodically scanning the project directory.
Each project's directory is scanned only once at the beginning when
calling the function `core.add_project_directory` and is updated
incrementally when directory change events are treated.
The config variable `project_scan_rate` is removed as well as the
function `core.reschedule_project_scan`.
Now we request a watch on the directory and we manage sending
and receiving directory change events.
The mechanism to update on the fly the directory scan is not complete.
The code to remove a file is there but we need to implement the code
to add a new file.
It is reported that the built-in lua function os.remove(path) does
not removes empty directories on windows. To fix this a system.rmdir
function is introduced that calls a native win32 function.
Also common.rm(path, recursively) was added which wraps system.rmdir()
to easily delete an entire folder with all its contents.
Add a renderer.font's method "copy" to clone the font object
by specifying an optional new size. In the size is not given
the size of the original object is used.
Should fulfill the request from issue #288.