Subject: Re: bug#8754: submission of vimvars

From: Stefan Monnier <[email-masked]>
Date: Wed, 06 Jul 2011 09:12:35 -0400

> Sorry, I'm attaching the patch instead of sending it inline, contrary
> to the contribution guidelines, but I'll include the commit message
> inline.  Google already has an FSF copyright assignment for Emacs;
> fwiw, so do I.   Feedback on the right place in the manual to document
> this would be particularly welcome, since I wasn't certain which the
> optimal spot was.

This looks like an interesting feature, thanks.
I think we should add it to the GNU ELPA, does that sound goo to you?

- There's some redundancy between vimvars-enabled and (memq
  'vimvars-obey-vim-modeline find-file-hook), I think the user should
  only have to use one of the two.
- if vimvars-enabled stays, it should be renamed vimvars-mode and be
  made into a minor-mode.
- vimvars-enabled being buffer-local seems odd.  What was the motivation
  for it?
- if the user has to add vimvars-obey-vim-modeline to the hook, then add
  an autoload cookie before it so that the user does not need to
  (require 'vimvars).
-
    (if file-local-variables-alist
        (not vimvars-ignore-mode-line-if-local-variables-exist)
      t)))
  =>
    (or (not file-local-variables-alist)
        (not vimvars-ignore-mode-line-if-local-variables-exist))
  =>
    (not (and file-local-variables-alist
              vimvars-ignore-mode-line-if-local-variables-exist))
- next time someone adds support for shiftwidth in some other modes
  (e.g. by setting smie-basic-indent), he'll probably forget to update
  the doc, so better keep the doc less specific to the current limits.
- (equal major-mode 'c-mode)  =>  (derived-mode-p 'c-mode).
- you set compile-command globally.
- if we add it to the GNU ELPA rather than to Emacs itself, then the doc
  needs to be moved to the Commentary section.

        Stefan