[neomutt-devel] Config file search locations

[Guillaume Brogi]

A bit of context for those on the dev-list:
I'm cleaning up and trying to get the neomutt syntax files for vim
merged into vim/neovim. But first, we need to figure out how to get it
merged and what we put into the file.

> > So, I've been told to do everything on the vim-dev mailing list.
> 
> OK.  See if you can find out:
> * How long it takes patch on the list to merging?
> * Do they mind frequent small updates?
> * Or should we sort out everything first?
> 
There are frequent patches to the runtime files, but I'll make sure to
ask.

> > I have a patch. I'll send it here
> 
> Is it OK if we move this conversation to the dev-list?
> 
Done.

> > before submitting it to vim, so that I you guys can comment on it.
> 
> Great
> 
Depending on how they want to the patch, I may add a fork of vim to
neomutt's github. I don't know if we can just supply the vim syntax file
or if we need to add all the bufenters, etc... The patch I am preparing
has everything, but I think we only need it once so we should be fine
with having the syntax file inside the main repo after that.

> > ... syntax file so that it works and extends the muttrc syntax ...
> 
> I've been wondering about that.  Should we:
> 
> 1) Write an extension to mutt's syntax file?
>    Tidy, but requires us to keep checking what mutt supports
> 
It shows that we are simply an extension to mutt.

> 2) Write a pure neomutt syntax file?
>    We can potentially script parts of it by reading our code
> 
> If we work towards a scripted solution, we would have to write out the
> syntax longhand
>     sidebar-next|sidebar-prev
> rather than
>     sidebar-{next,prev}
> As the config files are never going to be *that* big, I don't think this
> would be a problem.
> 
Scripting would definitely be a plus. I don't think the longhand syntax
will be a problem (except if vim-dev decides it is).
Another upside of having our own whole file is that in the case where we
diverge on keywords (hopefully never, but who knows...), then it's just
business as usual. Otherwise, we would have to make a larger rewrite.

> > I realised there are quite a few keywords that are not in
> > either syntax files
> 
> The latest file seems to be for 1.7.0:
>     https://github.com/vim/vim/blob/master/runtime/syntax/muttrc.vim
> It might be worth asking the maintainer:
>     Kyle Wheeler <kyle-muttrc.vim at memoryhole.net>
> 
If we have our own file, we don't need to.

> > There are keywords that are ours, and keywords from mutt
> 
> Anything in doubt stick in our file.
> 
Ok. That's what I thought too.

> > (I would take the role of maintaining the syntax file and
> > checking it regularly, say after each release)
> 
> Thanks
> 
Hopefully, the burden won't be too heavy ^^

> > The other solution is to track what is in the pipe for mutt
> 
> Seeing as they do their dev discussion in secret, who knows.
> (another vote for our own syntax file :-)
> 
Yeah...

> > Keywords (grep'ed init.h and both syntax files, may need cleaning up)
> 
> I've put my WIP syntax files, here:
>     https://github.com/neomutt/flatcap-vim
> 
> They're curated by hand, up-to-date and split by syntax type.
> The .vim files are what I imagined a script would generate.
> If there's anything you can use, great.  If not, I'll delete the repo
> next week.
> 

I'll check it out!

All in all, I was all for extending the mutt syntax, but now I think our
own file would be better. It's really only a change the first time, and
that way we can make sure it is up to date.
As for scripting the generation, that would be the most convenient to
keep up to date, but that means the script must understand what is a
function, keyword, option, ... Maybe we can do it by parsing the AST of
init.h? Other ideas?

-- 
guiniol
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.neomutt.org/pipermail/neomutt-devel-neomutt.org/attachments/20170916/c0ca9b61/attachment.sig>