User commands are not being loaded

[donbex]

Even though the plugin has been loaded, as evidenced by the "Compiling textmate module..." message, the user commands (TxMtEnable, TxMtDisable, etc) are not defined.

I haven't written any plugins myself, but judging by what I've seen in other plugins I think you ought to export a module with the required functions from the lua directory and define the commands from the plugin directory -- I'm not sure what the usual way to refer to this is, but where those instructions are placed affects when and how they are loaded by (neo)vim.

P.S.: The README says that the plugin is loaded with require('textmate'), but that won't work because the module is called nvim-textmate (the name coincides with the directory containing the init file under lua). I attempted loading the plugin with both require('nvim-textmate') and require('nvim-textmate').setup(), but only the latter appeared to have any effect.

[icedman]

"Compiling textmate module..." should only display once. And nvim will prompt "Done. Please restart" after successful compilation.

Please try building manually and see if any error occurred.

git clone http://github.com/icedman/nvim-textmate
cd nvim-textmate
make

Compilation currently requires python and gcc.

README updated

[donbex]

I compiled it manually and at first I thought it succeeded, even if more quickly than I would have expected, and then I noticed that automake was missing...

./autogen.sh: line 3: autoreconf: command not found

However, I am now having trouble getting the build to find the lua headers:

/Users/***.config/nvim/bundle/nvim-textmate/module.cpp:2:10: fatal error: 'lua.h' file not found

I should say that I am attempting to compile this on MacOS Monterey 12.5.1. I have lua installed with Homebrew, but I guess the fact that the libraries are installed in a non-standard place is throwing the compiler off. I'll need to tinker with this when I have more time.

[donbex]

Poking around in CMakeLists.txt, I thought that

LUAINCLUDE_DIRS=/usr/local/Cellar/lua/5.4.4_1/include/ LUALIBRARIES=/usr/local/Cellar/lua/5.4.4_1/lib/ make

might work, but sadly that was not the case.

[icedman]

Try copying lua,lib and include under the same directory. And point to that directory.

[casonadams]

Here is what is required from a fedora perspective

FROM fedora:latest

RUN dnf update -y
RUN dnf install -y \
  automake \
  cmake \
  g++ \
  libtool \
  lua-devel \
  make \
  python \
  ;

Once I installed those and did a make make install then things started to work

[donbex]

In my original investigation, I assumed that LUAINCLUDE_DIRS and LUALIBRARIES were environment variables, although after learning more about CMake it that turned out not to be the case. They are actually internal CMake variables created by find_package(Lua REQUIRED) (well, sort of, see below).

After some more investigation, it looks like CMake is actually finding the correct path for the Lua includes, but somehow they are not being taken into account during the build

$ make
[...]
cd build && cmake ../ && make
-- The CXX compiler identification is GNU 12.2.0
-- The C compiler identification is GNU 12.2.0
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/local/bin/g++-12 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/local/bin/gcc-12 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Lua: /usr/local/lib/liblua5.4.dylib (found version "5.4.4")
-- Configuring done (2.4s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/donbex/code/nvim-textmate/build
[...]

And the values in build/CMakeCache.txt do indeed point to the correct paths:

//Path to a file.
LUA_INCLUDE_DIR:PATH=/usr/local/include/lua

//Path to a library.
LUA_LIBRARY:FILEPATH=/usr/local/lib/liblua5.4.dylib

Note that /usr/local/include/lua is a symlink to /usr/local/Cellar/lua/5.4.4_1/include/lua, but that shouldn't be an issue.

Now, the CMake documentation says that the variables declared by find_package(Lua) are called LUA_INCLUDE_DIR and LUA_LIBRARIES, although from the above I presume that the latter is actually called LUA_LIBRARY. Anyway, I tried replacing LUAINCLUDE_DIRS and LUALIBRARIES in

nvim-textmate/CMakeLists.txt

Lines 78 to 80 in b6f372c

	find_package(Lua REQUIRED)
	set(LUA_PREFERRED_INCLUDE_DIRS ${LUAINCLUDE_DIRS})
	set(LUA_PREFERRED_LIBRARIES ${LUALIBRARIES})

with either combination and that still didn't work.

[donbex]

Alright, so adding LUA_PREFERRED_INCLUDE_DIRS to the includes list of the textmate target gets me almost all the way.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2f24095..dc52b05 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -76,8 +76,8 @@ target_include_directories(onigmolib
 )
 
 find_package(Lua REQUIRED)
-set(LUA_PREFERRED_INCLUDE_DIRS ${LUAINCLUDE_DIRS})
-set(LUA_PREFERRED_LIBRARIES ${LUALIBRARIES})
+set(LUA_PREFERRED_INCLUDE_DIRS ${LUA_INCLUDE_DIR})
+set(LUA_PREFERRED_LIBRARIES ${LUA_LIBRARY})
 
 add_library(textmate
   SHARED 
@@ -115,6 +115,7 @@ target_include_directories(textmate
   ./libs/tm-parser/textmate/theme
   ./libs/tm-parser/textmate/extensions
   ./libs/tm-parser/textmate/resources
+  ${LUA_PREFERRED_INCLUDE_DIRS}
 )
 
 set_target_properties(textmate PROPERTIES PREFIX "")

However, now the build fails due to the result of the build:

$ make
[...]
[100%] Linking CXX shared library textmate.dylib
[100%] Built target textmate
cp build/textmate.so ./lua/nvim-textmate/
cp: build/textmate.so: No such file or directory
make: *** [build] Error 1

Indeed, the compiled artifact from the build has a different name:

$ file build/textmate.dylib
build/textmate.dylib: Mach-O 64-bit dynamically linked shared library x86_64

From my limited understanding, it looks like MacOS distinguishes between shared libraries and dynamically loaded modules, although I don't know if this has any impact on how the plugin should treat the built artifact.

[donbex]

Looks like Lua should be able to load both .so and .dylib objects, but from my understanding of the conversation in neovim/neovim#21749 (comment), .so should be preferred. Configuring the textmate library as MODULE instead of SHARED does build a .so object, however I am now at the point that nvim-textmate builds correctly, but if I try and enable it in neovim with require('nvim-textmate').setup() then neovim just crashes upon startup, without any logging information as to why.

[Emptyfruit]

@donbex thanks to your efforts i was able to get the plugin to build successfully on my macos 12.6.3. also.
I tried both .so and .dylib variants (to keep .dylib i had to change this line
package.cpath = package.cpath .. ";" .. local_path .. "textmate.dylib").

In both cases the editor crashes without any messages. Based on a simple comment-out debugging, it seems like the call to the library crashes the editor:
local ok, module = pcall(require, "textmate")

@donbex were you able to make it work in the end?
@icedman if you have any ideas, it would be much appreciated. I need to work on a lot of files, which have no treesitter grammar yet, this plugin looked very promising to me.

UPD: later found this nice fork https://github.com/jakenvac/nvim-textmate-macos where the build is fixed. But sadly the highlighting itself does not seem to work, and executing TxMtEnable just causes a lot of error messages in the editor.

[donbex]

@Emptyfruit No, unfortunately I was never able to get it to work.