unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: James Youngman <youngman@google.com>
Cc: 8754@debbugs.gnu.org
Subject: bug#8754: submission of vimvars
Date: Wed, 06 Jul 2011 12:34:32 -0400	[thread overview]
Message-ID: <jwvoc17s7ib.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CA+1ReD-cB4bRuSDay6nzsVZ5MCSEqsqWhvC9JHkRgKS+212nGQ@mail.gmail.com> (James Youngman's message of "Wed, 6 Jul 2011 15:22:33 +0100")

>> > 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?

> I'm not opposed, but it is not my ideal choice for a small number of reasons:
> 1. It interacts a bit with Emacs' own local variables in order to
> avoid surprising behaviour, and my guess was that it may make sense to
> put the code in the same repo as the code interpreting Emacs' own
> local variables.
> 2. I wanted to make sure this was adequately documented in the same
> place as the Emacs' various VI emulations, since people wanting to use
> a VI emulation stand a high chance of finding this useful too.

The problem is that we entered feature freeze for Emacs-24.1 a week ago,
and I don't think this is high-enough priority to overrule it.  We can
reconsider it for Emacs-24.2 (at which point we may also reconsider the
way it hooks into Emacs: we could probably make it more robust by
hooking into hack-local-variables instead, tho this may currently lack
the necessary hooks).

>> - 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.

> I had to make some assumptions about user preferences, and I guessed
> that someone might want to leave vimvars-obey-vim-modeline in
> find-file-hook and yet disable vimvars for specific projects via
> .dir-locals.el.

That makes sense (but see below).  Note that as long as vimvars-enabled
is nil (add-hook 'find-file-hook 'vimvars-obey-vim-modeline) is
harmless, so you could arrange to add the hook eagerly (e.g. default
vimvars-enabled to nil and add the hook unconditionally), so the user
only has to deal with vimvars-enabled.

>> - 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?

You don't need to call make-variable-buffer-local for dir-locals to work.
make-variable-buffer-local basically says "this will only ever be set
buffer-locally", which is not right, here.  Just remove it and things
will keep working fine.


        Stefan





  reply	other threads:[~2011-07-06 16:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BANLkTikYHe-dgUUbv1ZW+HNF4AvO9fNB8g@mail.gmail.com>
2011-05-28 22:39 ` bug#8754: submission of vimvars James Youngman
2011-05-29  8:25   ` Štěpán Němec
2011-06-14 16:27     ` James Youngman
2011-05-29 17:21   ` Nix
2011-05-29 18:05     ` James Youngman
2011-06-14 16:11   ` James Youngman
2011-07-06 13:12   ` Stefan Monnier
2011-07-06 14:22     ` James Youngman
2011-07-06 16:34       ` Stefan Monnier [this message]
2011-07-06 16:50         ` James Youngman
2012-04-12 19:33           ` Lars Magne Ingebrigtsen
2016-02-25  6:57             ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvoc17s7ib.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=8754@debbugs.gnu.org \
    --cc=youngman@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).