"Project" commands simply based on directory paths

[dcst-it]

Hi, again! First of all, excuse me for monopolizing the forum recently. To my partial excuse, I've been silently learning, experimenting and developing Textadept scripts and modules for more than one year... and now I feel OK to finally ask about some things.

In my current understanding of the documentation, Textadept's only concept of "projects" is some kind of parent directory of an opened file (or of itself) in which it recognizes some version control system. Beside that, it supports file-specific and extension-specific compile and run commands, plus another history-based mechanism. I find this system very elegant, as it does not mess the project's directory with editor-specific project files, and allows for having multiple "projects" opened in the same instance.

To my disgrace, in most of my personal unpublished "projects" (both programming-related and not - everything that has a makefile is a "project" in my point of view) I do not use any VC system. I understand that by creating an empty .git directory in the project's root directory and by configuring the related commands (up to three) in my init.lua, when editing a file of that project Textadept lets me execute these commands in that project root directory as the working directory.

But... It would be possible to have a concept of "project" which simply is a directory path configured in init.lua with its project-specific commands? This way, when editing a file inside that directory or its subdirectories, the project-specific commands relative to that path would always be available, regardless of the fact of finding a VC system or not. This would be very useful in multi-file projects without a VC system... It would be the analogous of the already existing mechanism based on specific file paths, but with directories.

[orbitalquark]

Please continue to ask questions if you have them! Everyone can benefit :)

I think the short answer is you ought to be able to edit Textadept's core/file_io.lua's vcs table definition

textadept/core/file_io.lua

Lines 362 to 365 in a5e5a77

	local vcs = {
	['.bzr'] = 'directory', ['.git'] = 'directory', ['.hg'] = 'directory', ['.svn'] = 'directory',
	['.fslckout'] = 'file', _FOSSIL_ = 'file'
	}

and add ['init.lua'] = 'file'.

It may be worth exposing that table to the outside and let ~/textadept/init.lua add to it. I'll consider this.

[orbitalquark]

Actually, you can just define your own io.get_project_root() in ~/.textadept/init.lua, copying the one from core/file_io.lua, something like:

--- Map of version control files to their lfs modes.
local vcs = {
	['.bzr'] = 'directory', ['.git'] = 'directory', ['.hg'] = 'directory', ['.svn'] = 'directory',
	['.fslckout'] = 'file', _FOSSIL_ = 'file', ['init.lua'] = 'file'
}

function io.get_project_root(path, submodule)
	if type(path) == 'boolean' then path, submodule = nil, path end
	if not assert_type(path, 'string/nil', 1) then path = buffer.filename or lfs.currentdir() end
	local dir = path:match('^(.-)[/\\]?$')
	while dir do
		for file, expected_mode in pairs(vcs) do
			local mode = lfs.attributes(dir .. '/' .. file, 'mode')
			if mode and (submodule or mode == expected_mode) then return dir end
		end
		dir = dir:match('^(.+)[/\\]')
	end
	return nil
end

[dcst-it]

Thank you!! What I was trying to say is not to use the init.lua path as a project path, but to recognize arbitrary project paths to be defined inside _USERHOME .. '/init.lua' independently from the presence of a VCS... But, nonetheless, you pointed me in the right direction!

With the following code added in my init.lua (actually in my custom module) Textadept recognizes any path found in either of the textadept.run.build_commands, textadept.run.test_commands and textadept.run.run_project_commands as a project path, even if a VCS is not found.

-- Custom project system toggle switch.
M.customProjectSystem = true

--- Redefined map of version control systems to their "lfs" modes.
local vcs <const> = {
	-- VCSs recognized by default.
	['.bzr'] = 'directory',
	['.git'] = 'directory',
	['.hg'] = 'directory',
	['.svn'] = 'directory',
	['.fslckout'] = 'file',
	_FOSSIL_ = 'file'
	-- Custom "VCSs".
	-- ['makefile'] = 'file',
	-- ['IDE/makefile'] = 'file'
}

-- Redefined version of this function which adds the ability to recognize
-- project definitions based on directory paths.
function io.get_project_root(path, subModule)
	-- Default project definition; it must be updated with the original.
	if type(path) == 'boolean' then
		path, subModule = nil, path
	end
	if not assert_type(path, 'string/nil', 1) then
		path = buffer.filename or lfs.currentdir()
	end
	local dir = path:match('^(.-)[/\\]?$')
	while dir do
		for file, expected_mode in pairs(vcs) do
			local mode = lfs.attributes(dir .. '/' .. file, 'mode')
			if mode and (subModule or mode == expected_mode) then
				return dir
			end
		end
		dir = dir:match('^(.+)[/\\]')
	end
	-- New project definition based on directory paths.
	if M.customProjectSystem and buffer.filename then
		for projectPath, _ in pairs(textadept.run.build_commands) do
			if buffer.filename:find(projectPath .. '[/\\]', 1, false) then
				return projectPath
			end
		end
		for projectPath, _ in pairs(textadept.run.test_commands) do
			if buffer.filename:find(projectPath .. '[/\\]', 1, false) then
				return projectPath
			end
		end
		for projectPath, _ in pairs(textadept.run.run_project_commands) do
			if buffer.filename:find(projectPath .. '[/\\]', 1, false) then
				return projectPath
			end
		end
	end
	return nil
end

[dcst-it]

In this way the editor's project system is extended, while mantaining the original VCS-based mechanism...

The code is probably not the most elegant and concise, but it seems to work. Clearly, nested projects are not currently supported, as the project path (is any) is simply the first one which is found when iterating through the project commands tables.

Another possibility would be to expose the original vcs table, as you mentioned, and extend it to search for (e.g.) makefiles as in the comments in my version of the table. But the path-based system is simpler and more general... What do you think about it?

[orbitalquark]

I agree that the path-based system is simpler, however, this would make the core/file_io module dependent on the non-core modules/textadept/run module, which I don't want to do.

Nevertheless, your custom io.get_project_root() looks fine to me. Nice work!