Not really, I would still have to hunt down messages in the archive,
look at patches to find one that looks like it would work, then figure
out who wrote this anyway...
But let this not be an invitation for someone to do all this work,
because I'm just going to add a line in the todo list and it
Hi, Björn,
No, there is no official MacVim.app release yet (only binary
snapshots)...I am still fixing bugs and implementing missing features.
That being said, it works fairly well and supports some features that
the Carbon port does not. Please try it out and let me know why/if it
is
Is there a way of searching through multiple buffers? ie: I'd like a
derivative of '/' to
be able to span files, ie: if it doesn't find it in one file, it goes to the
next
in the bufferlist, and so on..
I'm not aware of any functionality quite like that, though there is the :bufdo
That use of lambda exists in colloquial contemporary French. In the French
wikipedia, under Lambda (homonymie), the first title is as follows:
Adjectif
* Le mot lambda est souvent utilisé comme adjectif pour qualifier une
entité indéfinie quelconque.
* Un utilisateur lambda
The only thing that requires a little care (IIUC) is to make sure that if the
tilde is followed by a backslash, the latter is a true backslash and not an
escaper backslash for something else than a backslash: in ~\foo, ~ means
$HOME while in ~\ foo it doesn't, and the filename is ~ foo.
My 'encoding' is set to utf-8
If I type the following in gvim:
:map! Û Ucirc;
where the {lhs} is a Latin capital U-circumflex, it appears in the output of
:map!
as
! Ã xCSI Ucirc;
It's impressive!
It might be related to 'tenc' to, I suppose. What's that
A.Politz wrote:
I am student of computer science. In the next semester I'll
have to do some practical work supervised by a professor.
Now what I really would like to do in this project, is
giving vim the ability to start and manage subprocesses.
It might help if you let people know what
vim -u NONE
:help helpget some text on screen, and statuslines
:silent :true The screen is garbled.
Not for me.
I think the point made earlier was that the docs actually, in the most strict
logical sense, don't say anything about what you need to do if a command
Wow, Thanks for everyone's feedback :), there are some great ideas on
how to get started. I particularly like the idea of running it as a server.
2) You start the GUI version as Vim-Server. Used by gvimplugin [2].
3) You start the GUI version as a Netbeans-Server. Used by eeedit [3].
First scenario:
set enc=default
set fenc=latin1
set fencs=ucs-bom,utf-8,latin1
set tenc=latin1
vim file-- Correct (fenc=latin1)
vim file8 -- Correct (fenc=utf8)
cat file8 | view - -- Correct (fenc=)
Second scenario:
set enc=utf8
Vim doesn't set fileencoding when it reads stdin, but it still uses
fileencodings
to interpret the encoding of stdin, just like opening any other file. So if
some
latin1 text is valid utf8 text, Vim will interpret it as such if your
fileencodings=utf8,latin1. Only if it is invalid as
This is not true. In fact, if the file contains señor instead of
ññ, Vim does resort to Latin1. This said, Vim's failure here does
sound like a bug. But I would like to hear from Bram first.
Well spotted, Yongwei. So there is something more subtle about this bug, and I
believe it is this:
Andy Wokula wrote:
... and I don't mean join().
I'd like to have a function like split(), except for it should collect all
the _matches_ in a list. matchlist() would be a good name for it,
unfortunately it's already taken.
How would I do it now?
A naive and inefficient but simple
Still buggy:
:echo SplitMatch(aba, .*)
['aba', '']
Looks OK to me.
Maybe you wanted
:echo SplitMatch(aba, '.\+')
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message
Here is a patch to Vim that adds a , register which is basically access to
Vim's
internal 'redo buffer' used when '.' is used. At a quick look, it seems to
work.
You can thus save your '.' commands to another register and replay them later:
:let @a=@,
@a
I believe @, will have pretty
Somehow using a dollar doesn't work here, probably because of expanding
environment vars. We might not be able to change this without breaking
backwards compatiblity.
This is completion-specific issue. In glob, the problem does not exist.
Strangely, :e $Tab completes names of env.vars,
Hi,
a beginner question, can I reformat entire file code from:
if (...)
{
// some action
}
to:
if (...) {
// some action
}
Thanx.
The '=' command will reformat code.
gg=G
will do from top to bottom (whole file).
But you have to set the indent options to what you want
The '=' command does not reformat code--it indents code. In
particular, the '=' command will not move the opening brace from one
line to another.
O yeah. Duh. What was I thinking?!
Maybe I was thinking of gq and some set of formatoptions that might possibly
make
it work...dunno...never
!xdvi -hushstdout -s 5 -geometry 1024x900+416+0 -expert %.dvi
which works fine from vim, but not from gvim.
I think what is happening is that Vim is creating a pseudo-terminal, running
the
command, and then killing the pseudo terminal (and consequently all commands
attached to it) as
Well, I can see that you get the information, but this is not really a
useful real-world example. Think of a user that wants to get something
done for which v:operator is needed. And for which there is no other
solution.
Here's a somewhat naively implemented example where a custom
Well, I can see that you get the information, but this is not really a
useful real-world example. Think of a user that wants to get something
done for which v:operator is needed. And for which there is no other
solution.
Here's a somewhat naively implemented example where a custom
[CCing this to the mailing lists; only went to Bram before, but some parts may
be
useful for others.]
I'm not quite convinced adding v:operator is useful. What would help is
giving a couple of examples how it's used. Also, in the docs for
v:operator it would be good to have a few examples
[CCing vim_dev; apologies for my continued disorganised postings!]
OK, folks,
After reading feedback, etc., here is a revised patch. It's just the
documentation
that is different from the previous patch.
In the end, given that a number of things can be done without v:operator, as
Andy
Ilya Sher wrote:
Zvi Har'El wrote:
I don't think it is worth the trouble insisting to pass % to an external
command instead of passing %.
The big plus here is much less typing:
comparing :e %CR vs :e %CR gives
5 vs 7 characters to type.
Maybe some modifier might be added to % to make
Ben Schmidt wrote:
Hello everybody !
I find the automatic setting of the 'diff' option a bit inconsistent
and inconvenient :
vim -u NONE -U NONE file1 file2
:set cp
:syn on
:set diff
If you don't want it to be set as the global option which is the default for
newly
opened buffers
vim -u NONE
iA sentence.Esc)
The cursor is placed beyond end of line despite virtualedit being blank.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
:help :sort|/first number
The documentation reads
To sort on the first number in the line, no matter
what is in front of it:
:sort /.*\ze\d/
which is clearly wrong. As * is greedy, this actually sorts on the last
:help :sort|/first number
The documentation reads
To sort on the first number in the line, no matter
what is in front of it:
:sort /.*\ze\d/
which is clearly wrong. As * is greedy, this actually sorts on the last
[Didn't get any acknowledgement of this; resending. For the to do list perhaps,
Bram?]
vim -u NONE
iA sentence.Esc)
The cursor is placed beyond end of line despite virtualedit being blank.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Matthew Winn wrote:
On Sun, 25 Nov 2007 21:55:01 -0800, Mark Waggoner
[EMAIL PROTECTED] wrote:
I just thought I'd update this thread to note that I've been using vim with
this patch for the last month or so, and have not encountered any problems.
I can't say that I stress the handling of
My point was that a would-be cracker would have access to both the
encryption key and the encrypted text. Using the pid as the key is
not made more secure by not storing it, since that cracker would also
have access to the hypothetical getpid() function; it just saves him
the trouble of
and there is no way to protect against #3: Someone with access
to your core file can access the encryption key (even if it's vim's
start time, vim has to be storing that somewhere to give it to you)
Not necessarily. If it can be got by a system call when it is needed and then
popped off the
Hi, Bram and maintainers,
There is a long-standing bug in $VIMRUNTIME/syntax/php.vim which I patch
every time I reinstall vim!
Line 86:
runtime syntax/html.vim
should be
runtime! syntax/html.vim
At least, that's what I think!
Could that be fixed, please?
Cheers,
Ben.
Send
[Sending to vim_dev which is where this really belongs, I think.]
Daniel Fetchinson wrote:
Hi vimers!
Maybe the segfault happens more generally but I can only reproduce it
with tilde-style home directory file completion (on linux).
Steps to reproduce:
vim
:e ~xxxTABTABEnter
:e
once logged into
Sourceforge, it says that this is for filing bugs against the vimonline
website... not for filing bugs against Vim itself
I think that is correct. The procedure for reporting Vim bugs is documented in
Vim's help at, funnily enough
:help bugs
Cheers,
Ben.
Send instant
Philip Prindeville wrote:
Ben Schmidt wrote:
once logged into
Sourceforge, it says that this is for filing bugs against the vimonline
website... not for filing bugs against Vim itself
I think that is correct. The procedure for reporting Vim bugs is documented
in
Vim's help
Andrew Myers wrote:
Philippe De Muyter wrote:
On Sun, Oct 22, 2000 at 10:20:34PM +0200, Bram Moolenaar wrote:
[...]
The default digraphs now correspond to RFC1345. Most are different from
what was used in Vim 5.x. Do we care about this incompatibility?
I only noticed that now,
How can LINKIT only be :?
: is shell builtin, try 'type :'. It just expands arguments and returns
true. (so that ': $(touch a)' creates file a). To be sure I checked it
for sh, bash and ksh on Solaris.
I would've thought the confusion wasn't over what ':' did, but over why, if you
can't
Erik Falor wrote:
While writing a guitabtooltip function, I discovered that the
tooltips in Win32 don't properly handle backslash-escaped chars.
In particular, '\n' comes out as a box, and '\t' appears to terminate
the string like '\0'.
The GTK gui on Linux, however, works as expected.
Ingo Karkat wrote:
On 03-Jan-08 17:25, aj wrote:
I am running gvim on a windows box, version 7.1.
There are a series of coldfusion source files located on another machine on
the network. I have a shortcut to the network directory containing these
files on my desktop.
When I try to open
The filenames were the strings above without the double quotes.
Backslash-escaping looked OK: I could edit the files and save them. Then ls
t* in bash didn't show spurious filenames, and these files' lengths weren't
zero anymore. If you have other cases in mind, I'm ready to check.
I will
The attached patch avoids compiler warnings for different pointer signedness
that
shows up when compiling with MODIFIED_BY set (which I suppose Bram doesn't do,
so
doesn't notice it!).
Grins,
Ben.
--~--~-~--~~~---~--~~
You received this message from the
Hi,
I recently had trouble compiling Vim on Mac OS X 10.4.9 with GTK2 GUI. As is
mentioned in the Vim source, the X headers and Mac headers clash horribly. This
means stuff has to be separated carefully into files that have X headers
available
and those that have Mac headers available, and
[This copy contains the attachment. Also, I forgot to mention that simply
changing
the logic of preprocessing in, say, vim.h doesn't solve the problem. Features
provided by the conflicting code are indeed needed together--you lose X
functionality or MacRoman encoding functionality depending
- Moved from os_mac_conv.c to mac_gui.c and made static to that file:
- mac_utf16_to_enc
- mac_enc_to_utf16
- mac_enc_to_cfstring
- mac_utf16_to_utf8
- mac_utf8_to_utf16
I suppose you had to do this because MACOS_CONVERT is defined. Can't
you change vim.h not to define
Unfortunately this patch will break MacVim compilation because of the
MacRoman encoding support won't get compiled (MacVim does not use
gui_mac.c, neither does vim-cocoa for that matter). Why is it not
possible to have the encoding functions in a separate source file?
The problem is mostly
OK. In line with my previous emails, here is a revised patch. It also works,
but
by a different approach. It will definitely be better in some regards in light
of
a few points that were raised, but I'm still not completely comfortable with
it--it does seem like a bit of a dirty hack. That
It works for me. Quite nice. I've known about this for years, but it never
occurred to report it or try to fix it! It's lovely that it works now, though;
I
have a lot of files like this that I use quite regularly in Vim, so it will
improve my quality of life considerably.
Grins,
Ben.
1. abbrevs are not triggered by a mapping when remapping is off:
abbrevs not triggered:
:ino esc esc
:ino esc c-]esc
abbrevs triggered as expected:
:imap esc esc
:imap esc c-]esc| careful, endless loop
I'd like to have abbrevs expanded in all situations.
I think that could
The builtin Escape key already expands abbrevs. Isn't this like a part
of its definition? If I put esc on the right side of a noremap, I do
this in order to get this builtin behaviour.
I disagree. If *I* put Esc on the right hand side of a mapping I do it to get
the builtin behaviour of
Of course an abbreviation given in the
{rhs} of a :noremap is not to be expanded, just like any other user
mapping.
My example
:ino esc esc
targets an abbreviation that is not part of the mapping, but already to
be found in the text.
That makes sense. I didn't realise you were
Nikolai Weibull wrote:
I have the following mapping:
map g: Esc:set operatorfunc=SIDget_command_mode_rangeCRg@
and have recorded
g:}j^M
into register 'a'.
Running @a now does nothing.
Why?
(It should run :join from the current line to the end of the current
paragraph.)
It might help folks help you if you included the
get_command_mode_range() function.
Ugh, yeah, I'm beginning to have a suspicion as to what the problem is:
function! s:get_command_mode_range(type)
let b = line('[)
let e = line('])
if b e
let range = '.,+' . (e - b)
Ben Schmidt wrote:
Adri Verhoef wrote:
An easy way to reproduce this bug:
$ echo y y
$ vim -u NONE y
y 1 line, 2 characters
Then type ) and the cursor moves one position to the right, although
there's nothing there!
Vim 7.1 - Included patches: 1-2, 4-6, 8-12 - on Fedora 7.
I
Adri Verhoef wrote:
An easy way to reproduce this bug:
$ echo y y
$ vim -u NONE y
y 1 line, 2 characters
Then type ) and the cursor moves one position to the right, although
there's nothing there!
Vim 7.1 - Included patches: 1-2, 4-6, 8-12 - on Fedora 7.
I believe Bram fixed
Your code is equivalent
to this :
function! Outer()
let outer_var = 0
call Inner()
echo outer_var
endfunction
function! Inner()
let outer_var += 1
endfunction
call Outer()
-
Philip Prindeville wrote:
This is simple enough: suppress the detecting of /usr/local and putting it
into the load path (etc) if we're cross-compiling.
Please review this and if it looks reasonable, signal to whomever to commit
it to the source tree (as a patch, obviously) or cast a
Richard Hartmann wrote:
On Jan 10, 2008 4:20 PM, Ben Schmidt [EMAIL PROTECTED] wrote:
I suspect it is deliberate. URLs rarely contain parentheses, but are often
written
inside them in sentences, e.g.
There is interesting information on the web (for example, at
http://vim.org
I was thinking of RFC 1738 (Uniform Resource Locators) but it also
mentions that parentheses are reserved characters and can be escaped
unless they're being used for a reserved purpose.
And whether they have a reserved purpose is dictated by the URL scheme, isn't
it,
not the
Although according the Ben's earlier posting, we're both in the pipeline.
So I guess we just sit tight a little longer...
If you haven't seen Bram's post to you now (that should comt to you directly
and
via the vim_dev list), let me know and I will forward its text only to you.
Seems
he
Sorry, haven't received anything. Could you please forward it to me ?
Thank you,
Marc
I think the note was for Philip Prindeville, but it is relevant to all
contributors to the patch, I'm sure. I'll send it to all you guys while I'm at
it.
It's so frustrating when email systems
Not sure about the over the web part. This won't be easy to
implement
locally anyway.
What would this be good for if it works only locally then?
I'm sure locally includes ssh sessions which can provide across-the-web
functionality. Just have to have two people logged into the same
- add flexible tab stops, can be used for tables
Bram, do you mean Matthew Winn's patch? It would be super! I hope that as it
works, the amount of work to push it to production state will be small and
this
feature will be be included in vim even without any extra votes ;-)
It's slightly
results in this being printed:
function A
function A..B
function A..B..C
So, you can easily make a function yourself returning the callstack,
something like:
function! CallStack()
return split(substitute(expand(sfile), '^\S\+\s', '', ''), '\.\.')
endfunction
That's cool; I
Tony Mechelynck wrote:
Mikolaj Machowski wrote:
Dnia Thursday 17 of January 2008, Bram Moolenaar napisał:
Hello Vim users,
I have added two items to vote on:
- add collaborative editing: changes made to a file show up in another
Vim in a second
- add flexible tab stops, can be used for
But something I really do think is worth changing because it's really
confusing, is ++enc. Why do we call this ++enc not ++fenc which would
make a huge amount more sense, and be more consistent with ++ff and
++bin which both set their namesake options? We see evidence of people
getting 'enc'
Creating such a recursive mapping should perhaps give an error,
rather than causing infinite loops when triggering the mapping.
The infinite loop is actually a feature, and documented.
:help recursive_mapping
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
I've noticed that pressing CTRL-G while in visual mode,
causes vim to take 100% of the CPU.
I can interrupt it with CTRL-C.
Anybody else observing that?
Not me. 7.1.203
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Hi, Bram,
Another one for the todo list, I think (can't spot it on there).
If you issue setglobal in a read-only buffer for an option that locally would
change the buffer, it fails with an error. E.g. in a help window issue
:setglobal fenc=anything
and you get
E21: Cannot make changes,
I confirm that it fails if 'modifiable' is off, as in a helpfile. For a plain
'readonly' (but 'modifiable') file there is no problem, and the buffer is not
marked as modified.
Thanks again for the correction, Tony.
Not my week evidently!
Ben.
Send instant messages to your online
Ben Schmidt wrote:
Ahh, indeed, there is the problem and the reason why computing has not
advanced as much in the last 15 years as one would have expected
seeing the 15 years before: Backward compatibilty has hobbled us.
Indeed, I think it has. The Mac OS used to use resource forks and type
There is only 1 bufferlist in an vim instance. tabs more like windows,
a view of a buffer.
Yes. Vim has a single buffer list, and a bunch of tabpages. Each tabpage has
one
or more windows. Each window is a view of a buffer. :tabnew, :tabedit, etc.
make a
new tabpage with a single
Ben says For every tab, Vim adds a new tab. It seems counter-
intuitive to me considering that my command is *bufdo* tabnew (i.e.,
for each *buffer* create a new tab).
Just seeking to understand here: Do tabs transcend buffers or vice-
versa (i.e., can I have a set of buffers in a tab
(1) Just write an ß, go to Normal mode and do U. The ß gets killed. Do U
again and the ß appears again. You can do this repeatedly.
(2) Just write a line containing an ß. Visual select the whole line and
do U. The line is uppercase afterwards. Now do U repeatedly. The whole
line
Alexei Alexandrov wrote:
Hi,
I have the following in my .vimrc:
nmap C-Up :cprevCR
nmap C-Down :cnextCR
to navigate quickly between compiler errors. I noticed though that when
using these mappings I don't get closed folds opening automatically
despite quickfix is specified in the
I assumed Bram counted Windows towards DOS, thus not offering a PID at all?
No, Windows does have PID's, supported by the new Vim getpid() function. I
agree
the docs are unclear on this. Would be better if they had 'Unix and Windows'.
Ben.
Send instant messages to your online friends
Of course. But being able to generate/query a value and to reliably use it as
a
unique value are vastly different.
I think you *can* reliably use it as a unique value (though only within the
context of the process running), so I don't think these are vastly different. I
personally think
LegolasKiss wrote:
Hi every one.
When i use printf to print the time, i use ``%6d'' instead of ``%06d''
in code:
printf( %d.%6d, time_t.second, time_t.milsecond);
so the log is like this now:
time cost is 3. 1234
time cost is 3. 234
time cost is 3. 5
.
i want to use the
Nico Weber wrote:
I have never invoke functions in the ``esc:s/'' before.
If I understand you correctly, \zs might be even easier in this context:
:%s/d\.%\zs/0/g
See `:h \zs`.
You seem to have muddled that a bit...you have 'd' where you surely want '\d'
and
I'm not sure what
:s/\v(\d\.\s*)@=\s/0/g
This does work.
Nice, AP. I had believed (I thought on the basis of having run some tests...)
that
\zs was just syntactic sugar for \@= and that they thus behaved the same way,
so
didn't even try it, though I thought of it. Obviously I was wrong!
There may be many
To override settings set by vimrc_example.vim, don't modify the file
itself, because any Vim upgrade might silently remove your changes.
I prefer the approach that is suggested in the Vim tutor: copy the contents of
vimrc_example.vim into your own .vimrc rather than sourcing it. That way
Tony Mechelynck wrote:
Dasn wrote:
Well, it seems the new line continuation can be placed weirdly, which
will make the vim script syntax file even messy when considering the
line continuation. Any comments?
$ cat test.vim
e
\c
\h
\o
\ l
\e
\n(hello)
q
$ ex -Nu NONE -S test.vim
5
editing.txt is inaccurate on line 892 (a paragraph below *:w_c*):
The default [range] for the :w command is the whole buffer (1,$). If you
write the whole buffer, it is no longer considered changed. Also when you
write it to a different file with :w somefile!
The last sentence is only true if
editing.txt is inaccurate on line 892 (a paragraph below *:w_c*):
The default [range] for the :w command is the whole buffer (1,$). If you
write the whole buffer, it is no longer considered changed. Also when you
write it to a different file with :w somefile!
The last sentence is only true if
Tony Mechelynck wrote:
Ben Schmidt wrote:
editing.txt is inaccurate on line 892 (a paragraph below *:w_c*):
The default [range] for the :w command is the whole buffer (1,$). If you
write the whole buffer, it is no longer considered changed. Also when you
write it to a different file
Xiaozhou Liu wrote:
Hi Vimmers,
During the development of the new regexp, one thing confuses me a lot:
ordered alternation. (e.g. given r.e. 'ab\|abc' and text 'abc', 'ab'
matched, not 'abc')
I know that 100% compatibility is one of the project goals. So I try
to keep this feature
in
Antony Scriven wrote:
On 26/03/2008, Xiaozhou Liu [EMAIL PROTECTED] wrote:
Hi Vimmers,
During the development of the new regexp, one thing
confuses me a lot: ordered alternation. (e.g. given r.e.
'ab\|abc' and text 'abc', 'ab' matched, not 'abc')
I know that 100%
OTOH, with there is no ambiguity because the various uses of are
strictly separated:
Actually, there still is ambiguity unless one requires a decimal point or
exponent. Without that restriction
123.456
could still mean 123 (or 123.0) concatenated with 456. But with the restriction
123
Tony Mechelynck wrote:
On 09/04/08 17:30, Bram Moolenaar wrote:
Tony Mechelynck wrote:
[...]
Oh, oh.. it had started working (and1.0e256 multiplied by itself gives
inf, which is correct), but :echo1.0e308 crashes gvim (on Linux
i686) with SIGSEGV.
Easy to reproduce. Turns out that this
Charles E Campbell Jr wrote:
Ben Schmidt wrote:
Ben Schmidt wrote:
OTOH, with there is no ambiguity because the various uses of are
strictly separated:
Actually, there still is ambiguity unless one requires a decimal point or
exponent. Without that restriction
123.456
epanda wrote:
1-Setting the path to a recursive path cause that omnicpp is very slow
under windows.
ex: set path= D:\\** in your _vimrc and you will see.
I think this is related to an earlier-reported bug/problem in Vim itself in the
thread Vim file globbing... on vim_use:
Tony Mechelynck wrote:
On 30/04/08 17:05, Ben Schmidt wrote:
[...]
If anyone has or can find a HOWTO on building Vim on Win32 using free
software
tools (MinGW etc.), that might speed the process.
[...]
using Borland or Cygwin (I recommend Cygwin)
http://users.skynet.be
Patch #1 shouldn't be necessary after a patch I have recently submitted to Bram
is
incorporated as it was a bug that utf_head_off was called at all in the case
you
found; your solution of adding a NUL works around one of the symptoms rather
than
fixing the real bug.
Haven't looked at #2 so
Matthew Winn wrote:
On Sun, 18 May 2008 11:10:53 +1000, John Beckett
[EMAIL PROTECTED] wrote:
Adri Verhoef wrote:
I think there is a problem here, namely that the BOM (Byte
Order Mark, see :help 'bomb') is transferred to the shell
command, when it shouldn't. In my opinion Vim should be
I see. So, cvs and svn are effectively read-only - probably just a
convenience for folks want to track the activity? I presume there's an
uber-upstream source control system from which ftp.home.vim.org/pub/vim
is derived then eh?
Just curious - what is used at the top, and how do those
Milan Vancura wrote:
#include stdio.h
#include stdlib.h
int main()
{
system(gvim -c script.vim);
return 0;
}
:- Thank you for lenghtening my life with 10 minutes of laugh!
I loved the way it included stdio.h for added compilation time.
It remindes me my favorite IRC citation:
Try this:
vim --remote-expr 'feedkeys(\F4)'
:help feedkeys()
Thanks. It works, but it is not portable, so that's not enough for me.
But anyway, I can go without mapping support in --remote-send, if I am
aware of it.
Not portable?! Why not?
Ben.
The way it stands right now a user cannot
prevent a plugin writer from overwriting their maps.
Yes they can, as detailed by a previous poster, using autocommands or after
scripts the user can have the last say.
There is also the solution most of us use for Emacs. The user can choose not to
Bram Moolenaar wrote:
Ben Schmidt wrote:
I started this patch as it seemed a while ago some aspects it may be
helpful for MacVim. Recently I have dug it up and further revised it,
as I was coming across some other troubles using --remote-expr when
Vim is running in different modes
Hi, folks,
The earlier thread where Bram asked for comments on floating point
syntax, after quite a few suggestions were made and rejected for
compatibility reasons, petered out. However, two proposals were made
that I think had merit, and I wonder if people have additional comment
on them, and
1 - 100 din 260 matches
Mail list logo
