I completely agree that this is not a clean solution at all, however the situation for KWin is unclear, and for GNOME, it's already been decided that zwp-virtual-keyboard-manager-v1 will not be implemented. I think they believe it's not a good protocol because it emulates a real keyboard (which I believe is it's advantage). These compositors do actually already support virtual keyboard through the zwp-input-method-v2 protocol. This protocol allows inserting text in a text field and such and doesn't actually handle key events. What the developers of compositors that implement only this protocol usually fail to consider is that this protocol only works in well-written Wayland apps (those which report text input, this cannot work on XWayland apps for example) and also doesn't support modifier keys, so this is also unsuited for terminals. It also can't be brought up on command and will only react to text inputs.

Wvkbd is currently only usable on compositors that support the zwp-virtual-keyboard-manager-v1 protocol. Some major compositors don't# implement this at the moment, notably KDE's KWin (where there's an inactive ticket where this has been mentioned: https://invent.kde.org/plasma/kwin/-/issues/74#note_369963) as well as GNOME, where this isn't even planned.

Thus I believe it would be very useful for users of such compositors if wvkbd could fall back to creating a fake input device using Linux's uinput feature if the protocol isn't implemented. Given that the uinput API also uses linux keycodes, this would be reasonably easy to implement.

Thanks!

I do not see how my build system could possible calculate any reasonable macro path. Do you have any suggestions? The best I can think of would be adding the directory the script is in, but that's not useful when the macro file is 2 directories higher. As I explained already, there is no root project path.

Well, as I stated, I don't really have a module path I could give to the compiler here. I also wouldn't suggest changing existing behavior, but I believe it would be a great addition to have a function that operates on plain file paths instead of module paths of any sort.

I'm thinking that the import path would be relative to the directory the importing file is in. This would allow re-rooting just fine. My use-case here is admittedly very niche: the program I'm writing here is basically one you can give a directory to, and it will compile lua files in there to LuaJIT bytecode. This is to improve loading times of that lua code by doing the JIT compilation of LuaJIT ahead of time. I've recently added in fennel support to this, where fennel files are converted to lua in-place. This needs to work given any directory, and it should also recurse into subdirectories. Treating the given directory as root will not work, because it might be a directory containing multiple projects (for example, my neovim plugin folder). Given this architecture of being able to plug the build system into any lua or fennel project means that there is no way to have any sort of project-specific configuration that I can rely on. I don't see any good solution to allow shared macros here except my proposed relative-path based import.

Neither of these conditions apply here. ... is useless here, as it simply evaluates to nil when the fennel file is compiled using fennel -c foo.fnl. Here's a more clear description of the problem:

Let's consider this directory structure:

macros.fnl
some-dir/
| foo.fnl

#macros.fnl

;; example macro
(macro example [] 42)

#foo.fnl

;; Something like this does not currently exist
;(import-macros-path {: example} "../macros.fnl")

;; The `example` macro is used here
(print (example))

The goal here is to compile foo.fnl to a lua file foo.lua. This lua file should contain the following code:

print(42)

This does not currently appear to be possible. I currently do the compilation by invoking fennel -c some-dir/foo.fnl. This does however not allow the use of macros from macros.fnl.

Your proposed solution does not help here, as there is no consistently established "module path" in the compile-time environment in my use-case. My build system does not enforce any sort of consistent location of source files, making it impossible to solve this using module paths. What is needed for this is for a file to simply include macros from another without depending on any form of module structure.

We could also extend the above example by adding another file into some-dir/. This file should be able to use macros.fnl just as well. It will be compiled to another lua file by a seperate invocation of fennel -c.

It would be very useful for import-macros to alternatively take a plain file path instead of a module name, for example ../macros.fnl.

My use case for this would be compiling fennel files ahead-of-time without having a clearly-defined project root to use as a module path.

This could be implemented somewhat like this: (import-macros-path {: some-macro} "../macros.fnl")

The following sample has been formatted with fnlfmt. It is indented way too much.

;; insane indentation!
(vim.api.nvim_create_autocmd :User
                             {:pattern :PackerCompileDone
                              :once true
                              :callback #((. (require :mzte_nv) :compile
                                             :compilePath) (. (require :packer)
                                                                                                                                       :config
                                                                                                                                       :compile_path))})

Sure! Here's my example code: https://paste.sr.ht/~lordmzte/3f345e7c9b8a2ecca6c39b1d6190dc67f562c745

And here's a screenshot of the bug

Hey!

Sorry in advance if I make some sort of mistake here, first time using sourcehut :D

I've been playing around with your awesome crate, and I'm looking to create a table spanning multiple pages.

It works pretty well, however when a table wraps a page (so when it's too long to fit on one) it doesn't continue on the next page immediately, but first it inserts a small empty row at the end of the page before continuing on normally.

Best regards

LordMZTE