On sourcing lispwords from multiple locations

[iamFIREcracker]

Recently (commit: 6c30648) lispindent was changed so that it would not apply some default indenting rules anymore, and that basically forced users to add all these now-missing indentation rules back into their .lispwords (or otherwise indented files would look different than before).

That led me to the following two questions:

• Was this side-effect (i.e. the fact that now all the users will have to update their .lispwords), intentional or more of an oversight?
• And if that was intentional (i.e. we don't want the tool to enforce any rule, users should be responsible for defining all the indentation rules), then what can be done to make it a little bit easier for users to manage this additional complexity?

In particular, I was thinking lispindent could try and read lispwords files from different locations, in this specified order:

• ./.lispwords: this is where users would define project-specific rules
• ~/.lispwords (or file located at the value of LISPINDENT environment variable): this is where users would try to override some default rules (maybe not applicable anymore, if by design you don't want lispindent to apply any defaults), or simply try to define some sane defaults for themselves

I could see why one could be against this proposed change of behavior (especially when collaborating with others, relying on a .lispwords file sitting on someone's home directory might not be a good idea), and to be honest, I am not 100% sold on the idea myself; however, I am looking for a way not to repeat the same indentation rules over and over again, in all of my projects' .lispwords, and sourcing from the home, and the current working directory, was the best thing I could come up with.

Let me know your thoughts.

Edit:

• Previously I said lispindent should load .lispwords from the home directory first, and then from the current working directory, but clearly that would not work as expected.

[iamFIREcracker]

FYI, I have I have tried to implement the above (i.e. try to load from the current directory first, then try home/LISPWORDS env variable): iamFIREcracker@88366a8

[ds26gte]

Project-specific .lispwords seem problematic to me: If you place the .lispwords in the project's root directory, then you're constrained to always start Vim in the project's root dir (and maybe never use 'autochdir', :cd, :lcd), even if the Lisp file you're editing is embedded deep in a subdirectory. Otherwise, you must take care to litter every relevant subdir with a copy of the .lispwords. Is it not easier to set LISPWORDS temporarily while working on a project? E.g., having your Vim call expand to something like LISPWORDS=relevant_lispwords_file vim?

It was indeed intentional to not hardwire the lispwords into the indenter itself: I can't presume to know what the user's preferred lispwords are. Previously, I had had the Common Lisp version have a different hardwired lispwords from the Scheme version, but really the two indenters should be interchangeable. Also, the user may be using some other Lisp entirely.

Ideally, then, the indenter should be able to query the 'lispwords' Vim option, and leave it to the user to specify this differently for various filetypes or projects or both, in whatever way they want. It is no longer the indenter's job to worry about this.

https://github.com/ds26gte/neoscmindent does this seamlessly: it reads the local 'lispwords' correctly. But this would require you to use Neovim, which you may not want or be able to.

[iamFIREcracker]

Project-specific .lispwords seem problematic to me: If you place the .lispwords in the project's root directory, then you're constrained to always start Vim in the project's root dir (and maybe never use 'autochdir', :cd, :lcd), even if the Lisp file you're editing is embedded deep in a subdirectory.

Maybe... we have lispindent try to process .lispwords files as follows:

• Use LISPWORDS if set, or
• ./.lispwords, or
• ../.lispwords, or
• ../../.lispwords... until it finds the first file it can read

I know, it might sound a bit overkill, but that's how many other text-formatters/editor tools (and not) work (e.g. prettier, editor-config, git), so maybe it's not a bad idea to have lispindent behave similarly after all.

Is it not easier to set LISPWORDS temporarily while working on a project? E.g., having your Vim call expand to something like LISPWORDS=relevant_lispwords_file vim?

That's exactly how I have been dealing with this so far:

        if filereadable('.lispwords')
            let $LISPWORDS='./.lispwords'
        endif

Like I said, the only problem I was having with this was it that it was hard to split LINs definitions across different files (general/project specific rules) and have lispindent load them all, but the more I think about it, the more I tend to agree that having a single .lispwords file is probably the right thing to do (especially when collaborating with others).

Previously, I had had the Common Lisp version have a different hardwired lispwords from the Scheme version, but really the two indenters should be interchangeable. Also, the user may be using some other Lisp entirely.

I 100% agree, the indenters in this repository should all behave the same, and be programming language agnostic; and if we wanted such indenters to provide some sane defaults, there should at least be a way to:

1. Specify the programming-language (so we can configure the hardwired set of defaults)
2. Disable such defaults

It seems like a lot of work, for not much gain, so I guess sticking with a single project-specific .lispwords file, containing all the LIN rules will do just fine for now.

Ideally, then, the indenter should be able to query the 'lispwords' Vim option, and leave it to the user to specify this differently for various filetypes or projects or both, in whatever way they want. It is no longer the indenter's job to worry about this.

Well, to be honest I think it should be the other way around:

• you have an external formatter, lispindent, that can be used by people using different editors/IDEs
• then you have editor-specific plugins responsible for integrating with the external formatter (e.g. for Vim, such plugin would set equalprg=lispindent as well as set lispwords=... based on the configured .lispwords file).

[iamFIREcracker]

FYI, the last commit in my fork (iamFIREcracker@24747d2), adds support for automatically loading .lispwords from the current directory, its parent, its parent parent... until it gets past the user home directory.

[ThatGeoGuy]

I'd also love this. One suggestion though: instead of looking at successively higher and higher directories until a .lispwords is found, how about just searching for VCS root directories instead?

This is how many tools work with e.g. Git or other VCS and look for configuration files.