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

Re: Time to remove naming restrictions?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.