Pseudo options

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Pseudo options

Stefan Karlsson-3
Hi,

Is it possible to create one's own (pseudo) options? Instead of "let foo
= ..." I would sometimes prefer a construct that behave the same way as
a real option, perhaps just a way to declare a name and a way to connect
an autocommand to it.

-- Stefan
Reply | Threaded
Open this post in threaded view
|

Re: Pseudo options

Tim Chase-2
> Is it possible to create one's own (pseudo) options? Instead
> of "let foo = ..." I would sometimes prefer a construct that
> behave the same way as a real option, perhaps just a way to
> declare a name and a way to connect an autocommand to it.

I'm not sure what you mean by your "own (pseudo) options".  You
use "let foo = ..." which is how one manipulates regular
variables, rather than using "set foo nobar ..." usually used for
setting what are usually referred to as options.

If you describe what you're trying to do, it might help us answer
your question.  It sounds somewhat like you simply want to set a
buffer-local variable (see ":help internal-variables" for how to
specify scope of variables) and then perform other operations
(autocommands?) based on whether this variable is set.

It would be helpful to know when you'd expect to see code
running:  automatically when you load a buffer, when you change
an option, when you press a certain key, etc. as well as what
conditions are used to make decisions along that code-path.

-tim




Reply | Threaded
Open this post in threaded view
|

Re: Pseudo options

Stefan Karlsson-3
To clarify my question:

You have made a plugin. *Instead* of using "let foo = ..." you want the
user to be able to customize the plugin via something that looks and
feels just like a 'option'. Is this possible to do, e.g. by creating a
variable and then connect it to an autocommand?

-- Stefan


Tim Chase wrote:

>> Is it possible to create one's own (pseudo) options? Instead of "let
>> foo = ..." I would sometimes prefer a construct that behave the same
>> way as a real option, perhaps just a way to declare a name and a way
>> to connect an autocommand to it.
>
>
> I'm not sure what you mean by your "own (pseudo) options".  You
> use "let foo = ..." which is how one manipulates regular
> variables, rather than using "set foo nobar ..." usually used for
> setting what are usually referred to as options.
>
> If you describe what you're trying to do, it might help us answer
> your question.  It sounds somewhat like you simply want to set a
> buffer-local variable (see ":help internal-variables" for how to
> specify scope of variables) and then perform other operations
> (autocommands?) based on whether this variable is set.
>
> It would be helpful to know when you'd expect to see code
> running:  automatically when you load a buffer, when you change
> an option, when you press a certain key, etc. as well as what
> conditions are used to make decisions along that code-path.
>
> -tim
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Pseudo options

Gary Johnson
On 2005-08-03, Stefan Karlsson <[hidden email]> wrote:
> To clarify my question:
>
> You have made a plugin. *Instead* of using "let foo = ..." you want the
> user to be able to customize the plugin via something that looks and
> feels just like a 'option'. Is this possible to do, e.g. by creating a
> variable and then connect it to an autocommand?

I _think_ I know what you want to do, but it's still not too clear.

First of all, as Tim said, you can't use 'set' to set your own
variable, you have to use 'let', but that shouldn't be a big issue
for your users.

I think what you're concerned about it is your plugin code being
informed when the "option" value changes.  What you'd probably like
to do is be able to register some callback function to the 'let'
command so that your plugin code could react immediately when the
user changed the option value.  You can't do that, at least in vim
6.3; I don't know about 7.  There are three ways I know of to
address that problem.

1.  Instead of using 'let', require that the user change "option"
    settings via a custom command, e.g., "Set" (with an upper-case
    'S').  Since this command is under your control, you can have it
    notify the plugin as well as setting the "option" value.

2.  If the effect of the value change doesn't have to be immediate,
    just have the plugin code read the variable the next time it
    executes.

3.  If the effect needs to be almost immediate, you can use the
    CursorHold autocommand event to monitor the value of your
    "option" after a few hundred milliseconds of no keystrokes in
    normal mode.  Not great, but sometimes the best you can do.

Does that address your question?

HTH,
Gary

--
Gary Johnson                 | Agilent Technologies
[hidden email]     | Wireless Division
                             | Spokane, Washington, USA
Reply | Threaded
Open this post in threaded view
|

Re: Pseudo options

Stefan Karlsson-3

Nope, my question was simply if it was possible to *create* options.

I mean, Vim has n-mode commands *and* a user can create his own n-mode
commands. The same goes for v-mode, i-mode and :-mode commands. Vim has
error messages *and* a user can create his own error messages. Vim has
help pages *and* a user can create his own help pages. And so on.

I was wondering if this reationale extended to options as well, but I
guess it doesn't.

I'm not saying it would be useful or anything :-) , I am simply curious.


Best regards

-- Stefan





Gary Johnson wrote:

>On 2005-08-03, Stefan Karlsson <[hidden email]> wrote:
>  
>
>>To clarify my question:
>>
>>You have made a plugin. *Instead* of using "let foo = ..." you want the
>>user to be able to customize the plugin via something that looks and
>>feels just like a 'option'. Is this possible to do, e.g. by creating a
>>variable and then connect it to an autocommand?
>>    
>>
>
>I _think_ I know what you want to do, but it's still not too clear.
>
>First of all, as Tim said, you can't use 'set' to set your own
>variable, you have to use 'let', but that shouldn't be a big issue
>for your users.
>
>I think what you're concerned about it is your plugin code being
>informed when the "option" value changes.  What you'd probably like
>to do is be able to register some callback function to the 'let'
>command so that your plugin code could react immediately when the
>user changed the option value.  You can't do that, at least in vim
>6.3; I don't know about 7.  There are three ways I know of to
>address that problem.
>
>1.  Instead of using 'let', require that the user change "option"
>    settings via a custom command, e.g., "Set" (with an upper-case
>    'S').  Since this command is under your control, you can have it
>    notify the plugin as well as setting the "option" value.
>
>2.  If the effect of the value change doesn't have to be immediate,
>    just have the plugin code read the variable the next time it
>    executes.
>
>3.  If the effect needs to be almost immediate, you can use the
>    CursorHold autocommand event to monitor the value of your
>    "option" after a few hundred milliseconds of no keystrokes in
>    normal mode.  Not great, but sometimes the best you can do.
>
>Does that address your question?
>
>HTH,
>Gary
>
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: Pseudo options

A.J.Mechelynck
----- Original Message -----
From: "Stefan Karlsson" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, August 04, 2005 10:40 PM
Subject: Re: Pseudo options


>
> Nope, my question was simply if it was possible to *create* options.
>
> I mean, Vim has n-mode commands *and* a user can create his own n-mode
> commands. The same goes for v-mode, i-mode and :-mode commands. Vim has
> error messages *and* a user can create his own error messages. Vim has
> help pages *and* a user can create his own help pages. And so on.
>
> I was wondering if this reationale extended to options as well, but I
> guess it doesn't.
>
> I'm not saying it would be useful or anything :-) , I am simply curious.
>
>
> Best regards
>
> -- Stefan

Actually, options are just variables. There is, it is true, a "special"
command, namely ":set", but it is not essential. Look:

    For a boolean:
        :set option
            :let variable=1
        :set nooption
            :let variable=0
        :set invoption
        :set option!
            :let variable = !variable
        :set option?
            :echo variable

    For a number:
        :set option=1234
            :let variable = 1234
        :set option+=10
            :let variable += 10
        :set option^=5
            :let variable = variable * 5
        :set option
        :set option?
            :echo variable

    For a string:
        :set option=abcd
            :let variable = "abcd"
        :set option=string\ with\ spaces
            :let variable = "string with spaces"
        :set option+=text
            :if variable != "" | let variable .= "," | endif | let variable
.= "text"
        :set option^=text
            :if variable != "" | let variable = "," . variable | endif | let
variable = "text" . variable
        :set option-=text
            :let variable =
substitute(substitute(variable,'^text,\|,text,\|,text$\|^text$',",","g"),'^,\|,$',"","g")
        :set option
        :set option?
            :echo variable

    For a string of flags: same as above, except
        :set option+=f
        :set option^=f
            :if variable !~ "f" | let variable .= "f" | endif
        :set option-=f
            :let variable = substitute(variable, "f", "", "g")

    For any kind:
        :if exists("+option")
            :if exists("variable")

What is missing:
    * "set to default", "set to vi default", "set to vim default"; however,
user-created "options" wouldn't _have_ a default.
    * Test for existence without testing for functionality (":if
exists('&option')"): a variable cannot exist without being functional. I
don't think of this as a blemish re variables.

You can even have global variables (g:variable or, ouside of functions,
variable), buffer-local variables (b:variable), window-local variables
(w:variable), and other kinds which don't exist for options. And you can
create or destroy user-created variables, while Vim options are either
present or they are not (depending on version and on config options) but
they cannot be made to exist if they don't, nor vice-versa. So I'd say
variables are more powerful than options.

I really don't see what you're missing.


Best regards,
Tony.


Reply | Threaded
Open this post in threaded view
|

Re: Pseudo options

Stefan Karlsson-3
1. I know how Vim variables work  :-)
2. I really didn't say I was missing anything, I was simply curious.

By the way, thanks for your effort to keep us updated with fresh,
precompiled versions of Vim. Since I use Windows a lot I appreciate it
very much.

-- Stefan

Tony Mechelynck wrote:

> ----- Original Message ----- From: "Stefan Karlsson"
> <[hidden email]>
> To: <[hidden email]>
> Sent: Thursday, August 04, 2005 10:40 PM
> Subject: Re: Pseudo options
>
>
>>
>> Nope, my question was simply if it was possible to *create* options.
>>
>> I mean, Vim has n-mode commands *and* a user can create his own
>> n-mode commands. The same goes for v-mode, i-mode and :-mode
>> commands. Vim has error messages *and* a user can create his own
>> error messages. Vim has help pages *and* a user can create his own
>> help pages. And so on.
>>
>> I was wondering if this reationale extended to options as well, but I
>> guess it doesn't.
>>
>> I'm not saying it would be useful or anything :-) , I am simply curious.
>>
>>
>> Best regards
>>
>> -- Stefan
>
>
> Actually, options are just variables. There is, it is true, a
> "special" command, namely ":set", but it is not essential. Look:
>
>    For a boolean:
>        :set option
>            :let variable=1
>        :set nooption
>            :let variable=0
>        :set invoption
>        :set option!
>            :let variable = !variable
>        :set option?
>            :echo variable
>
>    For a number:
>        :set option=1234
>            :let variable = 1234
>        :set option+=10
>            :let variable += 10
>        :set option^=5
>            :let variable = variable * 5
>        :set option
>        :set option?
>            :echo variable
>
>    For a string:
>        :set option=abcd
>            :let variable = "abcd"
>        :set option=string\ with\ spaces
>            :let variable = "string with spaces"
>        :set option+=text
>            :if variable != "" | let variable .= "," | endif | let
> variable .= "text"
>        :set option^=text
>            :if variable != "" | let variable = "," . variable | endif
> | let variable = "text" . variable
>        :set option-=text
>            :let variable =
> substitute(substitute(variable,'^text,\|,text,\|,text$\|^text$',",","g"),'^,\|,$',"","g")
>
>        :set option
>        :set option?
>            :echo variable
>
>    For a string of flags: same as above, except
>        :set option+=f
>        :set option^=f
>            :if variable !~ "f" | let variable .= "f" | endif
>        :set option-=f
>            :let variable = substitute(variable, "f", "", "g")
>
>    For any kind:
>        :if exists("+option")
>            :if exists("variable")
>
> What is missing:
>    * "set to default", "set to vi default", "set to vim default";
> however, user-created "options" wouldn't _have_ a default.
>    * Test for existence without testing for functionality (":if
> exists('&option')"): a variable cannot exist without being functional.
> I don't think of this as a blemish re variables.
>
> You can even have global variables (g:variable or, ouside of
> functions, variable), buffer-local variables (b:variable),
> window-local variables (w:variable), and other kinds which don't exist
> for options. And you can create or destroy user-created variables,
> while Vim options are either present or they are not (depending on
> version and on config options) but they cannot be made to exist if
> they don't, nor vice-versa. So I'd say variables are more powerful
> than options.
>
> I really don't see what you're missing.
>
>
> Best regards,
> Tony.
>
>