I’m porting an assembler that I think it will be a good addition to HP repo. This comes with its own set of syntax highligting files, including VIM among others. I think it would be a good idea to install these modules with the main assembler as well.
Is there a standard way to check if a package is installed in a recipe (VIM, in this case)?
Assuming VIM is installed, where have I to install/copy/ put those add-ons files?
Let’s say I manually copy these files on a settings dir, what’s happen if the package itself is removed?
I think there are lots of different ways to perform those actions within a bash script. I was wondering if there is a more standard and robust way to do…
If any script is to run after install - either by the user, or at install time (which I do not believe is an option) - it won’t be able to copy files into vim’s install directory, so here you’d be back to $HOME/config/settings/vim
Unless this is a more massive collection than I imagine, I think the separate package is overkill. I guess that leaves you shipping the vim files in your package’s data, and just notifying users where it is if they want it - I think that’s easier for them than being notified they have to go get another package anyway.
A package is like a read-only union filesystem. My picture of what waddlesplash was proposing, that your filesystem and vim’s could both have /data/vim directories, and both packages’ files would appear there, if both were installed; if vim weren’t installed, yours would be alone there, and vice versa. But that’s awkward because the directory depends on the installed vim version. You can’t go in after the fact because they’re read-only, and anyway that would fall apart at the next vim upgrade.
As far as I can see (from “:help vimruntime” and “:version”), the versionned vimruntime is not mandatory. If it does not exist, vim will look in /system/data/vim/runtime instead. So, maybe we could change the way we package vim to use that instead, if it makes things simpler.
This is what I did at the end of the day. It will work until we will stay on the vim8.2 branch.
+1 to repackage vim . But we must put extreme care here I guess. Vim is installed in almost every Haiku installation all around the world. Repackage it will break apart the systems were the users have customized the content of the versioned runtime dir I guess.
…and I’m happy that a so trivial question about a vim addon for a very exotic language generated a so intense debate
Can somebody explain why would anyone package vim plugins?There are vim plugin managers, they can solve the problem.
Packaging won’t actually help to “Regular Joe”, because “Regular Joe” would use StyleEdit instead and the users who uses vim and want to pimp it, knows already where to go to install/remove/change plugins (eg. vim help screen lists the used folders and their paths).
Can maybe understand for extensive plugins like YCM, but in this case would be also nicer to upstream the Haiku related patches so every brave sould could just install it with his favorite vim plugin manager.
I see no point in this but i don’t use vim, so maybe i missed some important aspects.
Ofc, vim is not for the regular user. And ofc, the syntax for 65** assembly is not for the regular user. But this is only incidental.
Relying on the user on manually copy the so-called plugins made available on a package subpath to the proper directories is a valid choice. But it must be documented (in the description?).
It could be the Regular Joe or Jeff Minter, but two linex explaining the procedure should be provided. Let alone to find standard place to put those files for the users to pick them up. This is going to be a subjective task, for the porter, if there’s no a common, defined, way to do so.
For what it’s worth, vi has been all I’ve every used on BeOS and Haiku for the last couple decades and then some, and I do fiddle with the vim configuration files (colors on black background need bold fonts to be visible) - but I have never heard of a vim plugin manager. My point being that support for vim is really support for an editor that has been around for half a century, long before vim (which itself has been around for a long time.) Users will typically have learned enough about this particular implementation to serve their purposes, but they’re really here to edit assembly language files or whatever, which may turn out quite well without plugin managers.
Mmmm… I’m planning on moving to Vim as can be the same interface and settings on Silverblue as well as on Haiku. Besides, Vim already has GDScript sintax highlight available, which allows to code Godot scripts on Haiku, but I found that Vim for Haiku is not compiled with python, which seems to be a requirement for the GDScript autocompletion, … fixing means that too??
I might have said something wrong though. Just starting with Vim.