Why arn't all options local?

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

Why arn't all options local?

Suresh Govindachar`
 
Hello,

  Why aren't all options local?  Is it that an option is made global
  if no plugin can ever be written which depends on that option
  having a particular value?
   
  For some reason, Yasuhiro Matsumoto, the author of Calendar.vim,
  requires that the global option wrapscan have the non-default value
  of off.  So the use of Calendar.vim messes things up for those who
  are used to having wrapscan on.

  Do anyone know why exactly Calendar.vim needs wrapscan to be off?
  Can Calendar.vim be re-written without relying on global options
  having a particular value?

  Thanks,

  --Suresh
 
 
 

Reply | Threaded
Open this post in threaded view
|

color schemes

jagpreet
Hi All,
I downloaded the color s sampler pack from the scripts section.
I unzipped the files and stored in the correct directories as directed.
When on a vim consol I try using the command :colo <tab> I can see all the
colors files got included in the directory but after selecting any(new
included) colorscheme it doesn't changes the colors on the screen.

I'm connecting to a unix terminal via putty(telnet).
I'm not sure if the colorscheme included in the pack works for vim.
Also, when I checked those vim scripts, I find colors are defined with guibg
and guifg.
I guess it will work on gvim only. Am I right??

If it is so, did someone come across color pack for vim as well at site.


~Regards~
Jagpreet


Reply | Threaded
Open this post in threaded view
|

Re: color schemes

panshizhu
"jagpreet" <[hidden email]> wrote on 2006.04.05 16:07:18:

> Hi All,
> I downloaded the color s sampler pack from the scripts section.
> I unzipped the files and stored in the correct directories as directed.
> When on a vim consol I try using the command :colo <tab> I can see all
the
> colors files got included in the directory but after selecting any(new
> included) colorscheme it doesn't changes the colors on the screen.
>
> I'm connecting to a unix terminal via putty(telnet).
> I'm not sure if the colorscheme included in the pack works for vim.
> Also, when I checked those vim scripts, I find colors are defined with
guibg

> and guifg.
> I guess it will work on gvim only. Am I right??
>
> If it is so, did someone come across color pack for vim as well at site.
>
>
> ~Regards~
> Jagpreet
>
>
Hello,

It depends, if the selected color-scheme really contains color-scheme for
color terminal, the color will change.

I'd just found that more than 80% of color-schemes in the color's sampler
pack does only have GUI support, so if you set color-scheme to a scheme
which only contains GUI scheme, you won't get anything.

Some good news: the top-rated color-schemes are more likely to have
color-terminal support together with GUI.

If all you need is to have the color-scheme for color terminal, choose only
schemes which do have terminal support.

--
Sincerely
Pan, Shizhu. ext: 2221

Reply | Threaded
Open this post in threaded view
|

Re: Why arn't all options local?

Eric Arnold
In reply to this post by Suresh Govindachar`

That's just like asking, why aren't all M&Ms green?  Some should be global,
actually, but there are some local options that one might wish were green.

Life is like a box of chocolates, ya know, and we're all more like Forest than
we care to believe, except we don't have as much patience.

I'm assuming the calendar script is using nowrapscan because it can't guarantee
that the calendar will fit into the window.  The program might be re-written to
make sure that it accounts for the window width, if that's even desired, but it
would be simpler in the long run to have it save and restore the value of
&wrapscan in autocommand functions for WinEnter and WinLeave, etc.




--- Suresh Govindachar <[hidden email]> wrote:

>  
> Hello,
>
>   Why aren't all options local?  Is it that an option is made global
>   if no plugin can ever be written which depends on that option
>   having a particular value?
>    
>   For some reason, Yasuhiro Matsumoto, the author of Calendar.vim,
>   requires that the global option wrapscan have the non-default value
>   of off.  So the use of Calendar.vim messes things up for those who
>   are used to having wrapscan on.
>
>   Do anyone know why exactly Calendar.vim needs wrapscan to be off?
>   Can Calendar.vim be re-written without relying on global options
>   having a particular value?
>
>   Thanks,
>
>   --Suresh
>  
>  
>  
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Why arn't all options local?

Suresh Govindachar`


  I don't understand the following:  "Some [options] should be
  global, actually, but there are some local options that one might
  wish were green."

  My understanding is that an option that can be restricted to being
  local is local only if set with :setlocal.  And when one uses just
  :set to set the value of an option that can be restricted to being
  local, it in fact is set globally.

  So any option can always be set globally;  but not all options can
  be set only locally.  

  So asking "why aren't all options local"
  is NOT like asking "why aren't all M&Ms green?"

  Since making every option locally settable does not restrict
  anything, I ask again:  why aren't all options local?  (I don't
  mean why aren't all options set using setlocal; I mean why aren't
  all options restrictable to being local.)
 
  --Suresh

 

-----Original Message-----
From: Eric Arnold [mailto:[hidden email]]
Sent: Wednesday, April 05, 2006 3:23 AM
To: Suresh Govindachar; [hidden email]
Cc: 'Yasuhiro Matsumoto'
Subject: Re: Why arn't all options local?


That's just like asking, why aren't all M&Ms green?  Some should be global, actually, but there are some local options that one
might wish were green.

Life is like a box of chocolates, ya know, and we're all more like Forest than we care to believe, except we don't have as much
patience.

I'm assuming the calendar script is using nowrapscan because it can't guarantee that the calendar will fit into the window.  The
program might be re-written to make sure that it accounts for the window width, if that's even desired, but it would be simpler in
the long run to have it save and restore the value of &wrapscan in autocommand functions for WinEnter and WinLeave, etc.




--- Suresh Govindachar <[hidden email]> wrote:

>  
> Hello,
>
>   Why aren't all options local?  Is it that an option is made global
>   if no plugin can ever be written which depends on that option
>   having a particular value?
>    
>   For some reason, Yasuhiro Matsumoto, the author of Calendar.vim,
>   requires that the global option wrapscan have the non-default value
>   of off.  So the use of Calendar.vim messes things up for those who
>   are used to having wrapscan on.
>
>   Do anyone know why exactly Calendar.vim needs wrapscan to be off?
>   Can Calendar.vim be re-written without relying on global options
>   having a particular value?
>
>   Thanks,
>
>   --Suresh
>  
>  
>  
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Why arn't all options local?

iler.ml
On 4/5/06, Suresh Govindachar <[hidden email]> wrote:
> I don't
>   mean why aren't all options set using setlocal; I mean why aren't
>   all options restrictable to being local.
Let's take couple of  examples:
1) 'set columns', 'set lines'. How can those be local ?
A: They can't be.
2) How can 'set term'  be local ? It can't be

So, I think, you must be specific: if you can name option xxx
that you think it must be local but it isn't, why don't you
ask specifically 'why option xxx isn't local ?'

Yakov
Reply | Threaded
Open this post in threaded view
|

RE: Why arn't all options local?

Suresh Govindachar`
 
  >  Yakov Lerner Sent April 05, 2006 7:34 AM
  >
  > On 4/5/06, Suresh Govindachar <[hidden email]> wrote:
  >
  >> I don't mean why aren't all options set using setlocal; I mean
  >> why aren't all options restrictable to being local.
  >
  > Let's take couple of examples:
  > 1) 'set columns', 'set lines'. How can those be local ?
  > A: They can't be.
  > 2) How can 'set term' be local ? It can't be
   
  Thanks for these examples.

  > So, I think, you must be specific: if you can name option xxx
  > that you think it must be local but it isn't, why don't you ask
  > specifically 'why option xxx isn't local ?'
 
  wrapscan
 
  --Suresh


Reply | Threaded
Open this post in threaded view
|

Re: Why arn't all options local?

iler.ml
On 4/5/06, Suresh Govindachar <[hidden email]> wrote:

>
>   >  Yakov Lerner Sent April 05, 2006 7:34 AM
>   >
>   > On 4/5/06, Suresh Govindachar <[hidden email]> wrote:
>   >
>   >> I don't mean why aren't all options set using setlocal; I mean
>   >> why aren't all options restrictable to being local.
>   >
>   > Let's take couple of examples:
>   > 1) 'set columns', 'set lines'. How can those be local ?
>   > A: They can't be.
>   > 2) How can 'set term' be local ? It can't be
>
>   Thanks for these examples.
>
>   > So, I think, you must be specific: if you can name option xxx
>   > that you think it must be local but it isn't, why don't you ask
>   > specifically 'why option xxx isn't local ?'
>
>   wrapscan
Are you asking from the position of interactive user, or
from the position of the plugin writer ?

As interactive user, I don't have problems with global
'wrapscan'. It's my(user) preference, I don't need it per-buffer.

Wrt plugin writing, I think there are several ways of writing
vimscript independent of 'ws' option. One is using search().
Another is save & restore value of &was around every /search
perfoemed by plugin. Maybe it complicates the plugin
a little. Althouth using search() doesn't complicate plugins,
does it ? Maybe local 'ws' would comlpicate interactive usage
a little. It's hard to say. Maybe there is another reason 'ws' is global
only.

Yakov
Reply | Threaded
Open this post in threaded view
|

Re: Why arn't all options local?

Christian Ebert
In reply to this post by Eric Arnold
* Eric Arnold on Wednesday, April 05, 2006 at 03:23:25 -0700:
> I'm assuming the calendar script is using nowrapscan because it can't guarantee
> that the calendar will fit into the window.  The program might be re-written to
> make sure that it accounts for the window width, if that's even desired, but it
> would be simpler in the long run to have it save and restore the value of
> &wrapscan in autocommand functions for WinEnter and WinLeave, etc.

As far as I understand the code version 1.4a of calendar.vim does
just that with auto BufEnter and BufLeave respectively.

c
--
_B A U S T E L L E N_ lesen!  --->> <http://www.blacktrash.org/baustellen.html>
Reply | Threaded
Open this post in threaded view
|

RE: Why arn't all options local?

Eric Arnold
In reply to this post by Suresh Govindachar`

Some options, like the terminal type, only make sense as globals.

You're right that there is no reason they shouldn't be local+global, but I
think you missed the point of my last post.  The reason they aren't all local
is that it takes development time, and they aren't a priority.  So, the point
is that that's just life!  Ya gets what ya gets.

As the releases move forward, we've seen a trickle of options going
local+global

--- Suresh Govindachar <[hidden email]> wrote:

>
>
>   I don't understand the following:  "Some [options] should be
>   global, actually, but there are some local options that one might
>   wish were green."
>
>   My understanding is that an option that can be restricted to being
>   local is local only if set with :setlocal.  And when one uses just
>   :set to set the value of an option that can be restricted to being
>   local, it in fact is set globally.
>
>   So any option can always be set globally;  but not all options can
>   be set only locally.  
>
>   So asking "why aren't all options local"
>   is NOT like asking "why aren't all M&Ms green?"
>
>   Since making every option locally settable does not restrict
>   anything, I ask again:  why aren't all options local?  (I don't
>   mean why aren't all options set using setlocal; I mean why aren't
>   all options restrictable to being local.)
>  
>   --Suresh
>
>  
>
> -----Original Message-----
> From: Eric Arnold [mailto:[hidden email]]
> Sent: Wednesday, April 05, 2006 3:23 AM
> To: Suresh Govindachar; [hidden email]
> Cc: 'Yasuhiro Matsumoto'
> Subject: Re: Why arn't all options local?
>
>
> That's just like asking, why aren't all M&Ms green?  Some should be global,
> actually, but there are some local options that one
> might wish were green.
>
> Life is like a box of chocolates, ya know, and we're all more like Forest
> than we care to believe, except we don't have as much
> patience.
>
> I'm assuming the calendar script is using nowrapscan because it can't
> guarantee that the calendar will fit into the window.  The
> program might be re-written to make sure that it accounts for the window
> width, if that's even desired, but it would be simpler in
> the long run to have it save and restore the value of &wrapscan in
> autocommand functions for WinEnter and WinLeave, etc.
>
>
>
>
> --- Suresh Govindachar <[hidden email]> wrote:
>
> >  
> > Hello,
> >
> >   Why aren't all options local?  Is it that an option is made global
> >   if no plugin can ever be written which depends on that option
> >   having a particular value?
> >    
> >   For some reason, Yasuhiro Matsumoto, the author of Calendar.vim,
> >   requires that the global option wrapscan have the non-default value
> >   of off.  So the use of Calendar.vim messes things up for those who
> >   are used to having wrapscan on.
> >
> >   Do anyone know why exactly Calendar.vim needs wrapscan to be off?
> >   Can Calendar.vim be re-written without relying on global options
> >   having a particular value?
> >
> >   Thanks,
> >
> >   --Suresh
> >  
> >  
> >  
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Why arn't all options local?

Hari Krishna Dara
In reply to this post by Suresh Govindachar`

On Wed, 5 Apr 2006 at 7:10am, Suresh Govindachar wrote:

>
>
>   I don't understand the following:  "Some [options] should be
>   global, actually, but there are some local options that one might
>   wish were green."
>
>   My understanding is that an option that can be restricted to being
>   local is local only if set with :setlocal.  And when one uses just
>   :set to set the value of an option that can be restricted to being
>   local, it in fact is set globally.
>
>   So any option can always be set globally;  but not all options can
>   be set only locally.
>
>   So asking "why aren't all options local"
>   is NOT like asking "why aren't all M&Ms green?"
>
>   Since making every option locally settable does not restrict
>   anything, I ask again:  why aren't all options local?  (I don't
>   mean why aren't all options set using setlocal; I mean why aren't
>   all options restrictable to being local.)
>
>   --Suresh
>
>
>
> -----Original Message-----
> From: Eric Arnold [mailto:[hidden email]]
> Sent: Wednesday, April 05, 2006 3:23 AM
> To: Suresh Govindachar; [hidden email]
> Cc: 'Yasuhiro Matsumoto'
> Subject: Re: Why arn't all options local?
>
>
> That's just like asking, why aren't all M&Ms green?  Some should be global,
actually, but there are some local options that one
> might wish were green.
>
> Life is like a box of chocolates, ya know, and we're all more like Forest
than we care to believe, except we don't have as much
> patience.
>
> I'm assuming the calendar script is using nowrapscan because it can't
guarantee that the calendar will fit into the window.  The
> program might be re-written to make sure that it accounts for the window
width, if that's even desired, but it would be simpler in
> the long run to have it save and restore the value of &wrapscan in
autocommand functions for WinEnter and WinLeave, etc.
>

Just for the matter of fact, there are options that can ONLY be set
local to a buffer, such as 'filetype', so not all local options can be
set globally using :set instead of :setlocal. If you use :set, it still
means :setlocal for those options.

--
HTH,
Hari

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

RE: Why arn't all options local?

Eric Arnold


--- Hari Krishna Dara <[hidden email]> wrote:

> [...]
> Just for the matter of fact, there are options that can ONLY be set
> local to a buffer, such as 'filetype', so not all local options can be
> set globally using :set instead of :setlocal. If you use :set, it still
> means :setlocal for those options.

Hmm. As I understand it the example of "filetype" could indeed be made global,
and you would be quite happy using it that way if you were content to only edit
files of a single type at a time.  I most other examples follow this rule:  you
could make them global only, but they will limit the usefulness of the program.
 That is actually what is going on here in a small scale.  There are options
who's global only behavior is limiting, it's just a matter of exactly how
limiting which spurs development changes.

I'm having a hard time coming up with an example of a global option which you
couldn't argue some obscure case for, including terminal, GUI, and others since
I can image, for example, that a user might be developing a terminal emulator
that would handle different terms, and he wanted to test them in separate
buffers.  I think Bram is unlikely to revamp half his options for that guy :-)

On the other hand.  If a change could be made inside Vim where *all* options
can be set globally or locally, then it would just be a matter of setting them
intelligently.



Reply | Threaded
Open this post in threaded view
|

Re: Why arn't all options local?

iler.ml
On 4/6/06, Eric Arnold <[hidden email]> wrote:
> I'm having a hard time coming up with an example of a global option which you
> couldn't argue some obscure case for, including terminal, GUI, and others since
> I can image, for example, that a user might be developing a terminal emulator
> that would handle different terms, and he wanted to test them in separate
> buffers.

I can't believe you ain't serious. Is it April 1st yet ? If you're asking for
'setlocal term', then I'm asking for separate buffers/subwindows to run on
separate OSes.  In the end, I'm debugging kernel code and while one
vim's subwindow  is rebooting, I want to continue editing in another
vim'w subwindow. Simply 'setlocal host=HOSTNAME'. Easy.

Yakov
Reply | Threaded
Open this post in threaded view
|

Re: Why arn't all options local?

Matthew Winn
On Thu, Apr 06, 2006 at 10:58:09AM +0300, Yakov Lerner wrote:

> On 4/6/06, Eric Arnold <[hidden email]> wrote:
> > I'm having a hard time coming up with an example of a global option which you
> > couldn't argue some obscure case for, including terminal, GUI, and others since
> > I can image, for example, that a user might be developing a terminal emulator
> > that would handle different terms, and he wanted to test them in separate
> > buffers.
>
> I can't believe you ain't serious. Is it April 1st yet ? If you're asking for
> 'setlocal term', then I'm asking for separate buffers/subwindows to run on
> separate OSes.  In the end, I'm debugging kernel code and while one
> vim's subwindow  is rebooting, I want to continue editing in another
> vim'w subwindow. Simply 'setlocal host=HOSTNAME'. Easy.

If you're going to have that then I want the ability to "set columns"
on a line-by-line basis.  I like triangles, and I want to be able to
edit in one:

    |\
    |I\
    |f \
    |you\
    |'re \
    |going\
    | to ha\
    |ve that\
    |:w      \
    ----------

Furthermore, if I have a file containing lines of different lengths why
should my need to view the long lines mean that I have to conceal the
desktop behind the empty space to the right of the short lines?  What
a waste of limited screen real estate.

--
Matthew Winn ([hidden email])
Reply | Threaded
Open this post in threaded view
|

Re: Why arn't all options local?

Eric Arnold
In reply to this post by iler.ml


Definition:

\Hy*per"bo*le\, n. [L., fr. Gr?, prop., an
overshooting, excess, fr. Gr. ? to throw over or beyond;
"ype`r over + ? to throw. See {Hyper-}, {Parable}, and cf.
{Hyperbola}.] (Rhet.)
A figure of speech in which the expression is an evident
exaggeration of the meaning intended to be conveyed, or by
which things are represented as much greater or less, better
or worse, than they really are; a statement exaggerated
fancifully, through excitement, or for effect.


:-)




--- Yakov Lerner <[hidden email]> wrote:

> On 4/6/06, Eric Arnold <[hidden email]> wrote:
> > I'm having a hard time coming up with an example of a global option which
> you
> > couldn't argue some obscure case for, including terminal, GUI, and others
> since
> > I can image, for example, that a user might be developing a terminal
> emulator
> > that would handle different terms, and he wanted to test them in separate
> > buffers.
>
> I can't believe you ain't serious. Is it April 1st yet ? If you're asking for
> 'setlocal term', then I'm asking for separate buffers/subwindows to run on
> separate OSes.  In the end, I'm debugging kernel code and while one
> vim's subwindow  is rebooting, I want to continue editing in another
> vim'w subwindow. Simply 'setlocal host=HOSTNAME'. Easy.
>
> Yakov
>