Loading ...
Sorry, an error occurred while loading the content.

Re: Time to remove naming restrictions?

Expand Messages
  • Nikolai Weibull
    ... As in what? That :quit always works as documented? Sure, that s great, but if that s the problem, the restriction should be limited to commands already
    Message 1 of 11 , Oct 2, 2006
    • 0 Attachment
      On 10/1/06, Bram Moolenaar <Bram@...> wrote:
      >
      > Nikolai Weibull wrote:
      >
      > > One thing that really annoys me with Vim is the limits it emposes on
      > > what names are legal for user-defined functions and commands. I know
      > > the reason for these restrictions, but I don't think they make much
      > > sense, especially so for user-defined commands. I realize that
      > > overriding :quit does have its implications, but done carefully, this
      > > does allow for some interesting effects.
      > >
      > > So, why not lift the restrictions on valid names for user-defined
      > > functions and commands?
      > >
      > > That is, give me good reasons for why they should be maintained and
      > > I'll drop this request.
      >
      > Predictability.

      As in what? That :quit always works as documented? Sure, that's
      great, but if that's the problem, the restriction should be limited to
      commands already defined. And what happens when more commands are
      added? Hell, then they'll break the user-defined commands with the
      same name. Big deal; that's life, you'll get over it - everyone does,
      eventually.

      I really don't see the big difference between user-defined commands
      clashing with built-in commands and user-defined commands clashing
      with each other. It'll happen; unless you start adding prefixes or
      namespaces or some other way of separating your commands. But then
      you lose out on simplicity. You don't want to type :NOWCommand (given
      that "NOW" is "my" prefix), and I don't want to type :Command; I want
      to type :command.

      Sure, it only saves my fingers from giving up on me for so long, but
      every little bit helps.

      I guess my problem is that I want - and I've always wanted - the
      flexibility of Emacs coupled with the simplicity and efficiency of
      Vim's command set and modes. I guess that's why I nitpick at things
      such as this.

      nikolai
    • A.J.Mechelynck
      ... and then you ll wonder why you can t define a new user-command but it s your funeral. It s still not perfect though; the cabbrev will be expanded even if
      Message 2 of 11 , Oct 3, 2006
      • 0 Attachment
        Nikolai Weibull wrote:
        > On 10/1/06, Bram Moolenaar <Bram@...> wrote:
        >>
        >> Nikolai Weibull wrote:
        >>
        >> > One thing that really annoys me with Vim is the limits it emposes on
        >> > what names are legal for user-defined functions and commands. I know
        >> > the reason for these restrictions, but I don't think they make much
        >> > sense, especially so for user-defined commands. I realize that
        >> > overriding :quit does have its implications, but done carefully, this
        >> > does allow for some interesting effects.
        >> >
        >> > So, why not lift the restrictions on valid names for user-defined
        >> > functions and commands?
        >> >
        >> > That is, give me good reasons for why they should be maintained and
        >> > I'll drop this request.
        >>
        >> Predictability.
        >
        > As in what? That :quit always works as documented? Sure, that's
        > great, but if that's the problem, the restriction should be limited to
        > commands already defined. And what happens when more commands are
        > added? Hell, then they'll break the user-defined commands with the
        > same name. Big deal; that's life, you'll get over it - everyone does,
        > eventually.
        >
        > I really don't see the big difference between user-defined commands
        > clashing with built-in commands and user-defined commands clashing
        > with each other. It'll happen; unless you start adding prefixes or
        > namespaces or some other way of separating your commands. But then
        > you lose out on simplicity. You don't want to type :NOWCommand (given
        > that "NOW" is "my" prefix), and I don't want to type :Command; I want
        > to type :command.
        >
        > Sure, it only saves my fingers from giving up on me for so long, but
        > every little bit helps.
        >
        > I guess my problem is that I want - and I've always wanted - the
        > flexibility of Emacs coupled with the simplicity and efficiency of
        > Vim's command set and modes. I guess that's why I nitpick at things
        > such as this.
        >
        > nikolai
        >

        :command -bar Command ...
        :cabbrev command Command

        and then you'll wonder why you can't define a new user-command but it's your
        funeral.

        It's still not perfect though; the cabbrev will be expanded even if it's not
        at the start (but that may be not-so-bad if you use ":verbose command",
        ":vertical command", etc.)


        Best regards,
        Tony.
      • Yakov Lerner
        ... You can (via source); cabbrev don t affect sourced scritps. Yakov
        Message 3 of 11 , Oct 3, 2006
        • 0 Attachment
          On 10/3/06, A.J.Mechelynck <antoine.mechelynck@...> wrote:
          > Nikolai Weibull wrote:
          > > On 10/1/06, Bram Moolenaar <Bram@...> wrote:
          > >>
          > >> Nikolai Weibull wrote:
          > >>
          > >> > One thing that really annoys me with Vim is the limits it emposes on
          > >> > what names are legal for user-defined functions and commands. I know
          > >> > the reason for these restrictions, but I don't think they make much
          > >> > sense, especially so for user-defined commands. I realize that
          > >> > overriding :quit does have its implications, but done carefully, this
          > >> > does allow for some interesting effects.
          > >> >
          > >> > So, why not lift the restrictions on valid names for user-defined
          > >> > functions and commands?
          > >> >
          > >> > That is, give me good reasons for why they should be maintained and
          > >> > I'll drop this request.
          > >>
          > >> Predictability.
          > >
          > > As in what? That :quit always works as documented? Sure, that's
          > > great, but if that's the problem, the restriction should be limited to
          > > commands already defined. And what happens when more commands are
          > > added? Hell, then they'll break the user-defined commands with the
          > > same name. Big deal; that's life, you'll get over it - everyone does,
          > > eventually.
          > >
          > > I really don't see the big difference between user-defined commands
          > > clashing with built-in commands and user-defined commands clashing
          > > with each other. It'll happen; unless you start adding prefixes or
          > > namespaces or some other way of separating your commands. But then
          > > you lose out on simplicity. You don't want to type :NOWCommand (given
          > > that "NOW" is "my" prefix), and I don't want to type :Command; I want
          > > to type :command.
          > >
          > > Sure, it only saves my fingers from giving up on me for so long, but
          > > every little bit helps.
          > >
          > > I guess my problem is that I want - and I've always wanted - the
          > > flexibility of Emacs coupled with the simplicity and efficiency of
          > > Vim's command set and modes. I guess that's why I nitpick at things
          > > such as this.
          > >
          > > nikolai
          > >
          >
          > :command -bar Command ...
          > :cabbrev command Command
          >
          > and then you'll wonder why you can't define a new user-command but it's your
          > funeral.

          You can (via source); cabbrev don't affect sourced scritps.

          Yakov
        • Nikolai Weibull
          ... ;-) It s a solution, but it s not great; still, better than nothing. nikolai
          Message 4 of 11 , Oct 3, 2006
          • 0 Attachment
            On 10/3/06, A.J.Mechelynck <antoine.mechelynck@...> wrote:

            > :command -bar Command ...
            > :cabbrev command Command
            >
            > and then you'll wonder why you can't define a new user-command but it's your
            > funeral.

            ;-)

            It's a solution, but it's not great; still, better than nothing.

            nikolai
          • Hari Krishna Dara
            ... You can use the Vim7 abbreviation in combination of getcmdpos() and getcmdtype() to make this a lot more reliable, and avoid expanding everywhere. I
            Message 5 of 11 , Oct 3, 2006
            • 0 Attachment
              On Tue, 3 Oct 2006 at 10:30am, A.J.Mechelynck wrote:

              > Nikolai Weibull wrote:
              > > On 10/1/06, Bram Moolenaar <Bram@...> wrote:
              > >>
              > >> Nikolai Weibull wrote:
              > >>
              > >> > One thing that really annoys me with Vim is the limits it emposes on
              > >> > what names are legal for user-defined functions and commands. I know
              > >> > the reason for these restrictions, but I don't think they make much
              > >> > sense, especially so for user-defined commands. I realize that
              > >> > overriding :quit does have its implications, but done carefully, this
              > >> > does allow for some interesting effects.
              > >> >
              > >> > So, why not lift the restrictions on valid names for user-defined
              > >> > functions and commands?
              > >> >
              > >> > That is, give me good reasons for why they should be maintained and
              > >> > I'll drop this request.
              > >>
              > >> Predictability.
              > >
              > > As in what? That :quit always works as documented? Sure, that's
              > > great, but if that's the problem, the restriction should be limited to
              > > commands already defined. And what happens when more commands are
              > > added? Hell, then they'll break the user-defined commands with the
              > > same name. Big deal; that's life, you'll get over it - everyone does,
              > > eventually.
              > >
              > > I really don't see the big difference between user-defined commands
              > > clashing with built-in commands and user-defined commands clashing
              > > with each other. It'll happen; unless you start adding prefixes or
              > > namespaces or some other way of separating your commands. But then
              > > you lose out on simplicity. You don't want to type :NOWCommand (given
              > > that "NOW" is "my" prefix), and I don't want to type :Command; I want
              > > to type :command.
              > >
              > > Sure, it only saves my fingers from giving up on me for so long, but
              > > every little bit helps.
              > >
              > > I guess my problem is that I want - and I've always wanted - the
              > > flexibility of Emacs coupled with the simplicity and efficiency of
              > > Vim's command set and modes. I guess that's why I nitpick at things
              > > such as this.
              > >
              > > nikolai
              > >
              >
              > :command -bar Command ...
              > :cabbrev command Command
              >
              > and then you'll wonder why you can't define a new user-command but it's your
              > funeral.
              >
              > It's still not perfect though; the cabbrev will be expanded even if it's not
              > at the start (but that may be not-so-bad if you use ":verbose command",
              > ":vertical command", etc.)
              >
              >
              > Best regards,
              > Tony.

              You can use the Vim7 <expr> abbreviation in combination of getcmdpos()
              and getcmdtype() to make this a lot more reliable, and avoid expanding
              everywhere. I have created the cmdalias.vim plugin
              (http://www.vim.org/script.php?script_id=745) just to address this
              problem (as it bothered me as well). The only case this breaks is the
              debug mode because of a bug in Vim (the expression itself is executed in
              the debug mode).

              Another oddity in using this approach is the history. If you execute:

              :command

              what will end up getting stored in the history is:

              :Command

              which means you have to remember to use the righ case while retrieving
              the last command (:com<Up> will not work).

              --
              HTH,
              Hari

              __________________________________________________
              Do You Yahoo!?
              Tired of spam? Yahoo! Mail has the best spam protection around
              http://mail.yahoo.com
            • Nikolai Weibull
              ... Argh. This is exactly why all the hacks one has to employ never really quite make it. There s always some base you haven t covered, some point you can t
              Message 6 of 11 , Oct 3, 2006
              • 0 Attachment
                On 10/3/06, Hari Krishna Dara <hari_vim@...> wrote:

                > Nikolai Weibull wrote:

                > > One thing that really annoys me with Vim is the limits it emposes on
                > > what names are legal for user-defined functions and commands.

                > Another oddity in using this approach is the history. If you execute:
                >
                > :command
                >
                > what will end up getting stored in the history is:
                >
                > :Command
                >
                > which means you have to remember to use the righ case while retrieving
                > the last command (:com<Up> will not work).

                Argh. This is exactly why all the hacks one has to employ never
                really quite make it. There's always some base you haven't covered,
                some point you can't reach.

                Seriously, if people want to f**k up their session, let them. No one
                who isn't prepared to get burned is going to override :quit. No one
                who isn't prepared for an unpredictable future (is there a second
                kind?) is going to install a plugin that adds a command called :vfold.
                Let us who really want our Vim to be what we want it to be have the
                tools to make it so. I'm obviously not the only person who feels this
                way. And I haven't even spent time writing a plugin to circumvent
                this, like Hari has.

                nikolai
              • Peter Hodge
                ... There s about 4 lines of vim source code which you need to remove so that you can have lower-case user commands. You re not interested in making your own
                Message 7 of 11 , Oct 3, 2006
                • 0 Attachment
                  > Argh. This is exactly why all the hacks one has to employ never
                  > really quite make it. There's always some base you haven't covered,
                  > some point you can't reach.
                  >
                  > Seriously, if people want to f**k up their session, let them. No one
                  > who isn't prepared to get burned is going to override :quit. No one
                  > who isn't prepared for an unpredictable future (is there a second
                  > kind?) is going to install a plugin that adds a command called :vfold.
                  > Let us who really want our Vim to be what we want it to be have the
                  > tools to make it so. I'm obviously not the only person who feels this
                  > way. And I haven't even spent time writing a plugin to circumvent
                  > this, like Hari has.

                  There's about 4 lines of vim source code which you need to remove so that you
                  can have lower-case user commands. You're not interested in making your own
                  patch?

                  regards,
                  Peter







                  ____________________________________________________
                  On Yahoo!7
                  Messenger - IM with Windows Live™ Messenger friends.
                  http://au.messenger.yahoo.com
                • Nikolai Weibull
                  ... Seeing as you ve identified the location and apparent fix, why not you? Anyway, I felt there was no need to provide a patch before a we had discussion on
                  Message 8 of 11 , Oct 4, 2006
                  • 0 Attachment
                    On 10/4/06, Peter Hodge <toomuchphp-vimdev@...> wrote:

                    > There's about 4 lines of vim source code which you need to remove so that you
                    > can have lower-case user commands. You're not interested in making your own
                    > patch?

                    Seeing as you've identified the location and apparent fix, why not you?

                    Anyway, I felt there was no need to provide a patch before a we had
                    discussion on the merit (or acceptance) of such a patch.

                    nikolai
                  • Peter Hodge
                    ... Because I don t want to maintain my own set of patches, that would be more tiring than using upper-case commands.
                    Message 9 of 11 , Oct 4, 2006
                    • 0 Attachment
                      >
                      > Seeing as you've identified the location and apparent fix, why not you?
                      >

                      Because I don't want to maintain my own set of patches, that would be more
                      tiring than using upper-case commands.






                      ____________________________________________________
                      On Yahoo!7
                      Messenger - IM with Windows Live™ Messenger friends.
                      http://au.messenger.yahoo.com
                    Your message has been successfully submitted and would be delivered to recipients shortly.