« first day (2185 days earlier)      last day (1183 days later) » 

3:56 PM
I'm using nixos, but I can't get my elm stuff to work when using a .elm file. Here's my config. I've chased down what Nix does and I think it's right, but it only works when I use startand not when I use opt.
mkShell {
buildInputs = [
  ((vim_configurable.override {python = python38;}).customize {
    name = "vim";
    vimrcConfig.customRC = ''
      syntax on
      filetype on
      set relativenumber
      set number
      set shiftwidth=4 expandtab
      set hidden
      set ruler
      set colorcolumn=80
      set backspace=indent,eol,start
      let g:elm_format_autosave = 1
      autocmd FileType elm :packadd elm-vim
      autocmd FileType nix :packadd vim-nix
    '';
    vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
An answer here seems to address the issue:
> The examples you give hint that what you're actually trying to do is load a vim8 optional package from an autocmd, which is a slightly different question.

The reason they don't work is most likely because you're already processing a FileType event at that point, and the plugin you're loading will register new autocmds for that same event, but those will most probably not be triggered for that same event you're already handling. Maybe you could hack something together using doautocmd to process those commands again, but I really don't think that would be worth it.
But I'm not finding a lot of corroborating information.
 
 
2 hours later…
5:46 PM
Neither plugin do much when the filetype isn't elm or nix. I don't see the point to not always add their install paths to the 'runtimepath'. Sourcing files on the fly when the filetype matches is already what ftplugin do. And these "plugins" are mostly made of ftplugins and autoload plugins. They both have a plugins (file) that define just a few convenience mappings.
 
 
3 hours later…
8:26 PM
@LucHermitte I'd like to tell Nixos to change their code comments/wiki on the subject, but I'd like to be able to point at a document (if only source code, but where?) before doing so.
Can you link me to it?
 
8:48 PM
I don't know what to say. There are a lot of people that want to load "plugins" on the fly. Yet, a well written plugin don't really need special attention as ft-specific stuff would go into ftplugins (file), and functions would do into autoload plugin (file), and we won't have any into plugin (files).

Yet.
- On some systems, the more plugins we have, the bigger 'runtimepath' is and the more file access it can cause. On those systems, we don't like long list of paths (PATH, LD_LIBRARY_PATH... and somehow runtimepath). This means, it's better to not necessarily activate all "plugins" (suite)
Note: when a plugin is well written, understand that their activation (through plugin manager, or :packadd) just changes the 'runtimepath' option, and it does not trigger the sourcing of any files of mismatching type.
 
9:12 PM
IDK why, but I can't manually load the plugin with packadd when it's in opt - it only loads in start.
I don't know if I have enough to make a change, but I'll try.
 

« first day (2185 days earlier)      last day (1183 days later) »