Saluton Yue :)

On Sun 31 May 2009 02:07, Wu +0200, Yue <v...@...> dixit:
> On Sat, May 30, 2009 at 06:42:17PM +0200, Raúl Núñez de Arenas
> Coronado wrote:
>> If you think you need to show the changes dynamically (and
>> instantaneously, I assume), maybe VCS's are not the way to go, but on
>> the other hand maybe you should think again about your needs about
>> how to solve your problem.
>>
>> Again, if you could elaborate a bit more about your particular
>> problem, we would be more proficient giving you help. I understand
>> that maybe you cannot reveal details (if this is for some job, for
>> example), but if you can, tell us and probably we will be able to
>> help better :)
>
> For example, if I'm editing a file, and the file has been modified by
> external tool, say echo foo >> file, since the last time I haved
> saved, then now after I'm finishing the editings and want to write the
> file to disk, then vim will warn that file has been changed, what
> should I do? 1) Abandon my editing; 2) Abandon the changes by external
> tool. Both of them are not so good.

What I don't understand is why do you need to do things that way. I
mean, why your file may be modified by external tools or why another
person has to edit the same copy of the file you are editing too.

If both you and your coworkers need to edit the same files because
everybody is working in *different* parts of them (for example, when
doing collaborative development) then VCS is the best solution. Each
person has his own copy of the data and from time to time all of them do
commits, merges are performed, etc.

If the problem is that you have some files that anyone may edit at any
point in time, you actually *DO NEED* to see the changes other are
making in their copies and show them on YOUR copy. There is no easy
solution to this problem, specially on UNIX, because it is a very
dangerous thing to do.

In this case and in my humble opinion, you need a change in the way you
work to avoid having to modify files concurrently. It is dangerous
unless *everybody* uses the same tool for modifying the files *and* that
tool has been designed for such job (concurrent editing). I've read the
other messages you've written about the issue and from my point of view
the problem is that you shouldn't be doing concurrent edition ;)) If you
have to do it (we can't always choose how to work, unfortunately), look
for a tool designed to do concurrent edition or sooner or later you will
get a nasty surprise: lost data. If you want me to I can explain what
kind of data losing you may suffer, but I'll do in a private email
because that would be offtopic :)

--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Ricky wrote:

> Hi
>
>   I want to see the caps lock's status more easily,  how to display caps
> lock status in status line?
>   It seems that vim don't support.

You can query the status of the LEDs (LED caps lock among other
things) with the Linux command "xset q".

I tried the following but it is not fully satisfactory.  Perhaps someone
can improve on it:

func! ShowCapsLockStatus()
   let xs = system('xset q')
   let mask = matchstr(xs, 'LED mask:\s*\zs\d\+')
   return ((mask % 2) == 0) ? 'off' : 'on'
endfunction

Then you can add something like this in your status line:

set statusline+=%{ShowCapsLockStatus()}        " show caps lock status

However, it is far from being ideal:
- the statusline is not refreshed immediately when pressing Caps-Lock
   (you need to move the cursor for example to see it being refreshed)
   There is no asynchronous event to notify when Caps-Lock key was
   pressed as far as I know.
- ShowCapsLockStatus() messes up display in xterm terminal
   when I move the cursor with the up, down, left, right keys.  I see some
   ^[OA or ^[OB showing up on the screen.  Why?
   Pressing CTRL-L or :redr! makes them disappear.
   I don't see that in gvim.
- And of course "xset q" will only work on Linux

Regards
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

wilson.m.liu wrote:
> When I set a path by ":set path=..." and use "sfind" to edit
> one file in the directory, wildcard in the file name seems
> not working. That is to say, when I type ":sf Sample.txt" for
> example, it opens the file successfully. However, when I type
> ":sf Sam*.*"(This pattern uniquely refers to one file), it
> amazingly shows an error displaying no match. I am puzzled
> whether we can use wildcard in sf path.

Yes you can use a wildcard in :find and :sfind, however, it
searches directories in the 'path' option, so the first step
would be (the second shows where set, if it has been):

   :set path?
   :verbose set path?

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

wilson.m.liu wrote:
> We can use "." to repeat the last editing command, however I
> do not know how we can repeat the last motion command.
> Supposing that we are reading a long story and using CTRL+D/U
> to scroll, is there a better way instead of pressing the keys
> again and again.

Unfortunately, no.

You could map the space bar to something handy.

And we have this tip:
http://vim.wikia.com/wiki/Automatic_scrolling_of_text

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

John Beckett wrote:
> wilson.m.liu wrote:
>> We can use "." to repeat the last editing command, however I
>> do not know how we can repeat the last motion command.
>> Supposing that we are reading a long story and using CTRL+D/U
>> to scroll, is there a better way instead of pressing the keys
>> again and again.
>
> Unfortunately, no.
>
> You could map the space bar to something handy.
>
> And we have this tip:
> http://vim.wikia.com/wiki/Automatic_scrolling_of_text
>
> John
>
>
> >
>
Damn this is great that would be a real good vim feature in the future.


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

The June edition of the Vim Tips Main Page is now available:
http://vim.wikia.com/wiki/Main_Page

Please fix any glitches you notice, or just add a comment at the
bottom of a tip to note any problem or improvement (we do not
use the talk pages ("Discussion") for tips).

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

wilson.m.liu wrote:
> I found that I cannot visit
> http://vim.wikia.com/wiki/Automatic_scrolling_of_text.
> Recently, I tried many times to connect to vim wiki, however
> failed. I don't know why, and if there is any other way to
> get the information.

Please give some explanation when you say you cannot do
something. You might mean you don't have an Internet connection,
or your DNS server is broken, or any of a hundred other things.

Start by describing exactly what you do and what happens. Is
there an error message?

OTOH if you are in China, you may be blocked from visiting
wikia.com.

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

wilson.m.liu@...
> I am not clear about what ":set path?" mean.

That's a command you type in Vim (starting with the colon).

It will display the value of the 'path' option. See:

   :help 'path'
   :help :set
   :help :find

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Mon, Jun 01, 2009 at 08:54:34AM +0200, Raúl Núñez de Arenas Coronado wrote:
>
> What I don't understand is why do you need to do things that way. I
> mean, why your file may be modified by external tools or why another
> person has to edit the same copy of the file you are editing too.
>
> If both you and your coworkers need to edit the same files because
> everybody is working in *different* parts of them (for example, when
> doing collaborative development) then VCS is the best solution. Each
> person has his own copy of the data and from time to time all of them do
> commits, merges are performed, etc.
>
> If the problem is that you have some files that anyone may edit at any
> point in time, you actually *DO NEED* to see the changes other are
> making in their copies and show them on YOUR copy. There is no easy
> solution to this problem, specially on UNIX, because it is a very
> dangerous thing to do.
>
> In this case and in my humble opinion, you need a change in the way you
> work to avoid having to modify files concurrently. It is dangerous
> unless *everybody* uses the same tool for modifying the files *and* that
> tool has been designed for such job (concurrent editing). I've read the
> other messages you've written about the issue and from my point of view
> the problem is that you shouldn't be doing concurrent edition ;)) If you
> have to do it (we can't always choose how to work, unfortunately), look
> for a tool designed to do concurrent edition or sooner or later you will
> get a nasty surprise: lost data. If you want me to I can explain what
> kind of data losing you may suffer, but I'll do in a private email
> because that would be offtopic :)

Yes, after many kind of help and advice, I realize I'm trying to do something
in a wrong way, it's dangerous.

But what about in this case: I want to share a file with others and we can
edit one same file, so it can act like that we are chatting via this file, and
when I'm typing something, then others typing will show up dranamically, I
think it's a case of concurrent editing, hmm? Someone advices me the
netmeeting, I don't know if he says the Microsoft's apps, but maybe that's the
right tool for doing such thing. I'm a vim fans, maybe I'm trying to do
something that has extently exceeded vim's ability.

--
Hi,
Wu, Yue

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 27/05/09 00:23, Ben Schmidt wrote:
>
> The bug has been fixed in a recentish Vim patch--you can now explicitly enable
> ff=dos when opening a file, and Vim will obey you.
>
> :e ++ff=dos
>
> I believe in this case Vim will treat CRLF and LF as line breaks, i.e. it will
> silently convert single LF into CRLF. Single CR will show up as ^M in the
buffer.
>
> As long as unix is in your 'ffs' option, though, Vim will autodetect filetype
and
> will turn to Unix line endings if it finds a missing CR.
>
> For more details on fileformat detection, and on specifying it explicitly when
> opening a file, etc., see
>
> :help 'ff'
> :help 'ffs'
> :help ++opt
> :help file-formats
>
> Remember, though, that this thread was about a bug Vim had where it would
> sometimes ignore the ++ff=dos option. It has now been fixed, but only if you
have
> a Vim complied with that patch in it will you have the benefit of the fix. I
don't
> have time now to look up when it was fixed; someone else may be able to.
>
> Ben.

7.2.040, see http://ftp.vim.org/pub/vim/patches/7.2/README


Best regards,
Tony.
--
Whenever anyone says, "theoretically", they really mean, "not really".
		 -- Dave Parnas

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Maybe we should use soft implement to enable/disable caps:
http://www.vim.org/scripts/script.php?script_id=1725
I have tried this, but I really want vim can display caps lock status.

And I only have Cygwin, of course can't use xset command.

If vim support CAPSLOCK key's map, this is not a problem:)

--------------------------------------------------
>
> Ricky wrote:
>
>> Hi
>>
>>   I want to see the caps lock's status more easily,  how to display caps
>> lock status in status line?
>>   It seems that vim don't support.
>
> You can query the status of the LEDs (LED caps lock among other
> things) with the Linux command "xset q".
>
> I tried the following but it is not fully satisfactory.  Perhaps someone
> can improve on it:
>
> func! ShowCapsLockStatus()
>  let xs = system('xset q')
>  let mask = matchstr(xs, 'LED mask:\s*\zs\d\+')
>  return ((mask % 2) == 0) ? 'off' : 'on'
> endfunction
>
> Then you can add something like this in your status line:
>
> set statusline+=%{ShowCapsLockStatus()}        " show caps lock status
>
> However, it is far from being ideal:
> - the statusline is not refreshed immediately when pressing Caps-Lock
>  (you need to move the cursor for example to see it being refreshed)
>  There is no asynchronous event to notify when Caps-Lock key was
>  pressed as far as I know.
> - ShowCapsLockStatus() messes up display in xterm terminal
>  when I move the cursor with the up, down, left, right keys.  I see some
>  ^[OA or ^[OB showing up on the screen.  Why?
>  Pressing CTRL-L or :redr! makes them disappear.
>  I don't see that in gvim.
> - And of course "xset q" will only work on Linux
>
> Regards
> -- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hello dear vim users,

I am completly new to vim, and I have a few questions:

- To me it feels like the [Esc] key would be very unreachable (for a
key which has to be pressed very often). How do other vim user cope with
this?

- I would like to use vim to write C++. I need gdb and I find it very
usefull to have gdb integrated into the editor. I find several plugins
for gdb ... are they all good or should I stick to specific one?

- When I press {, I like the } to be inserted with it. When I press }
int front of a {, I would like to jump over the } (look at eclipse
behavior for an example. Is this possible?

Thanks!
Nathan

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> Hello dear vim users,

Welcome

> - To me it feels like the [Esc] key would be very unreachable (for a
> key which has to be pressed very often). How do other vim user cope with
> this?

Various folks use solutions that work for them. On my laptops, I
often find that I hit <F1> accidentally when stabbing for <esc>,
so I just remap them:

    :inoremap <f1> <esc>
    :nnoremap <f1> <esc>
    ... (for other mapping modes)

This allows me to mash in the upper left corner of my keyboard
with less need for accuracy.

Alternatively, some folks use control+[  which sends vim the same
character as the <esc>.  I use this occasionally depending on the
keyboard.

Lastly, some folks remap an existing vim functionality such as
the comma or semi-colon to serve as <esc>  However I happen to
regularly use both of those keys, so that has never appealed to me.

> - I would like to use vim to write C++. I need gdb and I find it very
> usefull to have gdb integrated into the editor. I find several plugins
> for gdb ... are they all good or should I stick to specific one?

Can't help you much here.  When I've needed to do debugging, I
usually use "screen" and just flip between the two sessions.

> - When I press {, I like the } to be inserted with it. When I press }
> int front of a {, I would like to jump over the } (look at eclipse
> behavior for an example. Is this possible?

The first one can be done with

    :inoremap { {}<left>

The second one, I'm not sure I 100% understand (not using
Eclipse), but it sounds like you just want

    :inoremap } }<left>





--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Jun 1, 7:24 am, Nathan Huesken <v...@...> wrote:
> - When I press {, I like the } to be inserted with it. When I press }
> int front of a {, I would like to jump over the } (look at eclipse
> behavior for an example. Is this possible?
>

http://vim.wikia.com/wiki/Automatically_append_closing_characters has
some good suggestions.

There may be others in http://vim.wikia.com/wiki/Category:Brackets but
I haven't really looked at most of them.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

The help (just above :help :abbreviate-local) says:

> To avoid the abbreviation in insert mode: Type part of the abbreviation, exit
> insert mode with <Esc>, re-enter insert mode with "a" and type the rest.  Or
> type CTRL-V before the character after the abbreviation.
> To avoid the abbreviation in Command-line mode: Type CTRL-V twice somewhere in
> the abbreviation to avoid it to be replaced.  A CTRL-V in front of a normal
> character is mostly ignored otherwise.

Experience has shown me that the second insert mode method (press CTRL-
V just before the character after the abbreviation) also works in
command-line mode. For example, I have a cabbrev of q!@ to just q! (a
common typo of mine). Typing q!@<C-V><Space> works just fine to avoid
expansion of the abbreviation. Pressing q!<C-V><C-V>@<Space> on the
other hand does avoids the abbreviation, but also inserts a ^V
character in the command. I can certainly see this causing problems,
especially if you're entering not an ex command, but a search, where
the ^V will not be ignored but will rather be included in the search.

In addition, the given method sometimes causes an ex command to be
invalid. For example, I have a cabbrev for "vimgrep" that will expand
to a "noautocmd vimgrep" for the word under the cursor. Entering vim<C-
V><C-V>grep /pattern/ *.txt gives "E682: Invalid search pattern or
delimiter" whereas vimgrep<C-V> /pattern/ *.txt acts as desired.

Is there some reason the <C-V><C-V> would ever be desirable in command-
line mode over the second method listed for insert mode? I have yet to
find a situation where it is better, but I figure there must be some
reason this is the suggested method.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Saluton Yue :)

On Mon 1 Jun 2009 13:39, Wu +0200, Yue <v...@...> dixit:
> On Mon, Jun 01, 2009 at 08:54:34AM +0200, Raúl Núñez de Arenas
> Coronado wrote:
>> In this case and in my humble opinion, you need a change in the way
>> you work to avoid having to modify files concurrently. It is
>> dangerous unless *everybody* uses the same tool for modifying the
>> files *and* that tool has been designed for such job (concurrent
>> editing). I've read the other messages you've written about the issue
>> and from my point of view the problem is that you shouldn't be doing
>> concurrent edition ;)) If you have to do it (we can't always choose
>> how to work, unfortunately), look for a tool designed to do
>> concurrent edition or sooner or later you will get a nasty surprise:
>> lost data. If you want me to I can explain what kind of data losing
>> you may suffer, but I'll do in a private email because that would be
>> offtopic :)
>
> Yes, after many kind of help and advice, I realize I'm trying to do
> something in a wrong way, it's dangerous.

It's dangerous only if you don't use the appropriate tools, and only if
more than one person can write the file at any given point in time.

> But what about in this case: I want to share a file with others and we
> can edit one same file, so it can act like that we are chatting via
> this file, and when I'm typing something, then others typing will show
> up dranamically, I think it's a case of concurrent editing, hmm?

I understand the example, but in that case I would use a chat program ;)
Anyway, I understand your point: if you need to do the concurrent
editing, you need it, period. In that case I think it is safer if you
use a tool that supports concurrent editing instead of tweaking Vim to
do the job (which may be possible).

> Someone advices me the netmeeting, I don't know if he says the
> Microsoft's apps, but maybe that's the right tool for doing such
> thing. I'm a vim fans, maybe I'm trying to do something that has
> extently exceeded vim's ability.

I think you could write some autocommands for CursorHold, CursorHoldI,
CursorMove and CursorMoveI so that if the file is changed you reload it,
but that way the changes you made are lost. Mixing your changes and the
changes from other people is possible by using "diff" or "diff3" when
reloading the file.

Under Linux you can use inotify to check if someone wrote to the file
and the reload it, but right now I don't know how to use that to force
the rest of Vim processes to reload and merge the file.

Please note that no matter if you use an inotify-based solution or some
autocommands to monitor the file and reload+merge it, this is very error
prone and problems will happen as soon as two writers make incompatible
changes (both of them modify the exact same line, for example).

Your problem has no easy solution using Vim, because the only way you
could use Vim for what you want to do is to have just ONE Vim instance
acting as "server", and that instance is the only with physical access
to the concurrently-edited file. After that, each person editing the
file just uses a "client" Vim that sends keystrokes to the server. The
server performs the actions from all clients and updates all of them
with the new file contents. This is not concurrent at all, because the
actions from the clients are serialized, but it is collaborative,
changes are shown automatically, etc. The only problem with this
solution is that, as far as I know, you can set up a Vim server editing
a file and accepting keystrokes from clients, but you cannot set up a
"client" Vim that sends all the keystrokes to the server and receives
the updated file contents. The only way I know of sending keystrokes to
a "server" Vim is to use "--remote-send".

--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 27/05/09 17:21, Gene Kwiecinski wrote:
>
>> When I substitute using ":s/{pattern}/{string}/{option}", I prefer
>> to use "/{pattern}" to check out...
>
> You already got answer by now, but in general, if you just need to
> modify the pattern if it be *un*satisfactory, just type '/' and then
> scroll through the earlier search patterns with the up/down arrow keys,
> and once you find it or something similar, you can edit it to suit
> (add/delete/change), then rerun the search.

Another possibility, to reuse a search pattern which wasn't the last one
without bumping all the way around the file even if 'imsearch' is set,
is the command-line window: hitting q/ or q? will open a window with all
recent seach patterns (latest at bottom). Place the cursor on one of
them, edit it or not, then hit Enter, to search for that pattern
(executing the search command under the cursor); or hit :q (or :x etc.)
to leave the command-line window if you change your mind. (You cannot
leave that window without closing it.) Similarly with q: for ex-command
history instead of search history.


Best regards,
Tony.
--
Experience is that marvelous thing that enables you recognize a mistake
when you make it again.
		 -- F. P. Jones

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

I've usually used cmd.exe (command prompt) as my shell on Windows, but
I've recently begun using the cygwin bash shell. With cmd.exe, running
gvim from the command line caused gvim to start up and be completely
detached from the cmd shell, meaning I could continue using the cmd
shell while the gvim process was running and even close the cmd shell
without affecting the gvim process. But now with cygwin bash, whenever
I run gvim from the command line, it doesn't detach; it holds up the
shell until it exits at which point the shell returns. I know if I use
an ampersand on the end of the command then the gvim process will run
in the background and I'll be able to use the bash shell, but I still
won't be able to close the bash shell until the gvim process exits,
which I don't like. Why is this, and how can I fix this problem?
Thanks.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Jun 1, 10:25 am, Ben Fritz <fritzophre...@...> wrote:
> http://vim.wikia.com/wiki/Automatically_append_closing_characters has
> some good suggestions.
>

...which I've just updated with a far superior solution than was
already there, that doesn't have a bunch of side effects.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> I've usually used cmd.exe (command prompt) as my shell on Windows, but
> I've recently begun using the cygwin bash shell. With cmd.exe, running
> gvim from the command line caused gvim to start up and be completely
> detached from the cmd shell, meaning I could continue using the cmd
> shell while the gvim process was running and even close the cmd shell
> without affecting the gvim process. But now with cygwin bash, whenever
> I run gvim from the command line, it doesn't detach; it holds up the
> shell until it exits at which point the shell returns. I know if I use
> an ampersand on the end of the command then the gvim process will run
> in the background and I'll be able to use the bash shell, but I still
> won't be able to close the bash shell until the gvim process exits,
> which I don't like. Why is this, and how can I fix this problem?

man cygstart

specifically, 'cygstart gvim'

Chris

--
Chris Sutcliffe
http://emergedesktop.org

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 2009-06-01, Wu, Yue wrote:

> But what about in this case: I want to share a file with others
> and we can edit one same file, so it can act like that we are
> chatting via this file, and when I'm typing something, then others
> typing will show up dranamically, I think it's a case of
> concurrent editing, hmm? Someone advices me the netmeeting, I
> don't know if he says the Microsoft's apps, but maybe that's the
> right tool for doing such thing. I'm a vim fans, maybe I'm trying
> to do something that has extently exceeded vim's ability.

For that particular case, I think you should try screen, as Tim
suggested earlier.  As I understand it, in multiuser mode, screen
passes all the keyboard inputs from all connected users to the
application.  Take a look at the screen man page, or the home page
at http://www.gnu.org/software/screen/screen.html.  A Google search
for "gnu screen multiuser" turns up a lot of useful-looking hits.

Regards,
Gary



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 27/05/09 05:32, Nathan Neff wrote:
>
> Hello,
>
> I would like to create a foldexpr that turns this Groovy closure:
>
>      def list = {
>          if (!params.max) params.max = 10
>          [personList: Person.list(params)]
>      }
>
>      def show = {
>          blah
>          blah
>          blah
>      }
>
>
> Into this fold text:
>
>      def list = {
>      def show = {
>
> Currently, I'm using foldmethod=indent, because all the closures start
> on the 5th character.
>
> I'm messing around with the foldtext setting, but can't get Vim to
> quit displaying a line containing a bunch of dashes and how many
> lines have been folded, which I really don't care about.
>
> Thanks in advance,
>
> --Nate

I don't know if your Groovy syntax script sets folding, but anyway it
ought not to be too hard: try this (untested)

If it does,
	 :setlocal foldmethod=syntax

If it doesn't,
	 :setlocal foldmethod=marker foldmarker={,}

To avoid the bunch of dashes and number of lines folded (also untested):

	 :setlocal fillchars=fold:\  foldtext=getline(v:foldstart)
	 " with at least two spaces after the backslash


Best regards,
Tony.
--
Really heard in court in the U.S.A.:
Q.: Doctor, is it really true that when someone dies while sleeping, he
or she
      doesn't realize it until the next morning?
A.: Is it really true that you passed your exams before being admitted
to the
      Bar?

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Mon, Jun 1, 2009 at 8:37 AM, Gary Johnson <garyjohn@...> wrote:
> For that particular case, I think you should try screen, as Tim
> suggested earlier.  As I understand it, in multiuser mode, screen
> passes all the keyboard inputs from all connected users to the
> application.  Take a look at the screen man page, or the home page
> at http://www.gnu.org/software/screen/screen.html.  A Google search
> for "gnu screen multiuser" turns up a lot of useful-looking hits.

Also note that if you can login via the same shell account you don't
have to use screen's multiuser mode, simply run screen -x

Regards,
Jason

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---