On 2010-04-30, Nathan Neff wrote:
> Currently, I have the status line displaying Vim's
> current working directory.
>
> I like having the cwd on the right side of the status line.
>
> I would like to align the cwd as far left to the separator
> as possible, so that it doesn't shift around when I navigate
> from column 1 to column 10, (likewise row 1 to row 10).
>
> I've tried many variations of the sprintf syntax, and can't get
> the current working directory not to shift around depending on the
> line # and col # that I'm on.
>
> Any ideas?
>
> function! MyStatusLine()
>     let l:statline = '%='                     "left/right separator
>     let l:statline = l:statline . '%-20{" | " . fnamemodify(getcwd(),
> ":t") . " | "}'
>     let l:statline = l:statline . '%l, %v of %L'      "cursor line/total lines
>     return l:statline
> endfunction
>
> " Status Line
> set laststatus=2
> set statusline=%!MyStatusLine()

It's been a while since I wrote this, so I don't remember off-hand
what all the format specifiers mean, but this 'statusline' looks
like the default 'statusline' with 'ruler' set and with the addition
of the name of the current function displayed at the right side of
the status line, just left of the line and column numbers.  The
function name--the return value of TagName()--does not shift when
the line and column numbers change.  You should be able to replace
TagName() with a function that returns the cwd and get the behavior
you want.

     let &statusline='%<%f %(%h%m%r %)%=%{TagName()} %-15.15(%l,%c%V%)%P'

Regards,
Gary

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Wow, thank you so much, sc!
It works!

Ray

On Fri, Apr 30, 2010 at 5:39 PM, sc <toothpik@...> wrote:
> On Friday 30 April 2010 10:13:26 am C. Jiang wrote:
>
>> I am running Windows 7. In it I run a VMware (Fedora linux)
>>  where my projects files are. I mapped the projects folder in
>>  windows 7.  The Vim is installed on windows 7 and I can use
>>  the mouse to point a file and right click mouse and in the
>>  popup menu, use 'Edit with Vim', 'Edit with existing vim -
>>  myopenedfile.txt'.
>>
>> The issue is:
>>
>> If i open just one file, or open files one by one, ':pwd' in
>>  vim will show me the correct path where the current file is;
>>
>> But if I highlight 2 or more files and right click and open
>>  them with 'open with a single vim', after I check ':pwd' in
>>  vim, it shows c:\windows\system32.
>>
>> Since my tags for the projects is in the top directory of the
>> projects, vim won't find the tag file any more.
>
> the simplest will be to
>
>    :set autochdir
>
> in your _vimrc, although this setting has its detractors, and
> some plugins misbehave with it set, or did in the past -- i edit
> files all over the place and have come to rely on the fact that
> no matter where i am, :pwd is always current to the file i am
> editing
>
> sc
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01/05/10 05:00, stosss wrote:
> On Fri, Apr 30, 2010 at 10:57 PM, stosss<stosss@...>  wrote:
>> On Fri, Apr 30, 2010 at 10:46 PM, sc<toothpik@...>  wrote:
>>> On Friday 30 April 2010 9:17:57 pm stosss wrote:
>>>
>>>> I went to :he y and I see:
>>>> :[range]y[ank] [x]    Yank [range] lines [into register x].
>>>>
>>>> so I do:
>>>> :'y,'zy"c
>>>>
>>>> It did not give me an error, but when I type:
>>>>
>>>> "cP
>>>>
>>>> I don't get what I yanked.
>>>>
>>>> What I am doing wrong?
>>>> What register is my yanked text in?
>>>
>>> i think it'll be in the un-named register (")
>>
>> Yes typing P dumped my text into the file.
>>
>>> i think what you wanted to do was
>>>
>>>     :'y,'zyc
>>
>> This produced the E492 error
>>
>> So how does range yank into a named register work?
>
> Answering my own question.
>
> This is the correct way:
>
> :'y,'zy c
>
> There has to be a space between yank and the register.
>

Yes, so Vim knows where the ex-command name ends (otherwise it'll think
that you want some :yc command,and complain that there is none.

In your initial command (with y"c), Vim sees the double-quote and
anything following it as a comment, and therefore uses the "unnamed"
register, ats it always does when a register is expected and you don't
name one.


Best regards,
Tony.
--
"What is the Nature of God?"

      CLICK...CLICK...WHIRRR...CLICK...=BEEP!=
      1 QT. SOUR CREAM
      1 TSP. SAUERKRAUT
      1/2 CUT CHIVES.
      STIR AND SPRINKLE WITH BACON BITS.

"I've just GOT to start labeling my software..."
		 -- Bloom County

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Thu, Apr 29, 2010 at 09:47:37PM -0400, Steve Bertrand wrote:
>...however, in reports, emails and/or bug notifications, it will often
>look like this:
>
>    $self->function_orders();
>
>  my $type    = $params->{ type };
>  		  my $data    = $params->{ data };
>   my $error   = $params->{ error };
>
>           my $vardb    = ISP::Vars->new();
>
>     # die right off the bat if either data is an invalid type,
> # or no $error obj was passed in
>
>    		 if ( ! defined $error ) {
>    $error = ISP::Error->new();
>        $error->bad_api();
>    	 }
>
>....which makes it difficult (ie. *very* frustrating) to review down the
>road.

Following on from Marc's reply, you might consider running your code through
perltidy before committing it. By default it will convert any tabs to spaces and
tidy the code for you, although you can change the default behaviour.

--

.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

If I open the same file in two gvim sessions, and modify and write the
file in one session, the other session will be notified. However, this
is not true for vim. Is there a way to configure vim do the same thing?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01/05/10 16:30, Peng Yu wrote:
> If I open the same file in two gvim sessions, and modify and write the
> file in one session, the other session will be notified. However, this
> is not true for vim. Is there a way to configure vim do the same thing?
>

See :help 'autoread'

Note that Vim doesn't know that "the other program" which modified the
file is another instance of Vim -- it could be anything. Also, this
won't work if Vim notices that a 'modified' file has also been modified
somewhere else: in this case you will have to decide which changes to trash.

Finer control (but also more occasions to shoot yourself in the foot) is
afforded by the FileChangedShell autocommand event.


Best regards,
Tony.
--
Bizoos, n.:
	 The millions of tiny individual bumps that make up a
basketball.
		 -- Rich Hall, "Sniglets"

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

> On May 1, 3:10 pm, Ritmo2k <jcas...@...> wrote:
>
> > no backups are made in /tmp? How do you control this?
>
> The 'backupskip' option; the default value includes /tmp/*.
>
> Please excuse me if I'm wrong, but you seem unaware how good vim's
> help is.  Mucking around with the whatever option, it's a good idea to
> try
>
> :help 'whatever
>
> (that's a single quote).  :help 'backup tells about backupskip, and
> hyper-links to it.
>
> Regards, John

You're right, but my :set _does not_ indicate this value set, so when
I
looked through it to read up on the options, obviously I didn't see
this &
never looked into it. Reading :help backup suggests its activated by a
pattern, but as its not defined in :set or :let and neither my /etc/
vimrc or
/etc/virc or ~/.vimrc contain it, I am wondering how its getting set?
Are
there ways to compile defaults into vim? If so how does one display
these
build time options?

Thanks for being patient,
jlc

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

I am having a problem with a vim color file.  It colors everything the way I
want it, except for Braces.  I set this color file as the default to use in
my .vimrc file.  When I go in to edit a file, say a java file, however,
everything colorizes perfectly, but the braces, brackets, curly brackets,
and parenthesis don't color.  To get them to color, I have to run the color
command with the appropriate color filename.  Can anyone help me out with
this?  I'm assuming it's a syntax error in the color file.  The file is:

" peterv0.vim - Vim color file
   2 " Last Change: 2010 May 01
   3 "
   4 set background=dark
   5 hi clear
   6 if exists("syntax_on")
   7   syntax reset
   8 endif
   9 let g:colors_name = "peterv0"
  10 "
  11 syn match Braces display '[{}()\[\]]'
  12 hi Braces ctermfg=yellow
  13 "
  14 hi Cursor       ctermfg=black ctermbg=white
  15 hi CursorLine   cterm=underline,bold ctermbg=black ctermfg=yellow
  16 hi DiffAdd      ctermbg=blue  ctermfg=black
  17 hi DiffChange   ctermbg=darkGreen ctermfg=black
  18 hi DiffDelete   ctermbg=cyan  ctermfg=black
  19 hi DiffText     ctermbg=lightGreen ctermfg=black
  20 hi ErrorMsg     ctermfg=lightRed
  21 hi FoldColumn   ctermbg=gray  ctermfg=black
  22 hi Folded       ctermbg=yellow  ctermfg=black
  23 hi IncSearch    ctermfg=black ctermbg=darkYellow
  24 hi LineNr       ctermfg=cyan
  25 hi ModeMsg      ctermfg=yellow
  26 hi MoreMsg      ctermfg=yellow
  27 hi NonText      ctermfg=lightMagenta
  28 hi Normal       ctermfg=white ctermbg=black
29 hi Search       ctermfg=white ctermbg=red
  30 hi StatusLine   cterm=bold ctermfg=white ctermbg=LightGreen
  31 hi StatusLineNC ctermfg=black  ctermbg=blue
  32 hi Todo         ctermfg=black ctermbg=darkYellow
  33 hi Underlined   ctermfg=cyan cterm=underline
  34 hi VertSplit    ctermfg=blue ctermbg=blue
  35 hi Visual       ctermfg=black ctermbg=darkCyan term=reverse
  36 hi WarningMsg   ctermfg=cyan
  37 hi cIf0         ctermfg=gray
  38 hi comment      ctermfg=Magenta
  39 hi constant     ctermfg=cyan
  40 hi identifier   ctermfg=red
  41 hi label        ctermfg=yellow
  42 hi operator     ctermfg=lightGreen
  43 hi preproc      term=underline ctermfg=LightBlue
  44 hi Special      ctermfg=lightMagenta ctermbg=DarkGreen
  45
  46 hi statement    ctermfg=green
  47 hi title        cterm=bold
  48 hi type         ctermfg=lightRed ctermbg=None

I'd really appreciate help with this.

--
View this message in context:
http://old.nabble.com/Problem-with-VIM-syntax-coloring-tp28421691p28421691.html
Sent from the Vim - General mailing list archive at Nabble.com.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 05/03/10 01:35, Charles E Campbell Jr wrote:
> rameo wrote:
[...]
>> How can I resolve this problem?
>
> The problem appears to be that you're not getting the trailing slashes
> (see :help netrw-dirlist). The trailing slash indicates to netrw that a
> directory listing rather than a file transfer is wanted. Remote
> directory listings should have slashes for directories; if you're having
> problems in not having that trailing slash, then there's either an odd
> ftp client or a server. To track down such a problem -- see :help
> netrw-debug. Is it a M$ server?
[...]

Personally I get the slashes, except for softlinks to directories. In
that case the server sends a line like (e.g. for the entry for
"mozilla.org" in the pub/ directory of ftp.mozilla.org):

lrwxrwxrwx    1 ftp      ftp             1 Sep 14  2006 mozilla.org -> .

but netrw (in "long" listing mode) changes that to

mozilla.org lrwxrwxrwx    1 ftp      ftp             1 Sep 14  2006

removing the ' -> ' and all that follows it. I can still see that that
line is for a link (by the l as initial permission), but netrw doesn't
tell me what it links to. Also, when sorting by name, the link is not
segregated to the top of the list, even when directories are.

BTW I'm still getting "Invalid command", the first time only, when
browsing a directory. As a workaround I immediately use ":view" (with no
quotes and no aguments) to get the listing. (Could that be related to
the fact that no username/password is required, even though the server
asks for it with a 331 message after the motd? I have a .netrc file.)

A few days ago I got disconnected from the other end (36-hour silent
ADSL connection expiration from my ISP); netrw could not go on browsing
the same site (after reconnecting the ADSL interface). I had to browse a
different FTP server and come back before netrw could go on browsing the
"interrupted" one. How do I get netrw to "reopen" the current server and
directory?


Best regards,
Tony.
--
You know you have a small apartment when Rice Krispies echo.
		 -- S. Rickly Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On May 1, 10:19 am, Tony Mechelynck <antoine.mechely...@...>
wrote:
> On 01/05/10 16:30, Peng Yu wrote:
>
> > If I open the same file in two gvim sessions, and modify and write the
> > file in one session, the other session will be notified. However, this
> > is not true for vim. Is there a way to configure vim do the same thing?
>
> See :help 'autoread'
>
> Note that Vim doesn't know that "the other program" which modified the
> file is another instance of Vim -- it could be anything. Also, this
> won't work if Vim notices that a 'modified' file has also been modified
> somewhere else: in this case you will have to decide which changes to trash.
>
> Finer control (but also more occasions to shoot yourself in the foot) is
> afforded by the FileChangedShell autocommand event.

I type :set autoread in both vim session starting from genome-
terminal. Then, I write to the file from one vim session, the other
vim doesn't know the file has been changed. However, gvim knows a file
has been changed. Therefore, I doubt that it is because of some
configuration problem.

Then, what is the different between gvim and vim cause the difference
in this behavior?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01/05/10 20:38, Peng Yu wrote:
>
>
> On May 1, 10:19 am, Tony Mechelynck<antoine.mechely...@...>
> wrote:
>> On 01/05/10 16:30, Peng Yu wrote:
>>
>>> If I open the same file in two gvim sessions, and modify and write the
>>> file in one session, the other session will be notified. However, this
>>> is not true for vim. Is there a way to configure vim do the same thing?
>>
>> See :help 'autoread'
>>
>> Note that Vim doesn't know that "the other program" which modified the
>> file is another instance of Vim -- it could be anything. Also, this
>> won't work if Vim notices that a 'modified' file has also been modified
>> somewhere else: in this case you will have to decide which changes to trash.
>>
>> Finer control (but also more occasions to shoot yourself in the foot) is
>> afforded by the FileChangedShell autocommand event.
>
> I type :set autoread in both vim session starting from genome-
> terminal. Then, I write to the file from one vim session, the other
> vim doesn't know the file has been changed. However, gvim knows a file
> has been changed. Therefore, I doubt that it is because of some
> configuration problem.
>
> Then, what is the different between gvim and vim cause the difference
> in this behavior?
>

See :help FileChangedShell

gvim checks the file's timestamp when it regains input focus. Most
console versions cannot detect that they have lost or gained focus, see
":help FocusGained" and ":help FocusLost".

The command
	 :checktime
(q.v.) will also trigger the check.


Best regards,
Tony.
--
ARTHUR:    Well, it doesn't matter.  Will you go and tell your master that
             Arthur from the Court of Camelot is here.
GUARD #1:  Listen, in order to maintain air-speed velocity, a swallow
             needs to beat its wings 43 times every second, right?
ARTHUR:    Please!
                                    The Quest for the Holy Grail (Monty
Python)

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Thu 29 Apr 2010 at 20:06:47 PDT stosss wrote:
>On Thu, Apr 29, 2010 at 10:19 PM, Tony Mechelynck
><antoine.mechelynck@...> wrote:
>>
>> Of course, if you're already over 13 (I'll be 60 next January ;-) ) the
>> birth date doesn't have to be bogus. :-)
>
>You are less then 6 years my senior.

He's only eight months older than me.

I wonder whether this is typical for vim users?  Are we mostly a bunch
of aging baby-boomers who learned to use computers back in the 1970's?

To put it another way, is vim like a Volkswagen Beetle that we still
drive, partly because we've never had a car we liked better and partly
because it reminds us of our youth?

- Charlie

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01/05/10 18:01, peterv6 wrote:
>
> I am having a problem with a vim color file.  It colors everything the way I
> want it, except for Braces.  I set this color file as the default to use in
> my .vimrc file.  When I go in to edit a file, say a java file, however,
> everything colorizes perfectly, but the braces, brackets, curly brackets,
> and parenthesis don't color.  To get them to color, I have to run the color
> command with the appropriate color filename.  Can anyone help me out with
> this?  I'm assuming it's a syntax error in the color file.  The file is:
>
> " peterv0.vim - Vim color file
>    2 " Last Change: 2010 May 01
>    3 "
>    4 set background=dark
>    5 hi clear
>    6 if exists("syntax_on")
>    7   syntax reset
>    8 endif
>    9 let g:colors_name = "peterv0"
>   10 "
>   11 syn match Braces display '[{}()\[\]]'
>   12 hi Braces ctermfg=yellow
>   13 "
>   14 hi Cursor       ctermfg=black ctermbg=white
>   15 hi CursorLine   cterm=underline,bold ctermbg=black ctermfg=yellow
>   16 hi DiffAdd      ctermbg=blue  ctermfg=black
>   17 hi DiffChange   ctermbg=darkGreen ctermfg=black
>   18 hi DiffDelete   ctermbg=cyan  ctermfg=black
>   19 hi DiffText     ctermbg=lightGreen ctermfg=black
>   20 hi ErrorMsg     ctermfg=lightRed
>   21 hi FoldColumn   ctermbg=gray  ctermfg=black
>   22 hi Folded       ctermbg=yellow  ctermfg=black
>   23 hi IncSearch    ctermfg=black ctermbg=darkYellow
>   24 hi LineNr       ctermfg=cyan
>   25 hi ModeMsg      ctermfg=yellow
>   26 hi MoreMsg      ctermfg=yellow
>   27 hi NonText      ctermfg=lightMagenta
>   28 hi Normal       ctermfg=white ctermbg=black
> 29 hi Search       ctermfg=white ctermbg=red
>   30 hi StatusLine   cterm=bold ctermfg=white ctermbg=LightGreen
>   31 hi StatusLineNC ctermfg=black  ctermbg=blue
>   32 hi Todo         ctermfg=black ctermbg=darkYellow
>   33 hi Underlined   ctermfg=cyan cterm=underline
>   34 hi VertSplit    ctermfg=blue ctermbg=blue
>   35 hi Visual       ctermfg=black ctermbg=darkCyan term=reverse
>   36 hi WarningMsg   ctermfg=cyan
>   37 hi cIf0         ctermfg=gray
>   38 hi comment      ctermfg=Magenta
>   39 hi constant     ctermfg=cyan
>   40 hi identifier   ctermfg=red
>   41 hi label        ctermfg=yellow
>   42 hi operator     ctermfg=lightGreen
>   43 hi preproc      term=underline ctermfg=LightBlue
>   44 hi Special      ctermfg=lightMagenta ctermbg=DarkGreen
>   45
>   46 hi statement    ctermfg=green
>   47 hi title        cterm=bold
>   48 hi type         ctermfg=lightRed ctermbg=None
>
> I'd really appreciate help with this.
>

The place for a ":syn match" command is not in a colorscheme (which is
only sourced once, when the ":colorscheme" command is issued, and maybe
again if you set ":syntax on" after using "syntax off"), but in a syntax
script (which is sourced every time a file of the concerned filetype is
opened). If you want to apply that Braces synmatch to all files, then
you might add to your vimrc the following (untested)

if has('autocmd') && has('syntax')
	 au VimEnter * au Syntax * syn match Braces display '[]{}()[]'
endif

while keeping the Braces highlight command in your colorscheme.
Otherwise that :syn match command should go (I think) in
~/vimfiles/after/syntax/whatever.vim (on Windows), or
~/.vim/after/syntax/whatever.vim (on Unix), replacing "whatever" by the
syntax type (which is usually the filetype).


Best regards,
Tony.
--
I have great faith in fools -- self confidence my friends call it.
		 -- Edgar Allan Poe

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Sat, May 1, 2010 at 3:50 PM, Charlie Kester <corky1951@...> wrote:
> On Thu 29 Apr 2010 at 20:06:47 PDT stosss wrote:
>>
>> On Thu, Apr 29, 2010 at 10:19 PM, Tony Mechelynck
>> <antoine.mechelynck@...> wrote:
>>>
>>> Of course, if you're already over 13 (I'll be 60 next January ;-) ) the
>>> birth date doesn't have to be bogus. :-)
>>
>> You are less then 6 years my senior.
>
> He's only eight months older than me.
>
> I wonder whether this is typical for vim users?  Are we mostly a bunch
> of aging baby-boomers who learned to use computers back in the 1970's?
>
> To put it another way, is vim like a Volkswagen Beetle that we still
> drive, partly because we've never had a car we liked better and partly
> because it reminds us of our youth?

Hey! I resemble that remark! :) I'm not old! Just ask my kids. :)

That means you were born the same month I was born, but five years earlier.

--
A government big enough to give you everything you want, is strong
enough to take everything you have.
-Thomas Jefferson

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 05/01/2010 02:50 PM, Charlie Kester wrote:
>>> Of course, if you're already over 13 (I'll be 60 next January ;-) ) the
>>> birth date doesn't have to be bogus. :-)
>>
>> You are less then 6 years my senior.
>
> He's only eight months older than me.
>
> I wonder whether this is typical for vim users?  Are we mostly a bunch
> of aging baby-boomers who learned to use computers back in the 1970's?

Some of us are only a little more than half that age...

But I think the typically unifying factor for vim users is
"wanting to edit text efficiently", not "used punched cards/tape"
or "loaded my operating system & software from tape" :-)

-tim




--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01/05/10 21:50, Charlie Kester wrote:
> On Thu 29 Apr 2010 at 20:06:47 PDT stosss wrote:
>> On Thu, Apr 29, 2010 at 10:19 PM, Tony Mechelynck
>> <antoine.mechelynck@...> wrote:
>>>
>>> Of course, if you're already over 13 (I'll be 60 next January ;-) ) the
>>> birth date doesn't have to be bogus. :-)
>>
>> You are less then 6 years my senior.
>
> He's only eight months older than me.
>
> I wonder whether this is typical for vim users? Are we mostly a bunch
> of aging baby-boomers who learned to use computers back in the 1970's?
>
> To put it another way, is vim like a Volkswagen Beetle that we still
> drive, partly because we've never had a car we liked better and partly
> because it reminds us of our youth?
>
> - Charlie
>

I only learnt Vim a few years ago, the current version was 6.1 IIRC; I
think the first file I edited with it was /etc/lilo.conf (that I don't
use anymore). Forty years ago I would edit source files by punching onto
Hollerith cards replacement lines which were then added between or
instead of existing lines, according to their line number in columns 1-6
(for COBOL) or 1-5 (for assembly or job-control languages), into source
tapes by a program named UPDATE (that 6-bit machine's 64-character set
included no lowercase). ("Delete" lines, either by range or for single
lines, were of course also foreseen.)

For me, UPDATE was the bicycle, Notepad was the Citroën 2CV, and gvim is
the limo.


Best regards,
Tony.
--
Religion has done love a great service by making it a sin.
		 -- Anatole France

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01/05/10 22:26, stosss wrote:
> On Sat, May 1, 2010 at 3:50 PM, Charlie Kester<corky1951@...>  wrote:
>> On Thu 29 Apr 2010 at 20:06:47 PDT stosss wrote:
>>>
>>> On Thu, Apr 29, 2010 at 10:19 PM, Tony Mechelynck
>>> <antoine.mechelynck@...>  wrote:
>>>>
>>>> Of course, if you're already over 13 (I'll be 60 next January ;-) ) the
>>>> birth date doesn't have to be bogus. :-)
>>>
>>> You are less then 6 years my senior.
>>
>> He's only eight months older than me.
>>
>> I wonder whether this is typical for vim users?  Are we mostly a bunch
>> of aging baby-boomers who learned to use computers back in the 1970's?
>>
>> To put it another way, is vim like a Volkswagen Beetle that we still
>> drive, partly because we've never had a car we liked better and partly
>> because it reminds us of our youth?
>
> Hey! I resemble that remark! :) I'm not old! Just ask my kids. :)

You "look like" that remark? Really? Or maybe do you "resent" (feel
indignation at) it? Or was the pun intended?

>
> That means you were born the same month I was born, but five years earlier.
>

Best regards,
Tony.
--
"Tom Hayden is the kind of politician who gives opportunism a bad
name."
		 -- Gore Vidal

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01/05/10 22:30, Tim Chase wrote:
[...]
> But I think the typically unifying factor for vim users is "wanting to
> edit text efficiently", not "used punched cards/tape" or "loaded my
> operating system & software from tape" :-)
>
> -tim
>

As one of my pseudo-random sigs say, in a quote attributed to Ashley
Montague: “The idea is to die young... as late as possible.”


Best regards,
Tony.
--
You have the capacity to learn from mistakes.  You'll learn a lot
today.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 2010-05-01, Ritmo2k wrote:
> > On May 1, 3:10 pm, Ritmo2k <jcas...@...> wrote:
> >
> > > no backups are made in /tmp? How do you control this?
> >
> > The 'backupskip' option; the default value includes /tmp/*.
> >
> > Please excuse me if I'm wrong, but you seem unaware how good vim's
> > help is.  Mucking around with the whatever option, it's a good idea to
> > try
> >
> > :help 'whatever
> >
> > (that's a single quote).  :help 'backup tells about backupskip, and
> > hyper-links to it.
> >
> > Regards, John
>
> You're right, but my :set _does not_ indicate this value set, so
> when I looked through it to read up on the options, obviously I
> didn't see this & never looked into it. Reading :help backup
> suggests its activated by a pattern, but as its not defined in
> :set or :let and neither my /etc/ vimrc or /etc/virc or ~/.vimrc
> contain it, I am wondering how its getting set?
> Are there ways to compile defaults into vim? If so how does one
> display these build time options?

From within Vim,

     :version

From the shell command line,

     vim --version

":help backupskip" says,

     {not available when compiled without the |+wildignore| feature}

Maybe one of your Vims was compiled without the +wildignore feature
and the other was compiled with it.

See also

     :help :version

Regards,
Gary

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

> ":help backupskip" says,
>
>     {not available when compiled without the |+wildignore| feature}

Ahh, so if not specified, it defaults to exclude the /tmp dirs.
adding 'set backupskip=' gets the behavior I wanted.

Thanks guys!

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 04/03/10 10:08, winterTTr wrote:
> I just want to check whether a autocmd group is empty and i want to
> remove it when it is empty.
> But I don't find the method or a way to do this.
>
> Is there a way to check whether a specific autocmd group is empty?
> Any suggestion is OK. Thanks.
>

I'm surprised that there has been no reply yet to this post.

To check if auto commands exist for a given group, I can imagine two
possibilities; you will have to experiment to see what works:

a) see ":help exists()" [near the end of the list]. I'm not sure this
allows you to test if autocommands are defined for a given group if you
don't know which patterns or events are possible in that group.

b) see ":help autocmd-list" and ":help :redir". Finding out that you got
an empty list may be tedious. Also the title may depend on your messages
language (see :help v:lang and what it resends to).


Best regards,
Tony.
--
GUARD #2:  It could be carried by an African swallow!
GUARD #1:  Oh, yeah, an African swallow maybe, but not a European swallow,
             that's my point.
GUARD #2:  Oh, yeah, I agree with that...
                                    The Quest for the Holy Grail (Monty
Python)

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

:new by default open a window above the current window. Is there a
command to open a new window below the current one?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 05/01/2010 05:59 PM, Peng Yu wrote:
> :new by default open a window above the current window. Is there a
> command to open a new window below the current one?

You can use

    :below new

which you can read about at

    :help :below

If you want it to always split below, you can investigate the
'splitbelow' option

    :help 'splitbelow'

which you can set in your vimrc so that new/split windows are
created below the current one instead of above it.  However, it's
easy enough to override with the ":bel" command.

-tim



--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 2010-05-01, Peng Yu <pengyu.ut@...> wrote:
> :new by default open a window above the current window. Is there a
> command to open a new window below the current one?

To do it once:

     :belowright new

To do it every time:

     :set splitbelow
     :new

See

     :help :belowright
     :help 'splitbelow'

Regards,
Gary

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On May 1, 6:13 pm, Tim Chase <v...@...> wrote:
> On 05/01/2010 05:59 PM, Peng Yu wrote:
>
> > :new by default open a window above the current window. Is there a
> > command to open a new window below the current one?
>
> You can use
>
>    :below new
>
> which you can read about at
>
>    :help :below
>
> If you want it to always split below, you can investigate the
> 'splitbelow' option
>
>    :help 'splitbelow'
>
> which you can set in your vimrc so that new/split windows are
> created below the current one instead of above it.  However, it's
> easy enough to override with the ":bel" command.

"open file under cursor
map <C-O> :exe "below new ".expand("<cfile>")<CR>
map <C-S-O> :exe "new ".expand("<cfile>")<CR>

I put the above comand in ~/.vimrc. I expect that ctrl+shift+o open a
new window above the current one and ctrl+o open a new window below
the current one. However, both of them open a new window above the
current one. Would you please let me know how to fix the first command?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Sat, May 1, 2010 at 3:30 PM, Tim Chase <vim@...> wrote:

> Some of us are only a little more than half that age...

And some of us less than 1/3 that age.

> But I think the typically unifying factor for vim users is "wanting to edit
> text efficiently", not "used punched cards/tape" or "loaded my operating
> system & software from tape" :-)

Agreed; I use vim because it's efficient and (on *nix), damn pretty.

--
Jeff Wheeler

Undergraduate, Electrical Engineering
University of Illinois at Urbana-Champaign

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Tony,
Thanks for the tip!  I put the syn braces into the java.vim file, and it works
perfectly!
Peter V.

On May 1, 2010, at 3:55 PM, Tony Mechelynck wrote:

> On 01/05/10 18:01, peterv6 wrote:
>>
>> I am having a problem with a vim color file.  It colors everything the way I
>> want it, except for Braces.  I set this color file as the default to use in
>> my .vimrc file.  When I go in to edit a file, say a java file, however,
>> everything colorizes perfectly, but the braces, brackets, curly brackets,
>> and parenthesis don't color.  To get them to color, I have to run the color
>> command with the appropriate color filename.  Can anyone help me out with
>> this?  I'm assuming it's a syntax error in the color file.  The file is:
>>
>> " peterv0.vim - Vim color file
>>   2 " Last Change: 2010 May 01
>>   3 "
>>   4 set background=dark
>>   5 hi clear
>>   6 if exists("syntax_on")
>>   7   syntax reset
>>   8 endif
>>   9 let g:colors_name = "peterv0"
>>  10 "
>>  11 syn match Braces display '[{}()\[\]]'
>>  12 hi Braces ctermfg=yellow
>>  13 "
>>  14 hi Cursor       ctermfg=black ctermbg=white
>>  15 hi CursorLine   cterm=underline,bold ctermbg=black ctermfg=yellow
>>  16 hi DiffAdd      ctermbg=blue  ctermfg=black
>>  17 hi DiffChange   ctermbg=darkGreen ctermfg=black
>>  18 hi DiffDelete   ctermbg=cyan  ctermfg=black
>>  19 hi DiffText     ctermbg=lightGreen ctermfg=black
>>  20 hi ErrorMsg     ctermfg=lightRed
>>  21 hi FoldColumn   ctermbg=gray  ctermfg=black
>>  22 hi Folded       ctermbg=yellow  ctermfg=black
>>  23 hi IncSearch    ctermfg=black ctermbg=darkYellow
>>  24 hi LineNr       ctermfg=cyan
>>  25 hi ModeMsg      ctermfg=yellow
>>  26 hi MoreMsg      ctermfg=yellow
>>  27 hi NonText      ctermfg=lightMagenta
>>  28 hi Normal       ctermfg=white ctermbg=black
>> 29 hi Search       ctermfg=white ctermbg=red
>>  30 hi StatusLine   cterm=bold ctermfg=white ctermbg=LightGreen
>>  31 hi StatusLineNC ctermfg=black  ctermbg=blue
>>  32 hi Todo         ctermfg=black ctermbg=darkYellow
>>  33 hi Underlined   ctermfg=cyan cterm=underline
>>  34 hi VertSplit    ctermfg=blue ctermbg=blue
>>  35 hi Visual       ctermfg=black ctermbg=darkCyan term=reverse
>>  36 hi WarningMsg   ctermfg=cyan
>>  37 hi cIf0         ctermfg=gray
>>  38 hi comment      ctermfg=Magenta
>>  39 hi constant     ctermfg=cyan
>>  40 hi identifier   ctermfg=red
>>  41 hi label        ctermfg=yellow
>>  42 hi operator     ctermfg=lightGreen
>>  43 hi preproc      term=underline ctermfg=LightBlue
>>  44 hi Special      ctermfg=lightMagenta ctermbg=DarkGreen
>>  45
>>  46 hi statement    ctermfg=green
>>  47 hi title        cterm=bold
>>  48 hi type         ctermfg=lightRed ctermbg=None
>>
>> I'd really appreciate help with this.
>>
>
> The place for a ":syn match" command is not in a colorscheme (which is only
sourced once, when the ":colorscheme" command is issued, and maybe again if you
set ":syntax on" after using "syntax off"), but in a syntax script (which is
sourced every time a file of the concerned filetype is opened). If you want to
apply that Braces synmatch to all files, then you might add to your vimrc the
following (untested)
>
> if has('autocmd') && has('syntax')
>  au VimEnter * au Syntax * syn match Braces display '[]{}()[]'
> endif
>
> while keeping the Braces highlight command in your colorscheme. Otherwise that
:syn match command should go (I think) in ~/vimfiles/after/syntax/whatever.vim
(on Windows), or ~/.vim/after/syntax/whatever.vim (on Unix), replacing
"whatever" by the syntax type (which is usually the filetype).
>
>
> Best regards,
> Tony.
> --
> I have great faith in fools -- self confidence my friends call it.
> 	 -- Edgar Allan Poe
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Sat, May 1, 2010 at 2:32 AM, Gary Johnson <garyjohn@...> wrote:
> On 2010-04-30, Nathan Neff wrote:
>> Currently, I have the status line displaying Vim's
>> current working directory.
>>
>> I like having the cwd on the right side of the status line.
>>
>> I would like to align the cwd as far left to the separator
>> as possible, so that it doesn't shift around when I navigate
>> from column 1 to column 10, (likewise row 1 to row 10).
>>
>> I've tried many variations of the sprintf syntax, and can't get
>> the current working directory not to shift around depending on the
>> line # and col # that I'm on.
>>
>> Any ideas?
>>
>> function! MyStatusLine()
>>     let l:statline = '%='                     "left/right separator
>>     let l:statline = l:statline . '%-20{" | " . fnamemodify(getcwd(),
>> ":t") . " | "}'
>>     let l:statline = l:statline . '%l, %v of %L'      "cursor line/total
lines
>>     return l:statline
>> endfunction
>>
>> " Status Line
>> set laststatus=2
>> set statusline=%!MyStatusLine()
>
> It's been a while since I wrote this, so I don't remember off-hand
> what all the format specifiers mean, but this 'statusline' looks
> like the default 'statusline' with 'ruler' set and with the addition
> of the name of the current function displayed at the right side of
> the status line, just left of the line and column numbers.  The
> function name--the return value of TagName()--does not shift when
> the line and column numbers change.  You should be able to replace
> TagName() with a function that returns the cwd and get the behavior
> you want.
>
>    let &statusline='%<%f %(%h%m%r %)%=%{TagName()} %-15.15(%l,%c%V%)%P'
>
> Regards,
> Gary

Thank you very much -- this works exactly like I want!

The 'foo' in my status bar stays in the same column
in both the situations below:

foo line 100 column 200
foo line 1 column 1

Thanks again,
--Nate

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php