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

f:var, what was the final word?

Expand Messages
  • Zdenek Sekera
    Some time ago I have raised a question of adding a new variable type f:var related to the filetype. Bram/Peppe suggested workarounds that are usable on
    Message 1 of 26 , Jan 2, 2001
    • 0 Attachment
      Some time ago I have raised a question of adding a new variable
      type f:var related to the filetype. Bram/Peppe suggested workarounds
      that are usable on occassions but worsen the code readability
      real fast and add to the processing speed, natuarlly.

      I have a clear case for f:var, during a setup for
      something I need to go through an init process for the &ft, when
      done values are valid for all buffers of the same ft. Init is quite
      lengthy. The f:vars would be just perfect for it. For now I use
      b:vars, thus repeating init for all buffers, very wasty.

      I don't remember what was the the *final* (??) word on that issue,
      hence my question: is it planned (soon) or should I stay with
      my b: approach?

      Actually, there are so many things in vim tied to &ft that it is
      almost surprising IMHO that we don't have the f: yet...seems kind
      of natural to have it.

      ---Zdenek
    • Bram Moolenaar
      ... If your inits are in one sourced file, you can use s:var. Otherwise you can use global variables with some unique name. If there are many you could use a
      Message 2 of 26 , Jan 2, 2001
      • 0 Attachment
        Zdenek Sekera wrote:

        > Some time ago I have raised a question of adding a new variable
        > type f:var related to the filetype. Bram/Peppe suggested workarounds
        > that are usable on occassions but worsen the code readability
        > real fast and add to the processing speed, natuarlly.
        >
        > I have a clear case for f:var, during a setup for
        > something I need to go through an init process for the &ft, when
        > done values are valid for all buffers of the same ft. Init is quite
        > lengthy. The f:vars would be just perfect for it. For now I use
        > b:vars, thus repeating init for all buffers, very wasty.

        If your inits are in one sourced file, you can use s:var. Otherwise you can
        use global variables with some unique name. If there are many you could use a
        function that returns the desired value.

        > I don't remember what was the the *final* (??) word on that issue,
        > hence my question: is it planned (soon) or should I stay with
        > my b: approach?

        I'm not planning to add it. f:var has limited general use. So far you are
        the only one that mentioned it, and you do have alternative ways to do what
        you want. Introducing f:var would make your scripts simpler and Vim more
        complicated.

        > Actually, there are so many things in vim tied to &ft that it is
        > almost surprising IMHO that we don't have the f: yet...seems kind
        > of natural to have it.

        I don't see many things tight to a 'filetype'. In the syntax file you can use
        "s:var", for example. Most other things are global anyway (you need to be
        able to access them when 'filetype' is different too).

        --
        hundred-and-one symptoms of being an internet addict:
        185. You order fast food over the Internet

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
      • Zdenek Sekera
        ... No, they must survive the script and be used by other buffers of the same &ft. That s the whole point. ... Yes, but that slows down processing (I don t
        Message 3 of 26 , Jan 3, 2001
        • 0 Attachment
          Bram Moolenaar wrote:
          >
          ...
          > If your inits are in one sourced file, you can use s:var.

          No, they must survive the script and be used by other buffers of the
          same &ft.
          That's the whole point.

          > Otherwise you can
          > use global variables with some unique name. If there are many you could use a
          > function that returns the desired value.

          Yes, but that slows down processing (I don't know how much) and worsens
          a *lot*
          the code readability (= maintainability).
          >
          ...
          > I'm not planning to add it. f:var has limited general use. So far you are
          > the only one that mentioned it,

          Your call, but it's only a matter of time...Any bets?

          > and you do have alternative ways to do what
          > you want.

          It can hardly be said that in every case an existing alternative way
          is neccessarily a good solution. In those cases the *workaround* may be
          more satisfactory decription. And yes, we all do use workarounds in this
          business all the day every day, nothing new.

          > Introducing f:var would make your scripts simpler and Vim more
          > complicated.

          Oh yes, for sure, but isn't it what everyone is striving for? Make a
          tool
          the easiest on the user level? I am surprised that you, of all people,
          who
          really goes after the *user level* simplicity, mentions that.

          ...
          >
          > I don't see many things tight to a 'filetype'. In the syntax file you can use
          > "s:var", for example. Most other things are global anyway (you need to be
          > able to access them when 'filetype' is different too).

          And what about very powerful FileType event in autocmd? And indent? And
          others?
          And they are all very useful for certain things. Even if very rarely
          everyone
          of those is used by everyone everyday...

          Your call, no bad feelings.

          ---Zdenek
        • Bram Moolenaar
          ... The value of s:var is kept when the script finishes. You can use it again the next time the same script is sourced. s:var is static , in C terms. This
          Message 4 of 26 , Jan 3, 2001
          • 0 Attachment
            Zdenek Sekera wrote:

            > > If your inits are in one sourced file, you can use s:var.
            >
            > No, they must survive the script and be used by other buffers of the
            > same &ft.
            > That's the whole point.

            The value of s:var is kept when the script finishes. You can use it again the
            next time the same script is sourced. s:var is "static", in C terms. This
            changed some time ago.

            > > Otherwise you can use global variables with some unique name. If there
            > > are many you could use a function that returns the desired value.
            >
            > Yes, but that slows down processing (I don't know how much) and worsens a
            > *lot* the code readability (= maintainability).

            let f:var = "value"
            can be
            let g:ft_var = "value"
            or
            call MyFTSet("var", "value")

            It's not _that_ bad. Of course the first one is shorter, but it requires a
            fatter Vim.

            > > and you do have alternative ways to do what you want.
            >
            > It can hardly be said that in every case an existing alternative way
            > is neccessarily a good solution. In those cases the *workaround* may be
            > more satisfactory decription. And yes, we all do use workarounds in this
            > business all the day every day, nothing new.

            It's just a matter of taste whether you call this an alternative or a
            workaround. I would rather use the word "workaround" to get around a bug.
            When an application doesn't offer some feature, you have to find an alternate
            way to do it, thus I would call it an "alternative".

            > > Introducing f:var would make your scripts simpler and Vim more
            > > complicated.
            >
            > Oh yes, for sure, but isn't it what everyone is striving for? Make a tool
            > the easiest on the user level? I am surprised that you, of all people, who
            > really goes after the *user level* simplicity, mentions that.

            Not implementing f:var makes Vim easier to use. Less features == less
            documentation == easier to understand. Only when the alternative is
            complicated does adding a feature makes it simpler.

            > ...
            > >
            > > I don't see many things tight to a 'filetype'. In the syntax file you can
            > > use "s:var", for example. Most other things are global anyway (you need
            > > to be able to access them when 'filetype' is different too).
            >
            > And what about very powerful FileType event in autocmd? And indent? And
            > others?
            > And they are all very useful for certain things. Even if very rarely
            > everyone of those is used by everyone everyday...

            These are mostly things you would not be able to do without these features.
            And sometimes it's possible to do it without, but it's very complicated. Of
            course there is a grey area between "a simple alternative" and "very
            complicated". I need good arguments to figure this out.

            --
            hundred-and-one symptoms of being an internet addict:
            199. You read this entire list of symptoms, looking for something
            that doesn't describe you.

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          • Neil Bird
            ... I think I agree. if exists( g:ft_initialised ) finish else let g:ft_initialised = 1 endif let g:ft_everythingelse= set ... is wholly consistent with the
            Message 5 of 26 , Jan 3, 2001
            • 0 Attachment
              Bram Moolenaar wrote:
              > let f:var = "value"
              > can be
              > let g:ft_var = "value"

              I think I agree.


              if exists("g:ft_initialised")
              finish
              else
              let g:ft_initialised = 1
              endif

              let g:ft_everythingelse='set'


              ... is wholly consistent with the formal vim6 plugin methodology.

              --
              =====================- http://www.thalesgroup.com/ -=====================
              Neil Bird | If this .signature |
              work mailto:neil.bird@... | looks pants, then | $> cd /pub
              personal mailto:neil@... | stop using Outlook! | $> more beer
            • Zdenek Sekera
              ... No, Neil, I think you missed the fine details :-), check this: exe let gft = g: .&ft. _initialised if exists(gft)
              Message 6 of 26 , Jan 3, 2001
              • 0 Attachment
                Neil Bird wrote:
                >
                > Bram Moolenaar wrote:
                > > let f:var = "value"
                > > can be
                > > let g:ft_var = "value"
                >
                > I think I agree.
                >
                > if exists("g:ft_initialised")
                > finish
                > else
                > let g:ft_initialised = 1
                > endif
                >
                > let g:ft_everythingelse='set'
                >
                > ... is wholly consistent with the formal vim6 plugin methodology.

                No, Neil, I think you missed the fine details :-), check this:

                exe "let gft = g:".&ft."_initialised"
                if exists(gft) <- I think this goes without ".." !!!
                finish
                else
                exe "let g:".&ft."_initialised = 1"
                endif
                exe "let g:".&ft."_everythingelse="."'set'" <- or whatever

                (without guarantee, but it will boil down to that)

                You have to go through this gymnastics *every* time you want to get to
                that variable. How is that for redability?

                Of course, using functions make it look better, but I sincerely doubt
                the function call overhead will be negligible because, in a script of
                any
                *reasonable* size, there *may* be *many* (maybe *very many*) references
                to this variable. *Bien sur* your mileage will vary, but at the end of
                the day, I'd be always winning with f:var :-):-).

                >
                > ... is wholly consistent with the formal vim6 plugin methodology.

                This is tru *only* when the script is a *plugin* type. Which is the case
                when it can be sourced in once and be done with it.
                When this is not the case (e.g. the script generates new values of
                variables (yes those mine dreamt of f:var, as soon as some other event
                happens (a file is changed, a g:somevar is changed, etc, all those apply
                to my case, by the way)), the script gets re-sourced every such time
                and the plugin methodology doesn't apply.

                Just a comment.

                ---Zdenek
              • Vince Negri
                ... I think perhaps you need to show us an example of what you would be doing if f:var existed. It would probably be a more compelling argument, since this is
                Message 7 of 26 , Jan 3, 2001
                • 0 Attachment
                  > Zdenek Sekera [SMTP:zs@...] wrote:
                  ...
                  > When this is not the case (e.g. the script generates new values of
                  > variables (yes those mine dreamt of f:var, as soon as some other event
                  > happens (a file is changed, a g:somevar is changed, etc, all those apply
                  > to my case, by the way)), the script gets re-sourced every such time
                  > and the plugin methodology doesn't apply.

                  I think perhaps you need to show us an example of what you would be
                  doing if f:var existed. It would probably be a more compelling argument,
                  since this is a 'utility vs. code cost' debate, to demonstrate something
                  which enthuses others to ft-specific variables.

                  You said

                  > I have a clear case for f:var, during a setup for
                  > something I need to go through an init process for the &ft, when
                  > done values are valid for all buffers of the same ft. Init is quite
                  > lengthy. The f:vars would be just perfect for it. For now I use
                  > b:vars, thus repeating init for all buffers, very wasty.

                  So post what this would look like with f:vars and explain what it
                  is being used for.


                  Vince


                  Legal Disclaimer: Any views expressed by the sender of this message are
                  not necessarily those of Application Solutions Ltd. Information in this
                  e-mail may be confidential and is for the use of the intended recipient
                  only, no mistake in transmission is intended to waive or compromise such
                  privilege. Please advise the sender if you receive this e-mail by mistake.
                • Zdenek Sekera
                  ... Hmmm, I checked :h script-variable (60r) and it indeed talks about it, I must have missed it, maybe I could make use of it...need to get some thinking
                  Message 8 of 26 , Jan 3, 2001
                  • 0 Attachment
                    Bram Moolenaar wrote:
                    >
                    ...
                    >
                    > The value of s:var is kept when the script finishes. You can use it again the
                    > next time the same script is sourced. s:var is "static", in C terms. This
                    > changed some time ago.
                    >

                    Hmmm, I checked :h script-variable (60r) and it indeed talks about it,
                    I must have missed it, maybe I could make use of it...need to get some
                    thinking now...thanks!

                    ...
                    > let f:var = "value"
                    > can be
                    > let g:ft_var = "value"

                    rather:
                    exe "let g:".&ft." = " . value

                    > or
                    > call MyFTSet("var", "value")
                    >

                    That's better, indeed, lot can be hidden in MyFTSet(), of course, I just
                    wonder
                    about the overhead.

                    > It's not _that_ bad. Of course the first one is shorter, but it requires a
                    > fatter Vim.

                    Just like icing on the cake, sometimes good, sometimes too much.
                    Vim can still get fatter, wisely, I agree.
                    >
                    ...
                    >
                    > It's just a matter of taste whether you call this an alternative or a
                    > workaround. I would rather use the word "workaround" to get around a bug.
                    > When an application doesn't offer some feature, you have to find an alternate
                    > way to do it, thus I would call it an "alternative".
                    >

                    Yes you found a better expression, I am with you.

                    ...
                    > Not implementing f:var makes Vim easier to use. Less features == less
                    > documentation == easier to understand. Only when the alternative is
                    > complicated does adding a feature makes it simpler.

                    Good principles if you asked me, really!
                    (But: f:var needs no doc except one sentence :-)).

                    ...
                    >
                    > These are mostly things you would not be able to do without these features.
                    > And sometimes it's possible to do it without, but it's very complicated. Of
                    > course there is a grey area between "a simple alternative" and "very
                    > complicated".

                    Very very true, no problem with that. I just wanted to say that the
                    'filetype'
                    is a very prominent word in the vim vocabulary (and rightly so).

                    > I need good arguments to figure this out.

                    Looks like mine are not good enough. Arrrgh, but that's what the
                    discussion
                    is for. Anyway I need to give a good check to those s:var's, if it works
                    than
                    I'm fine, hope they won't change the property from
                    alpha->beta->release....!!

                    ---Zdenek
                  • Zdenek Sekera
                    ... I fully realize that and it is my intention, so now I am *committing* myself. I am doing something close to the *context editing* (*close* not
                    Message 9 of 26 , Jan 3, 2001
                    • 0 Attachment
                      Vince Negri wrote:
                      >
                      ...
                      >
                      > I think perhaps you need to show us an example of what you would be
                      > doing if f:var existed. It would probably be a more compelling argument,
                      > since this is a 'utility vs. code cost' debate, to demonstrate something
                      > which enthuses others to ft-specific variables.
                      >

                      I fully realize that and it is my intention, so now I am *committing*
                      myself.
                      I am doing something close to the *context editing* (*close* not
                      *identical*),
                      what can be done with vim scripts (and a lot can be).

                      Unfortunately, (though I have it working *for me*, and I like it) it is
                      not
                      in the state that it could be distributed. Showing a piece will convince
                      nobody,
                      sending the whole application will not do it because it doesn't work
                      fully yet.
                      It's a classical case of the *thing in the development* where one tries
                      and goes back to try something else. This f:var thing came from it as a
                      result
                      of different tries.

                      Anyway, I'll either use s:var (see another post) or b:var as I do now
                      and see
                      what's the limit of usability. When I'm happy, I'll distribute it and
                      shoot me
                      down then. (I didn't say yet this uses another of my packages which
                      imitates
                      arrays..., I just don't know how to do it without them)

                      Anyway, hopefully in 2 weeks I'm done.

                      ---Zdenek
                    • c928400@student.dtu.dk
                      ... The three first lines are not that bad, it is the repeated hassle of expanding ft that is cumbersome. The following will execute one-liners with ft_
                      Message 10 of 26 , Jan 3, 2001
                      • 0 Attachment
                        Thus wrote Zdenek Sekera (zs@...) on [010103]:
                        > exe "let gft = g:".&ft."_initialised"
                        > if exists(gft) <- I think this goes without ".." !!!
                        > finish
                        > else
                        > exe "let g:".&ft."_initialised = 1"
                        > endif
                        > exe "let g:".&ft."_everythingelse="."'set'" <- or whatever

                        The three first lines are not that bad, it is the repeated hassle of
                        expanding 'ft' that is cumbersome. The following will execute
                        one-liners with 'ft_' expanded to &ft.'_'

                        com -nargs=* FTdo exec substitute(<q-args>, '\<ft_', &ft . '_', 'g')

                        Thus you could do

                        FTdo let gft = "g:ft_initialised"
                        if exists(gft)
                        finish
                        else
                        FTdo let g:ft_initialised = 1
                        endif
                        FTdo let g:ft_everythingelse = 'set'

                        Note that you can only do 'FTdo if ...' if you keep all of the if
                        statement as a one-liner (eg. by line continuation with '\|').

                        > You have to go through this gymnastics *every* time you want to get to
                        > that variable. How is that for redability?

                        Does :FTdo look better?

                        > Of course, using functions make it look better, but I sincerely doubt
                        > the function call overhead will be negligible because, in a script of
                        > any
                        > *reasonable* size, there *may* be *many* (maybe *very many*) references
                        > to this variable. *Bien sur* your mileage will vary, but at the end of
                        > the day, I'd be always winning with f:var :-):-).

                        I think your definition of *reasonable* might be somewhat larger than
                        mine :-) [that is, I have a fairly large script which utilises the
                        wrapper commands in my VimLib posted a couple of weeks ago and I would
                        not call the result too slow - actually syntax highlighting is far
                        worse on my 486.]

                        > This is tru *only* when the script is a *plugin* type. Which is the case
                        > when it can be sourced in once and be done with it.

                        If a :function or :command uses a s:var globally defined in the
                        plugin, it is my experience that you can change those. A simple
                        example would be

                        let s:foo = "foo"
                        com! -nargs=* MyPluginExec exec <q-args>

                        MyPluginExec echo s:foo
                        MyPluginExec let s:foo = "bar"
                        MyPluginExec echo s:foo

                        which, when sourced echos "foo" then "bar".

                        Peppe
                        --
                        "Before you criticize someone, walk
                        Preben "Peppe" Guldberg __/-\__ a mile in his shoes. That way, if
                        c928400@... (o o) he gets angry, he'll be a mile away
                        ----------------------oOOo (_) oOOo-- - and barefoot." --Sarah Jackson
                      • Neil Bird
                        ... Ah, I think I see. I d thought you were doing something specific to one or two filetypes; by the looks of it, you have a set of routines that are always
                        Message 11 of 26 , Jan 3, 2001
                        • 0 Attachment
                          Zdenek Sekera wrote:
                          > No, Neil, I think you missed the fine details :-), check this:
                          >
                          > exe "let gft = g:".&ft."_initialised"
                          > if exists(gft) <- I think this goes without ".." !!!
                          > finish
                          > else
                          > exe "let g:".&ft."_initialised = 1"
                          > endif
                          > exe "let g:".&ft."_everythingelse="."'set'" <- or whatever

                          Ah, I think I see. I'd thought you were doing something specific to one
                          or two filetypes; by the looks of it, you have a set of routines that are
                          always run for each filetype, and yes, that would get complicated.

                          But that's going to, anyway, isn't it? It'll be difficult to say until
                          we see what you're up to :-)

                          --
                          =====================- http://www.thalesgroup.com/ -=====================
                          Neil Bird | If this .signature |
                          work mailto:neil.bird@... | looks pants, then | $> cd /pub
                          personal mailto:neil@... | stop using Outlook! | $> more beer
                        • Bram Moolenaar
                          ... Does your script really work for many different filetypes? Sounds complicated. In that case I would accept the script the be a bit complicated.
                          Message 12 of 26 , Jan 3, 2001
                          • 0 Attachment
                            Zdenek Sekera wrote:

                            > No, Neil, I think you missed the fine details :-), check this:
                            >
                            > exe "let gft = g:".&ft."_initialised"
                            > if exists(gft) <- I think this goes without ".." !!!
                            > finish
                            > else
                            > exe "let g:".&ft."_initialised = 1"
                            > endif
                            > exe "let g:".&ft."_everythingelse="."'set'" <- or whatever
                            >
                            > (without guarantee, but it will boil down to that)

                            Does your script really work for many different filetypes? Sounds
                            complicated. In that case I would accept the script the be a bit complicated.

                            [out-of-order]
                            > Of course, using functions make it look better, but I sincerely doubt
                            > the function call overhead will be negligible because, in a script of
                            > any *reasonable* size, there *may* be *many* (maybe *very many*) references
                            > to this variable. *Bien sur* your mileage will vary, but at the end of
                            > the day, I'd be always winning with f:var :-):-).

                            Using a function call will reduce the need for ":exe" and make it a bit more
                            readable. There is a bit of overhead but it's not much. I wouldn't worry
                            about that unless your script is repeated in some way.

                            > You have to go through this gymnastics *every* time you want to get to
                            > that variable. How is that for redability?

                            You could perhaps assing the value to an s:var at the start and write it back
                            to the global variable at the end. Anyway, there are probably many other
                            solutions to simplify this. Using buffer-local variables is one of them
                            (since 'filetype' is local to the buffer too).

                            You just happended to do something with 'filetype' here. Next somebody asks
                            the same for 'charcode', 'langmenu', etc. We can't create variable types for
                            all of those! I know that 'filetype' is the most obvious of these, but the
                            general idea of an option value specifying a new name space sounds strange to
                            me.

                            --
                            hundred-and-one symptoms of being an internet addict:
                            207. You're given one phone call in prison and you ask them for a laptop.

                            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                            ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                          • Vince Negri
                            ... [snip] ... more ... [snip] ... asks ... for ... the ... to ... The crux of the problem seems here to be that exe let gft = g: .&ft. _initialised looks
                            Message 13 of 26 , Jan 3, 2001
                            • 0 Attachment
                              > Bram Moolenaar [SMTP:Bram@...] wrote:
                              > > exe "let gft = g:".&ft."_initialised"
                              > > if exists(gft) <- I think this goes without ".." !!!
                              [snip]

                              > Using a function call will reduce the need for ":exe" and make it a bit
                              more
                              > readable. There is a bit of overhead but it's not much. I wouldn't worry
                              > about that unless your script is repeated in some way.

                              [snip]

                              > You just happended to do something with 'filetype' here. Next somebody
                              asks
                              > the same for 'charcode', 'langmenu', etc. We can't create variable types
                              for
                              > all of those! I know that 'filetype' is the most obvious of these, but
                              the
                              > general idea of an option value specifying a new name space sounds strange
                              to
                              > me.

                              The crux of the problem seems here to be that
                              exe "let gft = g:".&ft."_initialised"
                              looks messy compared to
                              let gft = ft:initialised

                              Maybe rather than create new variable types all over the place, we can come
                              up with some syntactic sugar which makes the exe "let gft =
                              g:".&ft."_initialised"
                              syntax less pooey. :-)

                              I don't really know how the Vimscript/ex parsing hangs together, but I
                              wonder
                              if there could be some syntax like (of the top of my head)

                              let g::&ft::_initialised=1

                              where the ::'s cause the &ft to be substituted in place in the ex command
                              line, and
                              Vim actually executes (assuming 'ft'=c)

                              let g:c_initialised=1

                              Then people can have their

                              let g::&charcode::_initialised=1

                              if they want...

                              I suppose it depends on how variable names get parsed.

                              Vince




                              Legal Disclaimer: Any views expressed by the sender of this message are
                              not necessarily those of Application Solutions Ltd. Information in this
                              e-mail may be confidential and is for the use of the intended recipient
                              only, no mistake in transmission is intended to waive or compromise such
                              privilege. Please advise the sender if you receive this e-mail by mistake.
                            • Bram Moolenaar
                              ... I think this requires going over the line twice: First to replace the ::&ft:: with c and then to execute it. That s similar to using :exec in
                              Message 14 of 26 , Jan 3, 2001
                              • 0 Attachment
                                Vince Negri wrote:

                                >
                                > Maybe rather than create new variable types all over the place, we can come
                                > up with some syntactic sugar which makes the exe "let gft =
                                > g:".&ft."_initialised"
                                > syntax less pooey. :-)
                                >
                                > I don't really know how the Vimscript/ex parsing hangs together, but I
                                > wonder if there could be some syntax like (of the top of my head)
                                >
                                > let g::&ft::_initialised=1
                                >
                                > where the ::'s cause the &ft to be substituted in place in the ex command
                                > line, and Vim actually executes (assuming 'ft'=c)
                                >
                                > let g:c_initialised=1
                                >
                                > Then people can have their
                                >
                                > let g::&charcode::_initialised=1
                                >
                                > if they want...
                                >
                                > I suppose it depends on how variable names get parsed.

                                I think this requires going over the line twice: First to replace the ::&ft::
                                with "c" and then to execute it. That's similar to using ":exec" in
                                functionality. The syntax is much more obscure though.

                                The suggestion to use a User command for this sounds much better.

                                --
                                hundred-and-one symptoms of being an internet addict:
                                212. Your Internet group window has more icons than your Accessories window.

                                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                              • Zdenek Sekera
                                ... Absolutely. And I strongly believe in the *visual acceptance* of a language (actually of anything, applies to girls, too :-):-):-)), remember Dirac: an
                                Message 15 of 26 , Jan 4, 2001
                                • 0 Attachment
                                  c928400@... wrote:
                                  >
                                  > Thus wrote Zdenek Sekera (zs@...) on [010103]:
                                  > > exe "let gft = g:".&ft."_initialised"
                                  > > if exists(gft) <- I think this goes without ".." !!!
                                  > > finish
                                  > > else
                                  > > exe "let g:".&ft."_initialised = 1"
                                  > > endif
                                  > > exe "let g:".&ft."_everythingelse="."'set'" <- or whatever
                                  >
                                  > The three first lines are not that bad, it is the repeated hassle of
                                  > expanding 'ft' that is cumbersome.

                                  Absolutely. And I strongly believe in the *visual acceptance* of a
                                  language
                                  (actually of anything, applies to girls, too :-):-):-)),
                                  remember Dirac: an equation is more correct if it is beautiful (or some
                                  variant
                                  on that one).

                                  > The following will execute
                                  > one-liners with 'ft_' expanded to &ft.'_'
                                  >
                                  > com -nargs=* FTdo exec substitute(<q-args>, '\<ft_', &ft . '_', 'g')
                                  >
                                  > Thus you could do
                                  >
                                  > FTdo let gft = "g:ft_initialised"
                                  > if exists(gft)
                                  > finish
                                  > else
                                  > FTdo let g:ft_initialised = 1
                                  > endif
                                  > FTdo let g:ft_everythingelse = 'set'
                                  >

                                  Very nice and probably the *cleanest looking* of all suggestions so far.
                                  Thanks!

                                  > Note that you can only do 'FTdo if ...' if you keep all of the if
                                  > statement as a one-liner (eg. by line continuation with '\|').
                                  >

                                  Don't understand that one. Are you saying I *can* or *cannot* use
                                  continuation
                                  lines with user commands? I am pretty sure I am using them in other
                                  context,
                                  would have to dig that out.

                                  > > You have to go through this gymnastics *every* time you want to get to
                                  > > that variable. How is that for redability?
                                  >
                                  > Does :FTdo look better?
                                  >

                                  It definitely does!

                                  > > Of course, using functions make it look better, but I sincerely doubt
                                  > > the function call overhead will be negligible because, in a script of
                                  > > any
                                  > > *reasonable* size, there *may* be *many* (maybe *very many*) references
                                  > > to this variable. *Bien sur* your mileage will vary, but at the end of
                                  > > the day, I'd be always winning with f:var :-):-).
                                  >
                                  > I think your definition of *reasonable* might be somewhat larger than
                                  > mine :-)

                                  I don't know, I know it fits my case :-)!

                                  > [that is, I have a fairly large script which utilises the
                                  > wrapper commands in my VimLib posted a couple of weeks ago and I would
                                  > not call the result too slow - actually syntax highlighting is far
                                  > worse on my 486.]
                                  >

                                  I have done some tests yesterday and, indeed, I tend to agree that I
                                  am/was
                                  probably overstating the time penalty caused by function calls. It all
                                  depends on context, but apples for apples syntax highlighting is much
                                  more serious. But - even a river is composed of drops, so one has to
                                  watch
                                  it.

                                  ..
                                  >
                                  > If a :function or :command uses a s:var globally defined in the
                                  > plugin, it is my experience that you can change those. A simple
                                  > example would be
                                  >
                                  > let s:foo = "foo"
                                  > com! -nargs=* MyPluginExec exec <q-args>
                                  >
                                  > MyPluginExec echo s:foo
                                  > MyPluginExec let s:foo = "bar"
                                  > MyPluginExec echo s:foo
                                  >
                                  > which, when sourced echos "foo" then "bar".

                                  Bram mentioned already some variant of this and I am now very confused
                                  about
                                  the s:var. I thought (at least it was like that at some point I believe)
                                  that it will disappear when script passed the 'finish' (stated or
                                  implied)
                                  statement. Now it looks like it doesn't. So what *is* the exact scope of
                                  this var? How does it differ from b:var ? I am really not sure if one
                                  can
                                  get that precise meaning from the doc, at least I am unable to.
                                  Any help?

                                  Thanks, Peppe, that user command above *is* brilliant!

                                  ---Zdenek
                                • Zdenek Sekera
                                  ... Very briefly, it very much resembles the syntax highligting: there are config files for each filetype, there is a (bunch of) scripts (common to all
                                  Message 16 of 26 , Jan 4, 2001
                                  • 0 Attachment
                                    Bram Moolenaar wrote:
                                    >
                                    ...
                                    >
                                    > Does your script really work for many different filetypes? Sounds
                                    > complicated. In that case I would accept the script the be a bit complicated.
                                    >

                                    Very briefly, it very much resembles the syntax highligting: there are
                                    config
                                    files for each filetype, there is a (bunch of) scripts (common to all
                                    filetypes),
                                    when you edit a file of certain &ft and hit the mapped key, scripts will
                                    read
                                    the config files for that filetype and init itself. That's the basics,
                                    at the
                                    end it's a little more complex because I can catch (most) any change of
                                    config
                                    (in the config scripts or on-the-fly, by detecting a change of certain
                                    variables
                                    etc...) and in such a case I have to re-init the thing.

                                    ...
                                    >
                                    > Using a function call will reduce the need for ":exe" and make it a bit more
                                    > readable. There is a bit of overhead but it's not much. I wouldn't worry
                                    > about that unless your script is repeated in some way.
                                    >

                                    As I mentioned in another mail, based on this very statement I made
                                    quite a number
                                    of timing tests (surely not exhaustive but sufficient to convince me)
                                    and
                                    you are right, the function call isn't very time consuming and can be
                                    ignored
                                    for most processing. There are worse things than that (syntax highliting
                                    is one).
                                    So I worry much less now.

                                    ...
                                    > You just happended to do something with 'filetype' here. Next somebody asks
                                    > the same for 'charcode', 'langmenu', etc. We can't create variable types for
                                    > all of those! I know that 'filetype' is the most obvious of these, but the
                                    > general idea of an option value specifying a new name space sounds strange to
                                    > me.

                                    Actually, and for the laugh of it, *you* are the cause :-)!
                                    When scripting started we had g: l: (never used because it's default)
                                    and later a: (perhaps v:).
                                    I never thought we might need more.

                                    When 6.0 came there were many more that appeared out of blue sky:
                                    b:, w:, s: ...(all very useful)
                                    So I figured you must have find a nice way of doing it in vim (keeping
                                    the
                                    namespaces separated) and when I had that problem of mine and f:
                                    sprinkled
                                    as an idea, I thought hey, that one isn't there.
                                    So: :-):-):-)

                                    ---Zdenek
                                  • Zdenek Sekera
                                    ... Yes, absolutely. ... ^^^^^ I had to ask about that one, one of my colleagues from NZ claimed it can mean anything between paradise and evil (well, he used
                                    Message 17 of 26 , Jan 4, 2001
                                    • 0 Attachment
                                      Vince Negri wrote:
                                      >
                                      ...
                                      >
                                      > The crux of the problem seems here to be that
                                      > exe "let gft = g:".&ft."_initialised"
                                      > looks messy compared to
                                      > let gft = ft:initialised
                                      >

                                      Yes, absolutely.

                                      > Maybe rather than create new variable types all over the place, we can come
                                      > up with some syntactic sugar which makes the exe "let gft =
                                      > g:".&ft."_initialised"
                                      > syntax less pooey. :-)
                                      ^^^^^
                                      I had to ask about that one, one of my colleagues from NZ claimed it can
                                      mean
                                      anything between paradise and evil (well, he used different words that
                                      are
                                      easy to pronounce but hard to write :-) which make the scope even
                                      wider).
                                      I wonder what meaning did *you* have in mind :-):-):-)

                                      >
                                      > I don't really know how the Vimscript/ex parsing hangs together, but I
                                      > wonder
                                      > if there could be some syntax like (of the top of my head)
                                      >
                                      > let g::&ft::_initialised=1
                                      >
                                      > where the ::'s cause the &ft to be substituted in place in the ex command
                                      > line, and
                                      > Vim actually executes (assuming 'ft'=c)
                                      >
                                      > let g:c_initialised=1
                                      >
                                      > Then people can have their
                                      >
                                      > let g::&charcode::_initialised=1
                                      >
                                      > if they want...
                                      >
                                      > I suppose it depends on how variable names get parsed.
                                      >

                                      I find it a very nice idea, though this exact form isn't much appealing
                                      to me
                                      (and I don't have a different one), but the idea is there. It would
                                      certainly be
                                      more readable (eventually) and more practical to use. But as you said
                                      the
                                      feasability of implementation depends on innards of parsing. Only Bram
                                      can say. But I think it would be a very practical thing to have.

                                      ---Zdenek
                                    • Zdenek Sekera
                                      ... Sure, but if the visually appealing syntax was found, I think it would be more practical than exec (for things like this). ... It is certainly a good way
                                      Message 18 of 26 , Jan 4, 2001
                                      • 0 Attachment
                                        Bram Moolenaar wrote:
                                        >
                                        ...
                                        > Vince:
                                        > (of the top of my head)
                                        > >
                                        > > let g::&ft::_initialised=1
                                        > >
                                        > > where the ::'s cause the &ft to be substituted in place in the ex command
                                        > > line, and Vim actually executes (assuming 'ft'=c)
                                        > >
                                        > > let g:c_initialised=1
                                        > >
                                        > > Then people can have their
                                        > >
                                        > > let g::&charcode::_initialised=1
                                        > >
                                        > > if they want...
                                        > >
                                        > > I suppose it depends on how variable names get parsed.
                                        >
                                        > I think this requires going over the line twice: First to replace the ::&ft::
                                        > with "c" and then to execute it. That's similar to using ":exec" in
                                        > functionality. The syntax is much more obscure though.

                                        Sure, but if the visually appealing syntax was found, I think it would
                                        be
                                        more practical than exec (for things like this).

                                        >
                                        > The suggestion to use a User command for this sounds much better.

                                        It is certainly a good way to go right now IMHO. But I wouldn't abandon
                                        Vince's idea completely, I think it would really go a long in improving
                                        the readability if a right form could be found and it is *much* more
                                        intuitive, I think.

                                        ---Zdenek
                                      • Bram Moolenaar
                                        ... This sounds like you are trying to do some speed optimization, which makes the scripts more complicated. I ve been taught to keep the functionality and
                                        Message 19 of 26 , Jan 4, 2001
                                        • 0 Attachment
                                          Zdenek Sekera wrote:

                                          > Bram Moolenaar wrote:
                                          > > Does your script really work for many different filetypes? Sounds
                                          > > complicated. In that case I would accept the script the be a bit
                                          > > complicated.
                                          >
                                          > Very briefly, it very much resembles the syntax highligting: there are
                                          > config files for each filetype, there is a (bunch of) scripts (common to all
                                          > filetypes), when you edit a file of certain &ft and hit the mapped key,
                                          > scripts will read the config files for that filetype and init itself. That's
                                          > the basics, at the end it's a little more complex because I can catch (most)
                                          > any change of config (in the config scripts or on-the-fly, by detecting a
                                          > change of certain variables etc...) and in such a case I have to re-init the
                                          > thing.

                                          This sounds like you are trying to do some speed optimization, which makes the
                                          scripts more complicated. I've been taught to keep the functionality and
                                          optimizations separate. Both in design and in implementation. Perhaps that
                                          helps in the design of your code too.

                                          Vim reads the syntax file each time it opens a buffer, even though that syntax
                                          file might have been read before. I didn't try to optimize this, because it
                                          would cause all kinds of complications (e.g, the syntax file might work
                                          slightly different when some global variable has been set). Opening a buffer
                                          might be a bit slower because of this, but you don't run into problems and
                                          writing a syntax file is not made more complicated.

                                          Did you try making your scripts without the optimizations? They need to be
                                          reasonably fast anyway, otherwise editing the first file of a certain type
                                          would be slow. So then why not accept the same slowdown for further editing?
                                          You might better spend effort on speeding up the first load instead of
                                          speeding up following loads.

                                          > ...
                                          > > You just happended to do something with 'filetype' here. Next somebody
                                          > > asks the same for 'charcode', 'langmenu', etc. We can't create variable
                                          > > types for all of those! I know that 'filetype' is the most obvious of
                                          > > these, but the general idea of an option value specifying a new name space
                                          > > sounds strange to me.
                                          >
                                          > Actually, and for the laugh of it, *you* are the cause :-)!
                                          > When scripting started we had g: l: (never used because it's default) and
                                          > later a: (perhaps v:). I never thought we might need more.
                                          >
                                          > When 6.0 came there were many more that appeared out of blue sky: b:, w:, s:
                                          > ...(all very useful) So I figured you must have find a nice way of doing it
                                          > in vim (keeping the namespaces separated) and when I had that problem of
                                          > mine and f: sprinkled as an idea, I thought hey, that one isn't there.
                                          > So: :-):-):-)

                                          I can imagine that when you see one new feature you think of another one that
                                          would be nice too. Namespaces are useful when you have a small set of them.
                                          One namespace causes problems because scripts will byte eachother. An
                                          unlimited number of namespaces makes it very complicated. The right choice is
                                          somewhere in the middle...

                                          --
                                          hundred-and-one symptoms of being an internet addict:
                                          231. You sprinkle Carpet Fresh on the rugs and put your vacuum cleaner
                                          in the front doorway permanently so it always looks like you are
                                          actually attempting to do something about that mess that has amassed
                                          since you discovered the Internet.

                                          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                          ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                          \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                        • c928400@student.dtu.dk
                                          ... A bit unclear perhaps. The thing is, you can use FTdo and :if (and similar dependency based groups of commands) together, if you use line continutation as
                                          Message 20 of 26 , Jan 4, 2001
                                          • 0 Attachment
                                            Thus wrote Zdenek Sekera (zs@...) on [010104]:
                                            > c928400@... wrote:
                                            > > Note that you can only do 'FTdo if ...' if you keep all of the if
                                            > > statement as a one-liner (eg. by line continuation with '\|').

                                            > Don't understand that one. Are you saying I *can* or *cannot* use
                                            > continuation
                                            > lines with user commands? I am pretty sure I am using them in other
                                            > context,
                                            > would have to dig that out.

                                            A bit unclear perhaps. The thing is, you can use FTdo and :if (and
                                            similar dependency based groups of commands) together, if you use line
                                            continutation as in

                                            FTdo if exists("b:ft_var")
                                            \| finish
                                            \| else
                                            \| let b:ft_var = 1
                                            \| endif

                                            If you do not use line continuation, as in

                                            FTdo if exists("b:ft_var")
                                            finish
                                            else
                                            FTdo let b:ft_var = 1
                                            endif

                                            the :if is evaluated on its own and the script finishes immediately
                                            (at least my small test when creating FTdo worked that way).

                                            [--- changing value of an s:var ---]

                                            > Bram mentioned already some variant of this and I am now very confused
                                            > about
                                            > the s:var. I thought (at least it was like that at some point I believe)
                                            > that it will disappear when script passed the 'finish' (stated or
                                            > implied)
                                            > statement. Now it looks like it doesn't. So what *is* the exact scope of
                                            > this var? How does it differ from b:var ? I am really not sure if one
                                            > can
                                            > get that precise meaning from the doc, at least I am unable to.
                                            > Any help?

                                            I think the s:var used to disappear (not sure), but at least now it
                                            sticks around.

                                            Actually I like that it sticks around, because this way you can have
                                            global script definitions floating around, but only for use by
                                            functions and commands defined in the same script as the variables.
                                            (Actually I used this quite a bit in the VimLib I posted before
                                            Christmas.)

                                            These variables can be changed from outside the script under some
                                            circumstances, but _only_ when a :function or :command is constructed
                                            in a way that allow it (either as a defined purpose or as a side
                                            effect of an :exec command - as the example I gave).

                                            Peppe
                                            --
                                            "Before you criticize someone, walk
                                            Preben "Peppe" Guldberg __/-\__ a mile in his shoes. That way, if
                                            c928400@... (o o) he gets angry, he'll be a mile away
                                            ----------------------oOOo (_) oOOo-- - and barefoot." --Sarah Jackson
                                          • Zdenek Sekera
                                            ... OK, I understand now. ... Looks like s: is *hit-and/or-miss to see how it works. Hmmm, I ll try that anyway.
                                            Message 21 of 26 , Jan 4, 2001
                                            • 0 Attachment
                                              c928400@... wrote:
                                              >
                                              ...
                                              > A bit unclear perhaps. The thing is, you can use FTdo and :if (and
                                              > similar dependency based groups of commands) together, if you use line
                                              > continutation as in
                                              >
                                              > FTdo if exists("b:ft_var")
                                              > \| finish
                                              > \| else
                                              > \| let b:ft_var = 1
                                              > \| endif
                                              >
                                              > If you do not use line continuation, as in
                                              >
                                              > FTdo if exists("b:ft_var")
                                              > finish
                                              > else
                                              > FTdo let b:ft_var = 1
                                              > endif
                                              >
                                              > the :if is evaluated on its own and the script finishes immediately
                                              > (at least my small test when creating FTdo worked that way).
                                              >

                                              OK, I understand now.

                                              > [--- changing value of an s:var ---]
                                              ...
                                              >
                                              > I think the s:var used to disappear (not sure), but at least now it
                                              > sticks around.
                                              >
                                              > Actually I like that it sticks around, because this way you can have
                                              > global script definitions floating around, but only for use by
                                              > functions and commands defined in the same script as the variables.
                                              > (Actually I used this quite a bit in the VimLib I posted before
                                              > Christmas.)
                                              >
                                              > These variables can be changed from outside the script under some
                                              > circumstances, but _only_ when a :function or :command is constructed
                                              > in a way that allow it (either as a defined purpose or as a side
                                              > effect of an :exec command - as the example I gave).

                                              Looks like s: is *hit-and/or-miss' to see how it works. Hmmm, I'll try
                                              that
                                              anyway.

                                              ---Zdenek
                                            • Zdenek Sekera
                                              ... True, but than you might end up with PL1...:-) ... I am not trying to optimize more than reasonable. I just don t want to do things more than once unless
                                              Message 22 of 26 , Jan 4, 2001
                                              • 0 Attachment
                                                Bram Moolenaar wrote:
                                                >
                                                ...
                                                > This sounds like you are trying to do some speed optimization, which makes the
                                                > scripts more complicated. I've been taught to keep the functionality and
                                                > optimizations separate. Both in design and in implementation. Perhaps that
                                                > helps in the design of your code too.
                                                >

                                                :-) that looks like taken from some Hoare theoretical class :-)
                                                True, but than you might end up with PL1...:-)

                                                > Vim reads the syntax file each time it opens a buffer, even though that syntax
                                                > file might have been read before. I didn't try to optimize this, because it
                                                > would cause all kinds of complications (e.g, the syntax file might work
                                                > slightly different when some global variable has been set). Opening a buffer
                                                > might be a bit slower because of this, but you don't run into problems and
                                                > writing a syntax file is not made more complicated.
                                                >

                                                I am not trying to optimize more than reasonable. I just don't want to
                                                do things
                                                more than once unless there is good reason for it.

                                                In your case, the syntax files are read by the c code. That *IS* fast.
                                                As an
                                                exercise try than in VimL. Not surpringly there is a world of
                                                difference.
                                                My stuff is pure viml (on purpose). It can be done but one needs to be
                                                extra
                                                careful. Hence I try all ideas I can come up with *to see and get a
                                                feeling*.
                                                I have now switched to reading my config using :runtime. Vast
                                                improvement,
                                                but it brings other issues, e.g. all vars have to be defined before they
                                                can be
                                                used otherwise :runtime blows up. This wouldn't be the case if I could
                                                read
                                                the whole config and then fill up the holes. In c that's fast, in vim
                                                it's
                                                a totally different game. But I think I can get through it (that implies
                                                some redesign but that's OK because of the :runtime speed benefit).

                                                > Did you try making your scripts without the optimizations?

                                                Yes, I have several versions (that idea is with me for over a year now)
                                                and
                                                the reason I am still redoing it and redesigning was precisely the
                                                hickkups
                                                I was getting that drove me nuts. (you'll remember at some point I was
                                                asking you how to call vim functions from c and the opposite, I thought
                                                I'll
                                                have to go to c for speed (that's not needed now I think)).
                                                Fortunately I could isolate (most) of the causes by (now) and that's why
                                                this last version will be *IT* :-)!
                                                And 6.0 (and vim-dev) added lots of good tools and ideas that all help.

                                                > They need to be
                                                > reasonably fast anyway, otherwise editing the first file of a certain type
                                                > would be slow. So then why not accept the same slowdown for further editing?
                                                > You might better spend effort on speeding up the first load instead of
                                                > speeding up following loads.
                                                >

                                                Absolutely true *if it is acceptable the first time*. I think now I can
                                                make
                                                it so. The f: idea was one of those to cut a time slice (however small)
                                                from
                                                the total (salami technique :-)).

                                                ...
                                                > I can imagine that when you see one new feature you think of another one that
                                                > would be nice too. Namespaces are useful when you have a small set of them.
                                                > One namespace causes problems because scripts will byte eachother. An
                                                > unlimited number of namespaces makes it very complicated. The right choice is
                                                > somewhere in the middle...

                                                Can't disagree, back to coding!

                                                ---Zdenek
                                              • Neil Bird
                                                ... Um. Less like poo ? Actually, I fail to see how you *can* misinterpret that! ... Hmm. Stepping back a little, it sounds like (and correct me if I m
                                                Message 23 of 26 , Jan 4, 2001
                                                • 0 Attachment
                                                  Zdenek Sekera wrote:
                                                  > Vince Negri wrote:
                                                  > > syntax less pooey. :-)
                                                  > ^^^^^
                                                  > I had to ask about that one, <snip>
                                                  > I wonder what meaning did *you* have in mind :-):-):-)

                                                  Um. "Less like poo"? Actually, I fail to see how you *can* misinterpret
                                                  that!


                                                  > > let g::&ft::_initialised=1
                                                  >
                                                  > I find it a very nice idea, though this exact form isn't much appealing
                                                  > to me (and I don't have a different one), but the idea is there. It
                                                  > would certainly be more readable (eventually) and more practical to use.
                                                  > But as you said the feasability of implementation depends on innards of
                                                  > parsing. Only Bram can say. But I think it would be a very practical
                                                  > thing to have.

                                                  Hmm. Stepping back a little, it sounds like (and correct me if I'm
                                                  wrong) you want a form of buffer class, such that buffers may elect to
                                                  belong to a class (which may just happen to have the same name as that
                                                  buffer's &ft), and that there are class-specific variables.


                                                  <this'll get waffly since I'm thinking straight to the email!>


                                                  Say you have a class named 'system' [may mean 'read-only system file']
                                                  and another named 'c' [may mean 'this file hase filetype "c"].

                                                  Then you'd have a [syntax aside] system::varname and a c::varname, which
                                                  would be directly equivalent to g:__system__varname and g:__c__varname
                                                  (but less cumbersome to work with).

                                                  Then a buffer may have a local b:class=system,c. Nah, then you get a
                                                  conflict - which varname does the buffer use, system's or c's? If you
                                                  followed that route, you'd have to force the buffer to only belong to one
                                                  class, losing the 'generic feature' attraction.

                                                  And again, in your case, you'd want to be able to do &ft::varname.


                                                  Hmm. It's looking more like a functional-based solution will be most
                                                  widely applicable. Have a classvars.vim file, which defines the functions
                                                  ClassLet(class,varname,value) and ClassGet(class,varname) and let *those*
                                                  access the mangled g:__class__varname. (or s: may be better)

                                                  Maybe. All that's assuming I followed what you wanted!


                                                  Meaning you get: ClassGet(&ft,setting) which is still not fantastic,
                                                  but is easier to read!

                                                  Is that usable everywhere that ft:setting would be (WRT expanding &ft as
                                                  opposed to using '&ft')?

                                                  --
                                                  =====================- http://www.thalesgroup.com/ -=====================
                                                  Neil Bird | If this .signature |
                                                  work mailto:neil.bird@... | looks pants, then | $> cd /pub
                                                  personal mailto:neil@... | stop using Outlook! | $> more beer
                                                • Bram Moolenaar
                                                  ... Keeping your script simple is a very good reason. And a simple script is often faster than a complicated one. I m sure ... is faster than ... Thus your
                                                  Message 24 of 26 , Jan 4, 2001
                                                  • 0 Attachment
                                                    Zdenek Sekera wrote:

                                                    > > Vim reads the syntax file each time it opens a buffer, even though that
                                                    > > syntax file might have been read before. I didn't try to optimize this,
                                                    > > because it would cause all kinds of complications (e.g, the syntax file
                                                    > > might work slightly different when some global variable has been set).
                                                    > > Opening a buffer might be a bit slower because of this, but you don't run
                                                    > > into problems and writing a syntax file is not made more complicated.
                                                    >
                                                    > I am not trying to optimize more than reasonable. I just don't want to do
                                                    > things more than once unless there is good reason for it.

                                                    Keeping your script simple is a very good reason.

                                                    And a simple script is often faster than a complicated one. I'm sure

                                                    :let b:ft_var

                                                    is faster than

                                                    :exe "let b:" . &ft . "_var"

                                                    Thus your tricks to make the second use of a filetype faster, probably makes
                                                    it slower for the first use.

                                                    --
                                                    hundred-and-one symptoms of being an internet addict:
                                                    238. You think faxes are old-fashioned.

                                                    /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                                    ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                                    \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                                  • Paul Moore
                                                    From: zs@sgi.com [mailto:zs@sgi.com] ... Are you using the same code for more than one filetype? The *same* code? If so, why does it depend on the filetype?
                                                    Message 25 of 26 , Jan 4, 2001
                                                    • 0 Attachment
                                                      From: zs@... [mailto:zs@...]
                                                      > No, Neil, I think you missed the fine details :-), check this:
                                                      >
                                                      > exe "let gft = g:".&ft."_initialised"
                                                      > if exists(gft) <- I think this goes without ".." !!!
                                                      > finish
                                                      > else
                                                      > exe "let g:".&ft."_initialised = 1"
                                                      > endif
                                                      > exe "let g:".&ft."_everythingelse="."'set'" <- or whatever
                                                      >
                                                      > (without guarantee, but it will boil down to that)

                                                      Are you using the same code for more than one filetype? The *same* code? If
                                                      so, why does it depend on the filetype? And if you are using different code
                                                      for each filetype, you know the specific filetype you are coding for, and
                                                      you can hard code it, as Neil and Bram suggested.

                                                      I know that your "real life" case is going to be more complicated than this,
                                                      but I'd imagine that most of your use could be split into one of the two
                                                      cases - common code which doesn't need a ft-specific variable, and
                                                      ft-specific code, which can use a (hard-coded) ft-specific variable.

                                                      Basically, I suspect that you can go back to basics and rethink your
                                                      solution to work with the features Vim has, rather than struggling to do
                                                      things that Vim doesn't support.

                                                      Of course, if you really, really do have a case where you definitely need
                                                      ft-specific variables and you don't know the ft, you can use something like

                                                      function! FTvar(var)
                                                      return "g:" . &ft . "_" . a:var
                                                      endfunction

                                                      function! FTset(var, val)
                                                      exe "let " . FTvar(a:var) . "=" . a:val
                                                      endfunction
                                                      command! -nargs=* FTset call FTset(<f-args>)

                                                      function! FTval(var)
                                                      exe "return " . FTvar(a:var)
                                                      endfunction

                                                      Your example then becomes

                                                      if exists(FTvar("initialised"))
                                                      finish
                                                      endif
                                                      FTset initialised 1
                                                      FTset everythingelse 'set'
                                                      " and just to prove you can do it...
                                                      echo FTval("everythingelse")

                                                      ... which looks reasonably good to me.

                                                      Hope this helps,
                                                      Paul.
                                                    • Zdenek Sekera
                                                      ... Same code (=exactly) for all filetypes. It s the config file(s) read at the beginning that drive it. ... Well, not much more than what you say :-). The
                                                      Message 26 of 26 , Jan 5, 2001
                                                      • 0 Attachment
                                                        Paul Moore wrote:
                                                        >
                                                        > From: zs@... [mailto:zs@...]
                                                        > > No, Neil, I think you missed the fine details :-), check this:
                                                        > >
                                                        > > exe "let gft = g:".&ft."_initialised"
                                                        > > if exists(gft) <- I think this goes without ".." !!!
                                                        > > finish
                                                        > > else
                                                        > > exe "let g:".&ft."_initialised = 1"
                                                        > > endif
                                                        > > exe "let g:".&ft."_everythingelse="."'set'" <- or whatever
                                                        > >
                                                        > > (without guarantee, but it will boil down to that)
                                                        >
                                                        > Are you using the same code for more than one filetype? The *same* code? If
                                                        > so, why does it depend on the filetype? And if you are using different code
                                                        > for each filetype, you know the specific filetype you are coding for, and
                                                        > you can hard code it, as Neil and Bram suggested.
                                                        >

                                                        Same code (=exactly) for all filetypes.
                                                        It's the config file(s) read at the beginning that drive it.

                                                        > I know that your "real life" case is going to be more complicated than this,
                                                        > but I'd imagine that most of your use could be split into one of the two
                                                        > cases - common code which doesn't need a ft-specific variable, and
                                                        > ft-specific code, which can use a (hard-coded) ft-specific variable.
                                                        >

                                                        Well, not much more than what you say :-). The common non-ft dependent
                                                        vars
                                                        are negligible amount.

                                                        > Basically, I suspect that you can go back to basics and rethink your
                                                        > solution to work with the features Vim has, rather than struggling to do
                                                        ^^^^^^^^^^
                                                        > things that Vim doesn't support.
                                                        >

                                                        I don't think that's the word. I can do it with b: (I have), but than
                                                        the
                                                        same init sequence has to be repeated for every buffer even if it's of
                                                        the
                                                        same &ft. I just wanted to be more efficient and f: would be just right.
                                                        I know I can do the things below, but that adds code (slows down, that
                                                        may
                                                        be debatable about how much) and though it gets much more readable (and
                                                        systematic => possible coding errors caused by exec are limited to the
                                                        function,
                                                        so code writing gets faster) I still think f: would be perfect.

                                                        But I am not hung on that, it was just a suggestion that I tried to push
                                                        forward
                                                        and it didn't fly, no big deal, I'll do it differently.

                                                        Your hint to go back to the drawing board is always the best solution
                                                        :-) IMHO.
                                                        I am right now in the middle of the n-th version. Forgot the n :-)!

                                                        And Happy New Year, haven't seen you posting for a while, cannoeing :-)

                                                        > Of course, if you really, really do have a case where you definitely need
                                                        > ft-specific variables and you don't know the ft, you can use something like
                                                        >
                                                        > function! FTvar(var)
                                                        > return "g:" . &ft . "_" . a:var
                                                        > endfunction
                                                        >
                                                        > function! FTset(var, val)
                                                        > exe "let " . FTvar(a:var) . "=" . a:val
                                                        > endfunction
                                                        > command! -nargs=* FTset call FTset(<f-args>)
                                                        >
                                                        > function! FTval(var)
                                                        > exe "return " . FTvar(a:var)
                                                        > endfunction
                                                        >
                                                        > Your example then becomes
                                                        >
                                                        > if exists(FTvar("initialised"))
                                                        > finish
                                                        > endif
                                                        > FTset initialised 1
                                                        > FTset everythingelse 'set'
                                                        > " and just to prove you can do it...
                                                        > echo FTval("everythingelse")
                                                        >
                                                        > ... which looks reasonably good to me.
                                                        >

                                                        ---Zdenek
                                                      Your message has been successfully submitted and would be delivered to recipients shortly.