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

Re: Time to remove naming restrictions?

Expand Messages
  • Bram Moolenaar
    ... Predictability. -- Are leaders born or made? And if they re made, can we return them under warranty? (Scott Adams - The Dilbert principle) /// Bram
    Message 1 of 11 , Oct 1, 2006
      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.

      --
      Are leaders born or made? And if they're made, can we return them under
      warranty?
      (Scott Adams - The Dilbert principle)

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
    • 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 2 of 11 , Oct 2, 2006
        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 3 of 11 , Oct 3, 2006
          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 4 of 11 , Oct 3, 2006
            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 5 of 11 , Oct 3, 2006
              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 6 of 11 , Oct 3, 2006
                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 7 of 11 , Oct 3, 2006
                  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 8 of 11 , Oct 3, 2006
                    > 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 9 of 11 , Oct 4, 2006
                      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 10 of 11 , Oct 4, 2006
                        >
                        > 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.