Re: Patch for variable tabstops
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 will sit there for a while. At least until lots of bugs have been fixed before I dare including a feature that most likely will cause more bugs. No matter how nice that feature is. There shouldn't be much work to do. I have been regularly compiling this patch into my Vim since it was first written, updating it as necessary. I have been busy recently, so haven't recompiled Vim for a few months. However, I doubt there will have been (m)any recent changes that break this patch. I will try to update it to the latest version within a few weeks. Feel free to nudge me if I do not. Also, I have noticed no stability problems throughout the time I have been applying the patch, so I think it's pretty solid. It has certainly had plenty of testing by me (I use it very regularly). IMHO, it's pretty much ready for inclusion in mainstream Vim. There is, however, a problem/limitation/weakness that needs to be resolved, related to the interplay between tabstop and vartabstop. I will try to look into this in the next few weeks, too, and write a followup message to the mailing list. Ben. -- -- You received this message from the vim_dev 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Mac clipboard support
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 not suitable for you (I am curious as to why you'd prefer the GTK version over MacVim on a Mac). Feature request/bug reports can be posted to the vim_mac group. As I mentioned in my other email on vim-dev, I prefer the terminal version for such things as being able to suspend my session. MacVim's implementation of :shell isn't bad, though, so a little of that functionality is there. Not enough for me to prefer the GUI to the terminal, though. The preference of GTK over MacVim is due to the struggle I have had trying getting Hebrew to work properly in MacVim (and Terminal.app and the Carbon GUI). I haven't succeeded in any of those. But I have succeeded in the GTK GUI and in xterm. I wonder how it goes in the Windows GUI--I will have to have a look when I am at work tomorrow. If we could get that fixed (Hebrew working properly in MacVim), I would definitely prefer it to the GTK GUI or xterm. And indeed, if that were fixed, I may well start using MacVim more regularly for editing other files, too, as it would be already open. I still expect I would do most work in terminal Vim, though, as it is really my preference, and ideally it would work with the Mac clipboard. Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: searching through multiple buffers
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 command. I suspect it would be easiest to use the functionality of :vimgrep to do the searching, provided your files are all in the same directory or something similarly convenient. Your recording would just use :cn rather than just n to jump to the line containing the next match. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [OT] Lambda
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 est une personne qui utilise un système de la même manière que la majorité des utilisateurs, sans chercher à exploiter des fonctionnalités avancées. which I translate as: Adjective * The word lambda is often used as an adjective to qualify any undefined quantity. As a native English speaker, I would translate it as any 'indefinite' quantity. * A lambda user is a person who uses a system in the same way as the majority of the users, not trying to use advanced functionalities. I think 'ordinary' would suit as a translation of 'lambda' in this context, as well as in the context you originally used it: Or is # just a lambda 'iskeyword' character when it applies to a variable? 'Regular' would also suffice. Another possibility for the 'lambda user' might be a 'naive user'. Your English is extremely good, Tony. It took quite a few of your posts before I realised it wasn't your native tongue, and even then, I'm not sure it was the English that gave the game away! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch: problems with filename contains '~' in file-marks
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. But maybe I'm overcomplexifying. Mmm. That seems true enough. But then who starts a filename with a tilde anyway?! But what I was actually referring to was the ability to expand other users' home directories with ~user. That could be handy on Windows, too, but I don't know what hoops you might need to go through to reliably find other users' directories! Vim-for-Cygwin is a Unix-like build, the shell handles the tilde. This thread is only busy with native-window at this point. O yes, of course. Easy. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Mapping capital U-circumflex in UTF-8 encoding
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 set to for you?
It works fine for me with Hebrew characters and enc=tenc=utf8.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: vim : process.c ?
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 length and level this project will be at. Is this a semester-long project at second-year tertiary level? Or a year-long at third-year level? Or something else? (I only have experience with Australian universities, so probably don't use terminology very useful internationally, but I guess you get the gist.) Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: doc nitpicking
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 doesn't output anything. I.e. they say you need Ctrl-L if the command does output something, but are silent (no pun intended) on whether or not you need a Ctrl-L if the command doesn't output anything. However, in English 'if' often really means 'if and only if', so the logic nitpicking isn't really valid--a phrase such as 'particularly if' or 'and even sometimes if it doesn't' could perhaps make the documentation clearer--if the behaviour you mention actually is reproducible elsewhere and not just a bug in a particular version, system or GUI! Which version/system/GUI are you using? Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Integration of Vim
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]. The next question that remains is then how you go about talking to the server. I started looking at the source code for [3] and it doesn't seem excessively hard, but I'd rather not count my chickens till they hatched. Try reading :help clientserver for a start. Once you can get Vim itself to do what you need, you should be able to make something else. E.g. find the code that implements the --remote-send option and integrate it into your application. Smiles, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Summarizing encoding issues
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 set fenc=latin1 set fencs=ucs-bom,utf-8,latin1 set tenc=latin1 vim file-- INCORRECT (fenc=latin1) vim file8 -- Correct (fenc=utf8) cat file | view - -- INCORRECT (fenc=) cat file8 | view - -- Correct (fenc=) Can you double check the value of fenc for the 'vim file' case? I get 'fenc=utf-8' (and display is incorrect, understandably). Anyway, I think you have found a Vim bug here. CCing this mail to vim_dev. The bug is as follows: When Vim gets to the fencs entry that matches enc, as it doesn't need to convert the file, it simply reads it into the buffer. The bug is that Vim does this whether the file is valid for that encoding or not. Expected behaviour: Vim only loads the file without conversion if the file is valid for the encoding; if not, it should move to the next entry in fencs. Note that because of this buggy behaviour, Vim's default value for fencs is non-sensical: it will always succeed when it gets to utf-8 when enc=utf-8 without trying default or latin1, even if the file is invalid as utf-8. Further note that fixing this may cause difficulties when reading from a stdin which can't be rewound, so once fixed, setting fencs prior to reading stdin may become more important to avoid read failures. Previous posts from me and others have explained how to do that if you are unsure, though it looks like you're pretty savvy. I thought this was worth mentioning as this is how the whole thread started! Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: fileencoding and stdin
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 utf8 will Vim interpret it as latin1. In either case, it will be converted internally to the encoding of Vim's encoding option, as always. The odd thing is that since fileencoding isn't set, you can't tell which of the fileencodings Vim used to interpret stdin, even though it still does the detection as normal. If 'fileencoding' isn't set, it falls back on 'encoding'. Yes. But this doesn't mean that was the encoding with which the input was read. I.e. you can pump latin1 or utf-8 encoded stdin into vim representing the same characters, and they will both be read correctly and converted if necessary (if enc!=utf-8 so we don't see the bug we've just discovered and mentioned in earlier posts of mine) but in both cases fenc will be unset. It will fall back to enc when the file is written, but gives no indication of how stdin was read. I think this is another bug. CCing vim_dev again. Bug: When reading stdin, fenc is not set (including when the encoding used to read stdin was different to enc). It should be set to indicate what encoding was used to interpret stdin. Cheers, Ben. P.S. Note my previous comments about non-rewindable stdin perhaps causing problems I believe to be bogus. It seems to work fine with non-rewindable stdin when enc=latin1 and it has to try multiple encodings, so the 'non-conversion even if invalid' problem should be easy enough to solve with a non-rewindable stdin, too. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Summarizing encoding issues
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: Vim doesn't recognise a file as invalid utf8 if, when you get to the first invalid sequence, there are less bytes in the file than would be required to read a valid sequence beginning with the unicode leader character read. I.e. if the last byte in the file is C2-DF, or one of the last two bytes is E0-EF or one of the last three bytes is F0-F4. As these sequences would take 2, 3 and 4 bytes respectively to read a valid character, and there are not that many bytes in the file, Vim finishes its analysis thinking 'valid' as it hasn't read a 'whole invalid character'. :-) This is a very specific scenario, though. Question for Dervish: was it just with this small test case that you noticed the problem, or does it occur elsewhere?! As I stated in another message, it looks to me when Vim reads from stdin, the content is already interpreted in termencoding. I have not yet found other results. This isn't true. I can set termencoding to e.g. big5 but Vim will read the input as latin1 or utf8 and thus display question marks as the ñ cannot be represented. On the other hand, with tenc=utf8 I can set fencs to big5 on the commandline (vim --cmd 'set fencs=big5' -) and have the f1 interpreted and displayed as Chinese. So I don't know about your Vim, but mine behaves exactly the same way whether something is pumped into stdin or opened as a regular file from disk, using fencs. I wonder if this behaviour could be platform-specific or depend on which libraries are available/compiled in. Because we both seem to have solutions, but neither of them works for the other person. H. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Wish: opposite to split() ...
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 implementation: function ListOfMatches(subject,pattern) let l:matches = [] let l:matchnum = 1 let l:curmatch = matchstr(a:subject, a:pattern, 0, l:matchnum) while l:curmatch != let l:matches = add(l:matches, l:curmatch) let l:matchnum = l:matchnum + 1 let l:curmatch = matchstr(a:subject, a:pattern, 0, l:matchnum) endwhile return l:matches endfunction E.g. :echo ListOfMatches(abracadabra,a.) ['ab', 'ac', 'ad', 'ab'] Enjoy! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Wish: opposite to split() ...
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 from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Convert dot command into macro
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 much the same functionality as . except that it
won't automatically change the count or the register number like . does (nor
will
this happen if you save to another register, of course).
I wonder what Bram thinks about including this functionality in standard Vim?
I
think it would be useful. What do others think?
Also, I haven't tested much. Testing and consequent feedback from others
would be
worthwhile. There may be issues with things not being escaped which should
be, etc.
My apologies; that was a poor patch. And I thought I'd tested @, but trying it
again showed it didn't work. I have now made sure it doesn't work. The .
command
is for that purpose, and implementing it isn't trivial!
Revised more robust patch attached.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: runtime/doc/change.txt
===
--- runtime/doc/change.txt (revision 607)
+++ runtime/doc/change.txt (working copy)
@@ -1013,7 +1013,7 @@
2. 10 numbered registers 0 to 9
3. The small delete register -
4. 26 named registers a to z or A to Z
-5. four read-only registers :, ., % and #
+5. five read-only registers :, ., ,, % and #
6. the expression register =
7. The selection and drop registers *, + and ~
8. The black hole register _
@@ -1068,6 +1068,9 @@
doesn't work with CTRL-R on the command-line. It works a bit
differently, like inserting the text instead of putting it
('textwidth' and other options affect what is inserted).
+ *quote_,* *quote,*
+ , Contains the commands that will be executed if the . normal
+ command is used.
*quote_%* *quote%*
% Contains the name of the current file.
*quote_#* *quote#*
Index: src/proto/ops.pro
===
--- src/proto/ops.pro (revision 607)
+++ src/proto/ops.pro (working copy)
@@ -18,7 +18,7 @@
int yank_register_mline __ARGS((int regname));
int do_record __ARGS((int c));
int do_execreg __ARGS((int regname, int colon, int addcr, int silent));
-int insert_reg __ARGS((int regname, int literally));
+int insert_reg __ARGS((int regname, int literally, int insert_mode));
int get_spec_reg __ARGS((int regname, char_u **argp, int *allocated, int
errmsg));
int cmdline_paste_reg __ARGS((int regname, int literally, int remcr));
void adjust_clip_reg __ARGS((int *rp));
Index: src/proto/getchar.pro
===
--- src/proto/getchar.pro (revision 607)
+++ src/proto/getchar.pro (working copy)
@@ -2,6 +2,7 @@
void free_buff __ARGS((struct buffheader *buf));
char_u *get_recorded __ARGS((void));
char_u *get_inserted __ARGS((void));
+char_u *get_old_inserted __ARGS((void));
int stuff_empty __ARGS((void));
void typeahead_noflush __ARGS((int c));
void flush_buffers __ARGS((int typeahead));
Index: src/getchar.c
===
--- src/getchar.c (revision 607)
+++ src/getchar.c (working copy)
@@ -225,6 +225,16 @@
}
/*
+ * Return the contents of the old redo buffer as a single string.
+ * K_SPECIAL and CSI in the returned string are escaped.
+ */
+char_u *
+get_old_inserted()
+{
+return(get_buffcont(old_redobuff, FALSE));
+}
+
+/*
* Add string s after the current block of buffer buf.
* K_SPECIAL and CSI should have been escaped already.
*/
Index: src/edit.c
===
--- src/edit.c (revision 607)
+++ src/edit.c (working copy)
@@ -7626,7 +7626,7 @@
do_put(regname, BACKWARD, 1L,
(literally == Ctrl_P ? PUT_FIXINDENT : 0) | PUT_CURSEND);
}
- else if (insert_reg(regname, literally) == FAIL)
+ else if (insert_reg(regname, literally, TRUE) == FAIL)
{
vim_beep();
need_redraw = TRUE; /* remove the '' */
Index: src/normal.c
===
--- src/normal.c(revision 607)
+++ src/normal.c(working copy)
@@ -2427,7 +2427,7 @@
if ((State INSERT) || !mouse_has(MOUSE_NORMAL))
{
if (regname == '.')
- insert_reg(regname, TRUE);
+
Re: anchoring filename completion to the end of filename
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, but :e *a$Tab does not complete anything. Since Tab completions are not scriptable, backward-compatibility here is different maybe ? There are human habits of course. My guess... As usually Tab completion matches as if a * is added, i.e. abcTab matches files abc*, putting the $ at the end results in abc$* being matched. $ in the middle of a pattern is not an end of string assertion but a literal $. Fixing it would then cause matching files with $ in their names to break--and such files do exist...though whether it is an issue if they aren't matched I don't know...Matching files starting with $ is probably already a problem given environment variables, so it may well be no great loss! And there is probably always \$...I don't know, but it wouldn't surprise me to see that representing a literal $, except possibly in DOS/Windows paths with the nightmare that their backslash path separator is... Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: reformat c code
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 using the :set command,
and make sure C indenting is turned on.
See
:help cindent
:help cinoptions
:help cinoptions-values
For even more info, see
:help C-indenting
However...for this particular problem, I would do it differently so as to
preserve
any other formatting. I would just join lines which begin with '{' to the line
above:
:g/^\s*{/.-1join
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: reformat c code
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 really played with it; have never had the need! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: gvim problem with
!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 soon as control is returned (which is basically immediately due to your ). I come up with this solution: :!nohup xclock sleep 1 The 'nohup' disconnects xclock from its controlling terminal, so it doesn't die when the ptty is killed. And the sleep 1 gives nohup enough time to actually run so Vim doesn't kill it with the terminal before it has managed to disconnect itself! A bit of a hack, but if you just have it mapped to a key via a mapping, I guess it doesn't make any difference! Hope this helps! Developers: Would it perhaps be better to allocate a pseudo-terminal when the GUI starts and reuse it throughout Vim's session, much as if Vim were started from a terminal rather than creating and killing pttys every time a shell or filter is called? Or is this just more trouble than it's worth? Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Operator pending mode
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 text-object is
defined that allows you to operate on a function name whether the cursor is on
the
name itself or on its arguments. You can yank with yF, change with cF,
uppercase
with gUF, etc. I can't think of any other way to do this, or more complicated
language-based custom text-object definition--e.g. yank/change a whole
conjunction
or disjunction in a logic language, yank or change the condition of an 'if' or
'while' loop from anywhere within its body. Some of these would be more useful
than others, of course, but there are a lot of real world possibilities, I
think.
Ben.
:onoremap F Esc:call OperateFunctionName()CR
function! OperateFunctionName()
let last_count = v:count
let last_op = v:operator
let last_reg = v:register
exe normal \Esc
while search('\(\%#\i\|\i\s*\%#\)\i*\s*(','ce',line('.')+1) == 0
normal [(
endwhile
exe normal \BS\_yiw
echo 'normal '.(last_count0?(last_count):'').''.last_reg.last_op.'e'
endfun
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: (2, actually 3) Operator pending mode
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 text-object is
defined that allows you to operate on a function name whether the cursor is
on the
name itself or on its arguments. You can yank with yF, change with cF,
uppercase
with gUF, etc. I can't think of any other way to do this, or more complicated
language-based custom text-object definition--e.g. yank/change a whole
conjunction
or disjunction in a logic language, yank or change the condition of an 'if'
or
'while' loop from anywhere within its body. Some of these would be more
useful
than others, of course, but there are a lot of real world possibilities, I
think.
A better one:
:onoremap F Esc:call OperateFunctionName()CR
:function! OperateFunctionName()
: let save_count = v:count
: let save_op = v:operator
: let save_reg = v:register
: while search('\(\%#\i\|\i\s*\%#\)\i*\s*(','ce',line('.')+1) == 0
:if searchpair('(','',')','bW') == 0
: normal \Esc
: return
:endif
: endwhile
: exe normal \BS\_yiw
: exe 'normal '.save_reg.(save_count0?(save_count):'').save_op.'e'
:endfun
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: (2) Operator pending mode
[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 of the values. I suppose it can be one char, like d, but also something longer. How about the count, e.g., when I do 4d? Very happy to modify the patch to document this. It does not include the count; that is what v:count is for. And it will be two characters for commands that begin with 'g' or 'z', and one character otherwise. Happy to include an example or two as well. I emailed a candidate a few moments ago. Interested to hear what people think, and will do so before revising the patch. My gut feeling regarding this, though, would be that if people want to use this, they will know how they want to use it, so an example isn't really necessary and would probably add more clutter to the docs than insight. Still, as I said, I'm very happy to put one in the patch! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Operator pending mode
[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
demonstrated, and that Yankring is a pretty specific example, I thought perhaps
the best thing would be to put a brief example analogous to the v:prevcount
example which is right nextdoor in the docs.
If you still think a lengthier example is better, though, Bram, I'm happy to
revise the patch again. I thought this, or a scaled-down count-ignorant version
might be a more useful lengthy example (compared to the function name thing I
suggested before):
: Defines a motion/text-object C which allows you to operate on
: the {count}th column of a tab-delimited table, or the column
: the cursor is currently in if no count is given.
:onoremap C Esc:call OperateColumn()CR
:function! OperateColumn()
: let c = v:prevcount
: if c == 0
:call search('^\|\t\zs','bc',line(.))
: else
:call cursor(line(.),1)
:while search('\v(\zs[^\t]*(\t|$)){'.c.'}','c',line(.)) == 0
: call setline(line(.),getline(line(.)).\t)
:endwhile
: endif
: call feedkeys(''.v:register.v:operator)
: if strpart(getline(line('.')),col('.')-1,1) == \t
:call feedkeys(:\CR)
: else
:call feedkeys(search('\t','n',line(.)) == 0 ? $ : t\t)
: endif
:endfun
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: runtime/doc/eval.txt
===
--- runtime/doc/eval.txt(revision 621)
+++ runtime/doc/eval.txt(working copy)
@@ -1401,10 +1401,20 @@
This is the screen column number, like with |virtcol()|. The
value is zero when there was no mouse button click.
+ *v:operator* *operator-variable*
+v:operator The last operator given in Normal mode. This is a single
+ character except for commands starting with g or z,
+ in which case it is two characters. Best used alongside
+ |v:prevcount| and |v:register|. Useful if you want to cancel
+ Operator-pending mode and then use the operator.
+ :omap O Esc:call MyMotion(v:operator)CR
+ Read-only.
+
*v:prevcount* *prevcount-variable*
v:prevcountThe count given for the last but one Normal mode command.
This is the v:count value of the previous command. Useful if
- you want to cancel Visual mode and then use the count.
+ you want to cancel Visual or Operator-pending mode and then
+ use the count.
:vmap % Esc:call MyFilter(v:prevcount)CR
Read-only.
Index: src/vim.h
===
--- src/vim.h (revision 607)
+++ src/vim.h (working copy)
@@ -1688,7 +1688,8 @@
#define VV_MOUSE_WIN 49
#define VV_MOUSE_LNUM 50
#define VV_MOUSE_COL 51
-#define VV_LEN 52 /* number of v: vars */
+#define VV_OP 52
+#define VV_LEN 53 /* number of v: vars */
#ifdef FEAT_CLIPBOARD
Index: src/eval.c
===
--- src/eval.c (revision 607)
+++ src/eval.c (working copy)
@@ -345,6 +345,7 @@
{VV_NAME(mouse_win, VAR_NUMBER), 0},
{VV_NAME(mouse_lnum, VAR_NUMBER), 0},
{VV_NAME(mouse_col, VAR_NUMBER), 0},
+{VV_NAME(operator,VAR_STRING), VV_RO},
};
/* shorthand */
@@ -17260,6 +17261,35 @@
}
/*
+ * Set v:operator if needed.
+ */
+void
+set_op_var(optype)
+intoptype;
+{
+/* This will either be two operator characters, or one and a NUL. */
+char_u opchars[2];
+
+if (optype == OP_NOP)
+{
+ set_vim_var_string(VV_OP, NULL, 0);
+ return;
+}
+
+opchars[0] = get_op_char(optype);
+if (opchars[0] == 'g' || opchars[0] == 'z')
+ opchars[1] = get_extra_op_char(optype);
+else
+ opchars[1] = 0;
+
+/* Avoid free/alloc when the value is already right. */
+if (vimvars[VV_OP].vv_str == NULL ||
+ vimvars[VV_OP].vv_str[0] != opchars[0] ||
+ vimvars[VV_OP].vv_str[1] != opchars[1])
+ set_vim_var_string(VV_OP, opchars, opchars[1]==0?1:2);
+}
+
+/*
* Get or set v:exception. If oldval == NULL, return the current value.
* Otherwise, restore the value to oldval and return NULL.
* Must always be called
Re: file name with parentheses
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 it usable in or ''. I mean like in :he filename-modifiers . Or would it be too way out to suggest that % automatically quote itself if it finds it's not already inside or ''? My suspicion is that escaping within quotes is more consistent across different shells than without quotes. Trouble is, is there any time you would want to use % inside quotes yet with other text also in the quotes...Hmmm...probably someone would have a reason to want to...But then, in those rare cases, one could resort to :exe and put together a more carefully constructed expression. For simple use of % perhaps auto-quoting is the best option. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: (2) automatic setting of 'diff'
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, you should use setlocal, not set. See :help local-options Ben. And if you're not familiar with it, the :diffthis command is also helpful specifically for diffing, and I believe does all its magic locally without touching global options. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug with )
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. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Documentation error for :sort
: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 digit
in
the line. The correct command would be something like
:sort /.\{-}\ze\d/
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Documentation error for :sort
: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 digit
in
the line. The correct command would be something like
:sort /.\{-}\ze\d/
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Bug with )
[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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
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 tabs to an extraordinary degree, but in my day to day usage, this has worked fine, and has been helpful when viewing and editing files with tab separated data. I'm still hoping that this can be considered for inclusion in a not-to-distant future version of vim. Thanks. I tried out your script and it works very well. When I get the time I'll update the patch to the latest patch of Vim, as my patch is against 7.1.145. I tried it out for the first time editing some real data today, and it made the job about 1000% times easier. The new feature and the AutoTabs command, which I now have living in my ~/.vim/plugins folder are both brilliant. Of course, if I find any anomalies, I will let you know, but so far, so good! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
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 accessing a variable to get the key. ~Matt I'm not sure the point is really to stop a cracker. If someone has access to your terminal with your user privileges and the password is stored, encrypted or not, they can get at it, unless decrypting it requires typing a password which defeats the point, of course. Rather, I would think the value in this is more so that if you're working with somebody else observing and for some reason issue :let or such, your password doesn't magically appear on the screen in plaintext for all to see. Passwords usually don't appear on the screen in plaintext as you're typing them, and they shouldn't be easy to accidentally bring up in plaintext for anyone who happens to be watching to see. To solve the problem, the encryption needn't be strong--it just needs to be good enough that casual inspection wouldn't reveal it, i.e. not just rot13. Likewise, a plaintext password shouldn't be stored in a session file--better to store some garbage that can't be decrypted next time, and require the user to retype the password once per session. So, far from being an attempt to stop a cracker who has access to your session, which is a hard kind of cracker to stop, it's more an attempt to stop accidental discovery of your password, or to stop yourself accidentally revealing it (e.g. by saving a session--who'd have thought that could reveal your password?). That's my take on it, anyway. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
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 stack after use. Unless Vim dumps core while it is decrypting the pw, but in that case it's also likely the pw is stored in plaintext somewhere as well. But, yes, that said, protecting against someone with access to core files is next to impossible. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Long-standing bug in php.vim
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 instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim 7 segfaults on file name completion
[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 ~xxxTABTABTAB If you do the above a couple of times vim will segfault, at least on my machine it is completely reproducable: I get what is probably a related problem; Mac OS X 10.4.9. vim -u NONE -N :e ~xxxTabTab On the second Tab I get messages vim(24115) malloc: *** error for object 0x410930: double free vim(24115) malloc: *** set a breakpoint in szone_error to debug Of course, there is no user xxx on my system. :-) Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Newbie question: how/where do I submit a bug (and possibly a patch)?
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 messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Newbie question: how/where do I submit a bug (and possibly a patch)?
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 at, funnily enough :help bugs Cheers, Ben. Equally funny is that once I have it built and running enough to be able to do that, I'll probably have fixed the bug myself and it will be a non-issue at that point. O dear, what a shame! I presumed by 'bug' you meant something wrong with a running Vim, not a problem building Vim. Bugs and build problems are frequently discussed on this list, which is mentioned briefly at :help bugs, too, so post away and we'll see if someone can help. For interest/information, I've pasted the section of the help below. Smiles, Ben. Bug reports:*bugs* *bug-reports* *bugreport.vim* Send bug reports to: Vim bugs [EMAIL PROTECTED] This is not a maillist but the message is redirected to the Vim maintainer. Please be brief; all the time that is spent on answering mail is subtracted from the time that is spent on improving Vim! Always give a reproducible example and try to find out which settings or other things influence the appearance of the bug. Try different machines, if possible. Send me patches if you can! It will help to include information about the version of Vim you are using and your setup. You can get the information with this command: :so $VIMRUNTIME/bugreport.vim This will create a file bugreport.txt in the current directory, with a lot of information of your environment. Before sending this out, check if it doesn't contain any confidential information! If Vim crashes, please try to find out where. You can find help on this here: |debug.txt|. In case of doubt or when you wonder if the problem has already been fixed but you can't find a fix for it, become a member of the vim-dev maillist and ask your question there. |maillist| Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: I care about vim rfc1345 switch
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, switching my linux distro to suse 10.3, and yes, I really care. I am a french-speaking programmer, so I use a qwerty-us keyboard beacause it is much easier for programming, but I need sometimes to produce french texts. Previously, I could use the CTRL-K combinations with ` (backquote or grave) to introduce grave accents, ^ (circumflex) for circumflex accents and for diaeresis, juste like on a typing machine. RFC1345 recommends : ! instead of ` for grave accent instead of ^ for circumflex accent : instead of for diaeresis Frankly I do not understand why RFC1345 has choosen that. I think the reason is that RFC 1345 isn't designed for what vim is using it for. Its goal is to provide an unambiguous short ASCII name for characters, not to give convenient keyboard combinations for invoking those characters in an editor. Admittedly these goals are similar, so using RFC 1345 is at least a good start. However, RFC 1345 is further constrained by using only a limited set of characters on which there is a high degree of agreement about the encoding. For example, ` is not one of the characters used. If it were up to me, I'd support the RFC 1345 combinations, but add many more as standard vim mappings. I use digraphs frequently to enter Unicode characters, and I find the RFC 1345 mappings often uninituitive or simply absent for characters of interest. I wholeheartedly agree with both of you. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in src/Makefile
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 link, you would do nothing rather than copy instead, or provide some other kind of second-best mechanism that's...well...better than nothing. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug: Win32 guitabtooltip doesn't respect backslash-escaped special chars
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. I for one would be interested in knowing what actually is 'expected' in this circumstance. I personally think that's quite unclear and am not at all surprised there is a difference between platforms. I guess it's obvious that \n should be a newline. But should they be left justified? Or centered? Or...? If tabs are used, should they line up, given the proportional font? What width should they be? Etc.? Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: gvim is slow opening, saving, and scanning tags on a file across the network
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 one of these files using notepad, it opens instantly. When I try to open one of these files using gvim, it hangs for about 20 seconds before opening. I get the same 20 second delay when saving files, and also when attempting to do tab completion (scanning tags). This happens 90% of the time, the other 10%, I get lucky, and it works instantly. I have tried disabling plugins and syntax highlighting, to no avail. Any ideas? VIM normally creates a 'swapfile' in the same directory as the edited file (cp. :help swap-file). This file creation can take some time on a network share. Try launching VIM with the -n argument (no swapfile), e.g. gvim -n \\hostname\share\myfile.txt. If this fixes the problem, you can selectively disable swapfile creation for this network share (but keep swapfiles for local files) by setting up an exception in your .vimrc file: autocmd BufReadPre //hostname/* setlocal noswapfile Also see :help 'directory' which you can use to store swapfiles for remote files locally for safety. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch for Unix filename expansion to try out
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 try at some later stage when I have time/will to copy and apply the patch, but I always had problems when a partially completed filename contained a single quote where it wouldn't complete further. With wildmode=longest,list,full and files with names It's good It's bad It's ugly the completion would always fail. I would type ITab which would yield It\'s\ typing gTab then would fail with a beep. Also, it was somewhat odd to obtain, for these files It is odd It's odd If I give ITab the result is It\. Kinda fair enough as whatever character comes next does need to be escaped, but still, seems a little strange. At any rate, those are my experiences and it would be interesting to know if they're fixed. It is really the quotes that caused problems. Completing works fine for a set of files like It is good It is bad It is ugly Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Minor bugfix for MODIFIED_BY
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 vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: src/version.c
===
--- src/version.c (revision 728)
+++ src/version.c (working copy)
@@ -1553,9 +1553,9 @@
if (*mesg == ' ')
{
- vim_strncpy(modby, _(Modified by ), MODBY_LEN - 1);
+ vim_strncpy(modby, (char_u *)_(Modified by ), MODBY_LEN - 1);
l = STRLEN(modby);
- vim_strncpy(modby + l, MODIFIED_BY, MODBY_LEN - l - 1);
+ vim_strncpy(modby + l, (char_u *)MODIFIED_BY, MODBY_LEN - l - 1);
mesg = modby;
}
#endif
Changes to make Vim compile with X on OS X
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 they weren't quite sorted out right. The attached patch fixes it by moving code around: - 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 - A chunk of code from option.c has also been moved to os_mac_conv.c as 'mac_lang_init()'. - And a preprocessor conditional in globals.h was changed so X headers aren't expected when they aren't available. I thought it was the best of a bad bunch of options for fixing the issues. It now compiles for me, configured with ./configure --with-features=huge --enable-pythoninterp --enable-perlinterp --enable-rubyinterp --enable-tclinterp --enable-cscope --enable-gui=gtk2 It would be good to have this or a similar fix in the official distribution. Might this have an effect on MacVim, Bjorn, or vim-coco, Jiang (sorry if names wrong...memory is hazy)? If so, perhaps you could suggest a better solution? Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Changes to make Vim compile with X on OS X [with attachment]
[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 what is disabled,
and
there's no easy way to reconcile it by playing preprocessor games.]
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 they weren't quite sorted out
right. The attached patch fixes it by moving code around:
- 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
- A chunk of code from option.c has also been moved to os_mac_conv.c
as 'mac_lang_init()'.
- And a preprocessor conditional in globals.h was changed so X headers
aren't expected when they aren't available.
I thought it was the best of a bad bunch of options for fixing the issues.
It now compiles for me, configured with
./configure --with-features=huge --enable-pythoninterp --enable-perlinterp
--enable-rubyinterp --enable-tclinterp --enable-cscope --enable-gui=gtk2
It would be good to have this or a similar fix in the official distribution.
Might this have an effect on MacVim, Bjorn, or vim-coco, Jiang (sorry if names
wrong...memory is hazy)? If so, perhaps you could suggest a better solution?
Cheers,
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: src/option.c
===
--- src/option.c(revision 728)
+++ src/option.c(working copy)
@@ -3267,20 +3267,7 @@
}
# else
# ifdef MACOS_CONVERT
-if (mch_getenv((char_u *)LANG) == NULL)
-{
- charbuf[20];
- if (LocaleRefGetPartString(NULL,
- kLocaleLanguageMask | kLocaleLanguageVariantMask |
- kLocaleRegionMask | kLocaleRegionVariantMask,
- sizeof buf, buf) == noErr *buf)
- {
- vim_setenv((char_u *)LANG, (char_u *)buf);
-# ifdef HAVE_LOCALE_H
- setlocale(LC_ALL, );
-# endif
- }
-}
+mac_lang_init();
# endif
# endif
Index: src/proto/os_mac_conv.pro
===
--- src/proto/os_mac_conv.pro (revision 728)
+++ src/proto/os_mac_conv.pro (working copy)
@@ -4,8 +4,6 @@
int enc2macroman __ARGS((char_u *from, size_t fromlen, char_u *to, int
*tolenp, int maxtolen, char_u *rest, int *restlenp));
void mac_conv_init __ARGS((void));
void mac_conv_cleanup __ARGS((void));
-char_u *mac_utf16_to_enc __ARGS((UniChar *from, size_t fromLen, size_t
*actualLen));
-UniChar *mac_enc_to_utf16 __ARGS((char_u *from, size_t fromLen, size_t
*actualLen));
-CFStringRef mac_enc_to_cfstring __ARGS((char_u *from, size_t fromLen));
char_u *mac_precompose_path __ARGS((char_u *decompPath, size_t decompLen,
size_t *precompLen));
+void mac_lang_init __ARGS((void));
/* vim: set ft=c : */
Index: src/gui_mac.c
===
--- src/gui_mac.c (revision 728)
+++ src/gui_mac.c (working copy)
@@ -60,6 +60,9 @@
#ifdef MACOS_CONVERT
# define USE_CARBONKEYHANDLER
static EventHandlerUPP keyEventHandlerUPP = NULL;
+static char_u *mac_utf16_to_enc __ARGS((UniChar *from, size_t fromLen, size_t
*actualLen));
+static UniChar *mac_enc_to_utf16 __ARGS((char_u *from, size_t fromLen, size_t
*actualLen));
+static CFStringRef mac_enc_to_cfstring __ARGS((char_u *from, size_t fromLen));
#endif
@@ -6466,5 +6469,213 @@
RevealDataBrowserItem(dataBrowser, item, kTabsColumn,
kDataBrowserRevealOnly);
}
+#endif // FEAT_GUI_TABLINE
-#endif // FEAT_GUI_TABLINE
+#if defined(MACOS_CONVERT)
+/*
+ * Conversion from UTF-16 UniChars to 'encoding'
+ */
+static char_u *
+mac_utf16_to_enc(from, fromLen, actualLen)
+UniChar *from;
+size_t fromLen;
+size_t *actualLen;
+{
+/* Following code borrows somewhat from os_mswin.c */
+vimconv_T conv;
+size_t utf8_len;
+char_u *utf8_str;
+char_u *result = NULL;
+
+/* Convert to utf-8 first, works better with iconv */
+utf8_len = 0;
+utf8_str = mac_utf16_to_utf8(from, fromLen, utf8_len);
+
+if (utf8_str)
+{
+ /* We might be called before we have p_enc set up. */
+ conv.vc_type = CONV_NONE;
+
+ /* If encoding (p_enc) is any unicode, it is actually in utf-8 (vim
+*
Re: Changes to make Vim compile with X on OS X [with attachment]
- 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 MACOS_CONVERT when building with GTK? Yeah, you can, but (1) that doesn't fix it, because os_mac_conv.pro contains prototypes with Mac-specific types in them for those functions that weren't static in os_mac_conv.c originally, and (2) if you undefine that, you lose MacRoman support. Maybe the better solution would be to assume the types won't change (they surely never will!) and use some casts. Since the main problem is os_mac_conv.pro, if we can just get the types out of the function signatures, we will be good: UniChar = unsigned short (CFBase.h) CFStringRef is a pointer type (as are all .*Ref, I believe) so could use void *. - And a preprocessor conditional in globals.h was changed so X headers aren't expected when they aren't available. This isn't quite right, Win32 also has the balloon eval functionality. And GTK too, so how can you omit this? OK. I presume it's only a problem when we have Mac headers included, in which case, we can use !defined(NO_X11_INCLUDES) instead of defined(FEAT_X11) and I think that will cover it. What GTK did you install? One that MacPorts installs. 2.0.10, I think. Anyone know how I check easily? It would be good to have this or a similar fix in the official distribution. Only when I'm sure it doesn't break anything. Yeah. I'm quite unsure myself which is why I wrote so much detail about it and suggested something 'similar', by which I mean 'something that also works for me but probably works better for everyone else too'! I'll have a fiddle with it and if it works, send a revised patch in a few minutes. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Changes to make Vim compile with X on OS X [with attachment]
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 Mac-specific prototypes in os_mac_conv.pro. But if you look, none of the MacRoman functions have moved anyway, only Unicode ones that it seems only things like clipboard support use in plain Vim. The MacRoman stuff was left in os_mac_conv.c. Does MacVim use those same functions, though? But as per my previous email, perhaps it is better to leave them where they are and use casts. I'll see if it works that way and send a patch shortly if it does. Then Bram can choose which he reckons is better. :-) It's probably a good thing to have available for use by other Mac-related GUIs, even if MacVim doesn't use them yet. Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Revised patch for Mac OS X and X together
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 said, it probably wouldn't
cause
things to break--it just feels dirty/dangerous, though it is very safe. What do
you think now, guys? Is it looking good, or in need of further improvement?
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: src/option.c
===
--- src/option.c(revision 728)
+++ src/option.c(working copy)
@@ -3267,20 +3267,7 @@
}
# else
# ifdef MACOS_CONVERT
-if (mch_getenv((char_u *)LANG) == NULL)
-{
- charbuf[20];
- if (LocaleRefGetPartString(NULL,
- kLocaleLanguageMask | kLocaleLanguageVariantMask |
- kLocaleRegionMask | kLocaleRegionVariantMask,
- sizeof buf, buf) == noErr *buf)
- {
- vim_setenv((char_u *)LANG, (char_u *)buf);
-# ifdef HAVE_LOCALE_H
- setlocale(LC_ALL, );
-# endif
- }
-}
+mac_lang_init();
# endif
# endif
Index: src/proto/os_mac_conv.pro
===
--- src/proto/os_mac_conv.pro (revision 728)
+++ src/proto/os_mac_conv.pro (working copy)
@@ -4,8 +4,9 @@
int enc2macroman __ARGS((char_u *from, size_t fromlen, char_u *to, int
*tolenp, int maxtolen, char_u *rest, int *restlenp));
void mac_conv_init __ARGS((void));
void mac_conv_cleanup __ARGS((void));
-char_u *mac_utf16_to_enc __ARGS((UniChar *from, size_t fromLen, size_t
*actualLen));
-UniChar *mac_enc_to_utf16 __ARGS((char_u *from, size_t fromLen, size_t
*actualLen));
-CFStringRef mac_enc_to_cfstring __ARGS((char_u *from, size_t fromLen));
+char_u *mac_utf16_to_enc __ARGS((unsigned short *from, size_t fromLen, size_t
*actualLen));
+unsigned short *mac_enc_to_utf16 __ARGS((char_u *from, size_t fromLen, size_t
*actualLen));
+void * mac_enc_to_cfstring __ARGS((char_u *from, size_t fromLen));
char_u *mac_precompose_path __ARGS((char_u *decompPath, size_t decompLen,
size_t *precompLen));
+void mac_lang_init __ARGS((void));
/* vim: set ft=c : */
Index: src/gui_mac.c
===
--- src/gui_mac.c (revision 728)
+++ src/gui_mac.c (working copy)
@@ -446,7 +446,7 @@
CFMutableStringRef cleanedName;
menuTitleLen = STRLEN(menu-dname);
-name = mac_enc_to_cfstring(menu-dname, menuTitleLen);
+name = (CFStringRef) mac_enc_to_cfstring(menu-dname, menuTitleLen);
if (name)
{
@@ -5752,7 +5752,7 @@
#ifdef MACOS_CONVERT
windowTitleLen = STRLEN(title);
-windowTitle = mac_enc_to_cfstring(title, windowTitleLen);
+windowTitle = (CFStringRef)mac_enc_to_cfstring(title, windowTitleLen);
if (windowTitle)
{
@@ -6084,7 +6084,7 @@
{
get_tabline_label(page, FALSE);
#ifdef MACOS_CONVERT
-return mac_enc_to_cfstring(NameBuff, STRLEN(NameBuff));
+return (CFStringRef)mac_enc_to_cfstring(NameBuff, STRLEN(NameBuff));
#else
// TODO: check internal encoding?
return CFStringCreateWithCString(kCFAllocatorDefault, (char *)NameBuff,
Index: src/os_mac_conv.c
===
--- src/os_mac_conv.c (revision 728)
+++ src/os_mac_conv.c (working copy)
@@ -318,10 +318,12 @@
/*
* Conversion from UTF-16 UniChars to 'encoding'
+ * The function signature uses the real type of UniChar (as typedef'ed in
+ * CFBase.h) to avoid clashes with X11 header files in the .pro file
*/
char_u *
mac_utf16_to_enc(from, fromLen, actualLen)
-UniChar *from;
+unsigned short *from;
size_t fromLen;
size_t *actualLen;
{
@@ -370,8 +372,10 @@
/*
* Conversion from 'encoding' to UTF-16 UniChars
+ * The function return uses the real type of UniChar (as typedef'ed in
+ * CFBase.h) to avoid clashes with X11 header files in the .pro file
*/
-UniChar *
+unsigned short *
mac_enc_to_utf16(from, fromLen, actualLen)
char_u *from;
size_t fromLen;
@@ -428,8 +432,9 @@
/*
* Converts from UTF-16 UniChars to CFString
+ * The void * return type is actually a CFStringRef
*/
-CFStringRef
+void *
mac_enc_to_cfstring(from, fromLen)
char_u *from;
size_t fromLen;
@@ -555,4 +560,25 @@
return result;
}
+
+/*
+ * Sets LANG environment variable in Vim from Mac locale
+ */
+void
+mac_lang_init() {
+if (mch_getenv((char_u *)LANG) == NULL)
+{
+ charbuf[20];
+ if (LocaleRefGetPartString(NULL,
+ kLocaleLanguageMask |
Re: Patch for Unix filename expansion to try out
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. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Triggering abbrevs
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 be quite 'unsafe' to trigger without an explicit command. The whole point of noremap is to ignore all user customisations so that Vim behaves completely predictably. Expanding abbreviations would undermine this. It wouldn't be so bad in insert mode as in command mode, but it still would be bad. But if C-] is a command to expand an abbreviation, then indeed, it should surely do so even for a noremap, as that is its function! I would say it's a bug that that doesn't work. 2. The key i_Ctrl-] is supposed to trigger an abbrev without inserting a character. Now it does insert itself if there is no abbrev to expand. How is this useful in any way? IMHO it should never insert itself. I would agree with that. If it's a command, it should be a command; if it's not a command, it should insert itself; it shouldn't decide on the spur of the moment which it wants to be. I'd probably call that a bug too. My Vim exhibits the same behaviours. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Triggering abbrevs
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 'exit insert mode', not 'change the text in user-customised ways and then exit insert mode'. But more importantly, if I put something like iword on the right hand side of a mapping, I expect 'word' to be inserted, not expanded as an abbreviation. Much more important is if I put ':command something' on the right hand side of a mapping, I expect ':command' to get executed, not something else that the user has defined as an abbreviation. I would think a good number of scripts would break if the interpretation were yours and thus the behaviour changed (any mapping that inserts text has the potential to break!). At least a dedicated key like i_Ctrl-] should work always. Mmm. Looks like we all agree on that one. The current behaviour looks like a side effect by accident, also because it seems to be ignored in the help. Fair point. And as they say, if a program is useful, it will have to be changed; if a program is useless, it will have to be documented. Even if the behaviour isn't ideal, at least if it's documented, people know what to expect--and if a workaround is documented, too, unwanted side effects can be avoided. Of course, we don't have a workaround for all of it yet... Grins, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Triggering abbrevs
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 drawing that distinction, but just
thought you had a 'minimal test case'. I guess that would be fair enough,
though
I'd probably still personally prefer the consistency of a noremap never
expanding
abbreviations without an explicit C-].
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Bug in @{reg} together with [EMAIL PROTECTED]
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.) You're missing a :, the Esc in the mapping clears the command line but doesn't put the : back to receive the }j^M which instead become normal commands (end of paragraph, cursor down, cursor to next line). Either record g::}j^M or use map g: Esc:set operatorfunc=SIDget_command_mode_rangeCRg@: Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in @{reg} together with [EMAIL PROTECTED]
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)
elseif b == e
let range = '.'
else
let range = '.,+' . (b - e)
endif
call feedkeys(':' . range, 'n')
endfunction
Mmm. And excuse my dumb reply from earlier that was agnostic about your
function.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Bug with )
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 believe Bram fixed this bug with patch 190-something. I long way off your version, by the look of it. It seems to work in my Vim now, though, which is 7.1.203. Though, Bram, perhaps if 've' contains onemore, it should indeed place the cursor beyond EOL? It doesn't now in either case. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug with )
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 this bug with patch 190-something. I long way off your version, by the look of it. It seems to work in my Vim now, though, which is 7.1.203. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Scoping in nested functions: How should it work?
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() - Except that the Inner function is defined before calling Outer, not during the call of Outer. It might help to realise that in Vim, 'function' is a command that defines a function in global scope (or script scope sometimes). You can run this command whenver you like to define a function, and it always does the same thing. It is NOT a program syntactical construct that defines a function at the point where it is placed in the code. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] Cross-compilation patch to avoid looking for /usr/local at compile time
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 positive vote or whatever is necessary to bless it and assure its commission. I sent it out-of-band a couple of times to Bram but it hasn't been approved (or rejected for that matter), so I figure I should be sending it to someone else (but don't know who that would be). Bram is the right person to send it to. His to do list is massive, but if you update your runtime files and do :help todo.txt you will find this on it: Patch for configure.in to support cross-compiling: Marc Haisenko, 2007 Sep 24. Again 2007 Dec 12 Some more from Philip Prindeville, 2007 Dec 18. Thus he will get around to it when he has the time, and when he does, it will be accepted, or accepted with modifications, or you'll be contacted to address one issue or another. I believe he is particularly careful about making changes to the build process of Vim, because it needs to work on so many systems. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in syntax/mail.vim
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/). That is true. In case there is an opening bracket in the URL, I do think highlighting the closing bracket as well would make sense, though. Yeah. I think it would make sense, too, but it's horrible to code nicely and reliably. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in syntax/mail.vim
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 browser/software. So a web browser shouldn't serve different pages, as brackets don't have a reserved purpose in http URIs. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Repost: [PATCH] Enable cross-compiling
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 has been having trouble reaching you (emails bouncing). If ones he sends to you via the mailing list bounce too, it could get tricky! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Repost: [PATCH] Enable cross-compiling
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 decide to be grumpy and drop mail like this. Ben. Bram wrote: The reason you don't hear from me is that most of my emails to you bounce back. What I tried to say: excluding /usr/local/[include|lib] is not specific for cross compiling. This should be a separate setting. Then it can also be set for cross compiling. Most configure features are explained in the Makefile. Or in the INSTALL file. I prefer the Makefile, there you can uncomment a line to have it used, no need to type it (configure doesn't warn for unrecognized arguments). -- Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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 machine, quite possibly both via ssh. That's how I'd expect to use it; log into someone else's machine and somehow attach to their Vim process to help them edit a file. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
- 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 buggy at the moment, in that it doesn't correctly update the global values. I need to bring my Linux machine up and have a look at it. Also, it uses the same tabstops over an entire file. An extended idea is to find some way of specifying different tab widths at different parts of the same file, but that means a heap of empty cans and worms all over the place. I think this is a much bigger problem than tabstops, and not worth addressing until a true and general solution can be found. The problem is basically that of having 'context-local' option settings, i.e. options that aren't global, nor local to a buffer or window, but local to a part of a file. Vim has no way of doing this though there are a number of occasions where it would be useful, and as you say there are many cans of worms if this is pursued. And, to be honest, the need for this is small. If a file uses different width tab stops for different parts of the file it would either be (1) Vim-specific and reliant on the Vim variable tabs feature or (2) some mish mash of files that should be in separate files anyway (i.e. somebody probably catted two different datafiles together) or (3) use spaces not tabs anyway. In those rare cases, it's no big deal to change the tabstop settings to work on the part of the file you're interested in, IMHO, especially if the AutoTabs command (I forget who provided this) is updated to accept a range (I have been meaning to do this as it does annoy me that it doesn't at present; often I have a small amount of paragraph text/comments with no tabs at all followed by a table and at present the comments push the first tab to the right side of the screen all the time, and so I delete the comments, run AutoTabs and replace them; would be much better to select the table and run AutoTabs on just that part). Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Exposing line/file/function call stack for debugging
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 didn't realise sfile behaved like that. But what I was envisaging was something richer, i.e. with line numbers and source file as Chip had suggested. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
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 tables I'd like to see something simpler(?): better command line completion of built-in commands. You can script user defined commands as you wish to perform all magic but completion of many built-in commands is really dumb. For example I am working lately with Tab Separated Values. When I try to insert Tab into regular expression of vimgrep Vim constantly tries to resolve it to file name. I have to resort to C-VC-I. m. To search for a hard tab, use \t in the pattern. Currently, :command can have at most one -complete= parameter. I suspect this unicity also applies to builtin commands. And maybe I'm just dumb, but isn't auto-complete on a regular expression a bit of a silly idea?! If it's so obvious from what you've already typed what it should be completed to, you probably already have enough typed there to do the search... Inserting Tab as ^I isn't auto-complete, but lack thereof, and \t, as Tony points out, is a better way of doing that anyway, even though it involves pressing an extra key. Another way of getting around it would be to use a different key to Tab for your autocomplete (if there's a key you need to enter less often)! Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to save a UTF-8 file on Windows using a non-ASCII name
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' and 'fenc' confused on a regular basis, and this feature naming really doesn't help matters. What would you think of changing this, Bram? Perhaps making it officially ++fenc but accepting ++enc for compatibility with old scripts (and old users!)? These are not really option names, although I can see that they are so similar that people might think that. They are options for the command. Offering more alternatives isn't going to make it simpler. We also don't have 'fbin' for reading a file in binary mode. Yes, I realise they're not option names, but they undeniably do look like it, and time and time again we see people getting 'fenc' and 'enc' confused, and ++ff sets 'ff' when reading, ++bin sets 'bin', but ++enc sets 'fenc'. This is only confusing because there *is* an option called 'enc'. If there weren't, as there isn't a 'fbin' option, nor a 'format' option, it would be no problem. But, hey, it's not too important. I just thought I'd throw it out there, as I think it has potential to help a lot of users avoid confusion. Maybe I'm wrong. It would be interesting to hear what others think. Also, I wonder whether it might be worth adding a 'best practices' section to mbyte.txt and referring to it in such places as 'enc' (probably mostly there) which explains the basics in a few short paragraphs: set 'enc' in your .vimrc (recommend utf-8), 'tenc' if your terminal/locale is different (unneeded in GUI), use ++fenc if a file is read with wrong encoding detected, 'fenc' to change what encoding to write a file with for future writes. This sort of material is repeated frequently on the mailing lists which suggests users aren't finding it easily in the help (though it is all there, it is somewhat spread around, etc.). Do others think this might or something similar might be a good idea? It will certainly help to update the documentation to explain common pitfalls. Writing this in a nice way, without becoming too verbose and putting it in the right place is not easy. If you or someone else can suggest a patch that would be great. I agree. Terseness is definitely not my strength, though, so I might leave this to someone else to have a try if anyone is willing. Volunteers? Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Pressing CTRL-G in visual mode causes vim to use 100% of the CPU.
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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Pressing CTRL-G in visual mode causes vim to use 100% of the CPU.
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 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug with setglobal
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, 'modifiable' is off: fenc=anything Obviously neither the failure nor the message is appropriate. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug with setglobal
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 friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: VIM and NTFS streams
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 attributes which were beautiful. Now we have descended to the level of extensions and magic numbers like everyone else. The filesystem supports resource forks and named forks, but nobody's really using them yet--indeed, if anything, at the moment they add confusion because some parts of the OS detect file types that way rather than by extension, when available, so it's hard to know what's going on. And that sad story told, I do agree with the other posters who don't think this has much use in Vim. I think to have some kind of consistency, probably an OS or other fairly central component needs to lead the way, not a text editor. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Doing :bufdo tabnew causes vim to hang, hog all resources
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 window--new makes it with a new empty buffer (possibly with a filename supplied for later writes), edit does it with the current buffer or a different file if provided a filename (it reads the file). Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Doing :bufdo tabnew causes vim to hang, hog all resources
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 that the buffer lists in other tabs do not know? Or can a tab be agnostic of buffers loaded by vim?). O, yes, sorry; I didn't explain fully. :tabnew creates a new tab with a new, empty, buffer. So, yes, you are right, it's because there is a new *buffer* that it keeps going and going and going; the fact that a new tab comes with each buffer is just coincidental. It might work if you used :tabedit which edits a file in a new tab, rather than opening a new file in a tab, i.e. :bufdo tabedit I also had some philosophical questions in my post whose MID I referred above (as in Why tabs?). I don't know how to search for a message by its MID, I'm afraid. Does google have a facility for it or something? Can you provide a link to the webpage view of the message or something? Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.243
(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 disappears, appears, disappears ... (3) Write a line without any ß. Visual select the whole line and do U. The line is upercase afterwards and the Visual selection is gone (which is ok). But if you do U repeatedly now, you will see the whole line alternate between lowercase and uppercase. None of these are bugs. In normal mode, U means single-line undo/redo. Only with a visual selection does it mean uppercase. gU means uppercase in normal mode as well as visual mode. In normal mode it is an operator that should be followed by a motion. Cheers, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: quickfix in foldopen doesn't work for keyboard mappings
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 foldopen option. And when I use :cprev/:cnext commands directly the folds open as expected. Looks like a bug? Maybe a bug, maybe not. It makes sense for folds to stay put in mappings unless explicitly requested to do something. Whether a bug or not, though, nmap C-Up :cprevCRzv nmap C-Down :cnextCRzv should be a workaround. I guess you probably knew that, but thought I'd mention anyway. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.262
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 http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.262
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 adding such an explanation to the docs would just add noise. If in doubt, it's better to be precice. LOL. Was that deliberate?! 'Precise.' Smiles, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: a problem about regex
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 regular expression in vim to change all spaces into ``0'',but i can't do this in one operation. my way is like this: esc:%s/\(\d\.\ *\)\ /\10/g 6g Many ways... One is something like this :%s/\d\. */\=tr(submatch(0), ,0) See :help :s\= :help tr() :help submatch() Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: a problem about regex
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 the % is doing in the middle, either. But an approach that tries to replace only a single occurrence at a time and catch the rest with /g won't work for this problem, because it can't find all the occurrences at the outset. So maybe there aren't that many ways after all. Smiles, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: a problem about regex
: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 ways after all! Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug: Can't replace highlighted text with Q!
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 things aren't silently changed...they aren't changed at all. Mostly. Essentially the same advice is at :help not-compatible There are pros and cons to each approach, of course. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim script line continuation?
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 So? You can also indent your scripts weirdly, e.g. reducing the indent after an if command, or even messily, e.g. indenting your lines by the result of tossing a 20-side die, regardless of syntax. To the best of my knowledge, in neither case did anyone ever recommend it. The vim-script syntax disregards all spaces and the preceding linebreak preceding a backslash which is the first non-blank on a line; it also disregards indenting (which is only there to make the script more readable to human people). That doesn't mean there is no such thing as good script writing style, which would be stricter than going by anything the parser would accept. In the same way, it _is_ possible to write C or CSS by removing all indent, all comments, all unnecessary spaces, and filling the lines to, let's say, the longest possible length shorter than 160 characters; the C compiler or the browser won't give an error, but I would never call that good programming style. And indeed, it is worth posting the link for those who are not already familiar with the International Obfuscated C Code Contest. http://www.ioccc.org/ Cheers, Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Documentation inaccuracy re. writing whole buffer
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 '+' is in 'cpoptions', which isn't the Vim default. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Documentation inaccuracy re. writing whole buffer
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 '+' is in 'cpoptions', which isn't the Vim default. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Documentation inaccuracy re. writing whole buffer
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 with :w somefile! The last sentence is only true if '+' is in 'cpoptions', which isn't the Vim default. Ben. I think this is due to an accidental lack of update at that location in that helpfile: it still describes the old behaviour from version 6. See the following help snippet: Aaah. Thanks, Tony. That was vaguely what I thought, too, but I searched and couldn't find that snippet--was looking in the wrong places (patches mostly). Ben. INCOMPATIBLE CHANGES *incompatible-7* These changes are incompatible with previous releases. Check this list if you run into a problem when upgrading from Vim 6.x to 7.0. A :write file command no longer resets the 'modified' flag of the buffer, unless the '+' flag is in 'cpoptions' |cpo-+|. This was illogical, since the buffer is still modified compared to the original file. And when undoing all changes the file would actually be marked modified. It does mean that :quit fails now. Best regards, Tony. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: regexp: does anyone really need ordered alternation?
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 the new regexp. But the problem is, ordered alternation is kind of 'side effect' of the original back track regexp matcher. AFAIK, It is very hard to implement this feature in the new, truly NFA matcher, if it is not impossible. We can resort to the original regexp when we see '\|', but we don't solve the problem perfectly. So does anyone really need this feature to be kept? If so, please do tell me. For me, the removal of this 'feature' won't break anything. I prefer the behaviour which I presume you have in your NFA implementation, of preferring longer matches, just as * is greedy by default, so would actually welcome the change. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: regexp: does anyone really need ordered alternation?
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% compatibility is one of the project goals. So I try to keep this feature in the new regexp. But the problem is, ordered alternation is kind of 'side effect' of the original back track regexp matcher. AFAIK, It is very hard to implement this feature in the new, truly NFA matcher, if it is not impossible. We can resort to the original regexp when we see '\|', but we don't solve the problem perfectly. I thought Russ Cox had solved this in the code on his website, or am I mistaken? So does anyone really need this feature to be kept? I don't need it, and though I'd prefer the longest match rather than the first alternative (as specified by POSIX) I don't really care too much as long as it is well documented. And since the original vi didn't have alternation, we don't need to worry about compatibility in that regard. An interesting twist. Can you clarify which behaviour POSIX specifies (your sentence above is ambiguous)? If so, please do tell me. For me, the removal of this 'feature' won't break anything. It won't break anything that I use regexps for. But... I know Parsing Expression Grammars can make use of this feature to give precedence to one match over another. You might want to check whether any of the syntax files do something similar. --Antony I'm not sure a syntax file itself should, though it possibly could, because it would be in the ordering of the commands and Vim internal implementation of syntax highlighting that it would be relevant. I imagine the most robust way to test this would be automated testing--get a Vim script to output the synID for each character in a complex source file in each language and compare the output of Vims compiled with each regex engine. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
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
is invalid. Not sure whether that's desirable. Probably the lesser of two
evils.
Of course, it needs to be enforced that printf and such functions either omit
the
ampersand for floats which happen to be integers (probably undesirable) or
always
append a '.0' in this case.
Would wrapping floats in braces be a better syntax? I don't think this would
clash
with anything: dictionaries require keys followed by colons which don't occur
in
floats, and a float is also an invalid variable or function name due to
starting
with a digit or sign (+/-) so couldn't be used as part of curly-brace variable
or
function names. E.g.
:let myfloat={12.52}
:let mybig={1234e56}
:let myintegerfloat={123}
To me, this is nicer than a leading , and avoids the nasty restriction of
needing
a decimal point all the time/ambiguity of decimal point vs. concatenation.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Patch to try out: floating point
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 line causes it: sprintf(tmp, format, f); Here format is %f and f is your value 1e+308. The result is an awful long string of numbers. I suppose it's about 308 digits. How big does tmp need to be to hold any result here? I don't think %f has a way of specifying a maximal field width. [...] I suggest a third floating-point format (%g maybe, or something else if that is already taken) which would mean either %f or %e depending on the size of the exponent similar, IIRC, to the number output formats available in FORTRAN and/or BASIC. That format would be implicit when :echoing a floating-point number. (Yes, I know, Vim is neither FORTRAN nor BASIC, but I feel this kind of thing would be better than crashing or even than giving an error.) +1. Ben. IIRC, in FORTRAN, the G output format would give (for different values output under a single format) results like: -1.234567E-123 (for a small number) 2.25 (with spaces to the same width) 342.5682 (with spaces for a large number but not too large) 6.02E+023 (for an even bigger number) NAN(a special case) -INF (another special case) (this from what [I think that] I remember from the time I used FORTRAN on computers whose printers had no lowercase letters). --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Updated floating point patch
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
could still mean 123 (or 123.0) concatenated with 456. But with the
restriction
123
is invalid. Not sure whether that's desirable. Probably the lesser of two
evils.
Of course, it needs to be enforced that printf and such functions either
omit the
ampersand for floats which happen to be integers (probably undesirable) or
always
append a '.0' in this case.
Would wrapping floats in braces be a better syntax? I don't think this
would clash
with anything: dictionaries require keys followed by colons which don't
occur in
floats, and a float is also an invalid variable or function name due to
starting
with a digit or sign (+/-) so couldn't be used as part of curly-brace
variable or
function names. E.g.
:let myfloat={12.52}
:let mybig={1234e56}
:let myintegerfloat={123}
To me, this is nicer than a leading , and avoids the nasty restriction of
needing
a decimal point all the time/ambiguity of decimal point vs. concatenation.
Actually, to clarify, my proposal is that a set of curly braces is taken to
represent a float if and only if it is (1) not preceded by a valid variable
name
character and (2) contains a valid float.
I.e. floats:
{+123.456}
{-123}
{123e-4}
{123.456}something_to_concatenate
non-floats:
{dictionary: 'value'}
variable_name_with_number_{123}
variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
variable_name_with_six_digits_here_{123.456}
{variable_name_from_a_variable}
{10x?'variable_1':'variable_2'}
combination!:
variable_name_with_float_expression_giving_{{0.55}some_float?'true':'false'}
variable_name_with_float_that_prints_as_integer_{{123}}
invalid:
variable_name_with_punctuation_due_to_float_{{123.456}}
I think it works unambiguously and sensibly, though, of course, you can
still do
dumb things if you try hard enough! But I don't think it breaks anything
that
currently works (even if what currently works is dumb)!
let x12=3
echo x{1.2}
Works quite nicely -- and is ambiguous with respect to floating point
overloading.
No, it isn't ambiguous. By (1) of my definition, this is not to be interpreted
as
a float. Furthermore, a variable with name 'x1.2' is invalid. A more confusing
example would be
let e=3
let x132=4
echo x{1e2}
but it still isn't ambiguous by my definition.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: omnicpp very slow under windows XP
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: http://groups.google.com/group/vim_use/browse_thread/thread/aa9d0c6c1429d738 I've had a look at the source code and have some pretty solid ideas about what's causing this and some ways to fix it, but don't have anything really quantitative to back up my suspicions, don't have a Windows build environment, only somewhat inconvenient access to Windows machines, and have another Vim patch or two to work on before this. But hey, I guess it's a start...so it may be fixed soon! Some time in June I should have time if not before. If anyone has or can find a HOWTO on building Vim on Win32 using free software tools (MinGW etc.), that might speed the process. 2- Omnicpp does not work when the name of an object is only one character. ex MyClass E; E- does not complete. 2 bugs in omnicpp Thanks Best Regards Epanda --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: omnicpp very slow under windows XP
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/antoine.mechelynck/vim/compile.htm Thanks, Tony. I'm sure that will help. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: (patches) fixed 2 bugs in multi-byte
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 will leave that to Bram/others to comment.
Ben.
Dominique Pelle wrote:
Bug#1:
Valgrind memory checker detects a bug when using utf-8 locale
and when loading a file which contains only 1 byte (0xfc).
Bug is easy to reproduce:
1/ make sure locale is utf-8
2/ create a file with only 1 byte 0xfc:
$ perl -e 'print chr(0xfc)' foo.txt
Note that this is clearly not a valid utf-8 file.
3/ open the file with vim and valgrind:
$ valgrind vim -u NONE foo.txt 2 vg.log
4/ notice that valgrind complains immediately as file is being read:
==15575== Conditional jump or move depends on uninitialised value(s)
==15575==at 0x811F6FD: utf_head_off (mbyte.c:2494)
==15575==by 0x80C32B0: readfile (fileio.c:1880)
==15575==by 0x80527AE: open_buffer (buffer.c:130)
==15575==by 0x80E7F82: create_windows (main.c:2459)
==15575==by 0x80E5C84: main (main.c:799)
5/ notice as well that vim has set file encoding to utf-8 even
though it is not a valid utf-8 file.
I would expect fenc to be set automatically to latin1,
and not utf-8.
':set fenc?' shows: fileencoding=utf-8
':set fileencodings? shows: fileencodings=ucs-bom,utf-8,latin1
Looking at the code, I see that function utf_head_off(base, p)
reads 1 to n bytes ahead p at line 2494:
2474 int
2475 utf_head_off(base, p)
2476 char_u *base;
2477 char_u *p;
2478 {
2479 char_u *q;
2480 char_u *s;
2481 int c;
2482 #ifdef FEAT_ARABIC
2483 char_u *j;
2484 #endif
2485
2486 if (*p 0x80) /* be quick for ASCII */
2487 return 0;
2488
2489 /* Skip backwards over trailing bytes: 10xx.
2490 * Skip backwards again if on a composing char. */
2491 for (q = p; ; --q)
2492 {
2493 /* Move s to the last byte of this char. */
!!! 2494 for (s = q; (s[1] 0xc0) == 0x80; ++s)
2495 ;
2496 /* Move q to the first byte of this char. */
2497 while (q base (*q 0xc0) == 0x80)
2498 --q;
Line 2494 is accessing s[1] (i.e. 'p[1]'). But only
p[0] is initialized since readfile() only read one byte
from file, so p[1] and beyond are uninitialized.
Loop at line 2494 can in theory access many other bytes
beyond the end of the buffer since exit condition
of loop depends on uninitialized memory.
I think adding a NUL after what is read from file fixes
this bug. See attached patch but please review it.
However, it does not fix the fact that fenc is set to
utf-8 even though it is an invalid utf-8 file.
Bug #2:
Using the same input file, I can see another bug:
1/ yank the first line: Y
This copies the invalid utf-8 into the unnamed register
2/ copy the unnamed register onto the Ex line:CTRL-R
3/ observe the following error when copying register:
==6484==at 0x80BAEBD: cmdline_paste_str (ex_getln.c:3028)
==6484==by 0x8132B12: cmdline_paste_reg (ops.c:1528)
==6484==by 0x80BADD2: cmdline_paste (ex_getln.c:3009)
==6484==by 0x80B8029: getcmdline (ex_getln.c:1131)
==6484==by 0x80B96C7: getexline (ex_getln.c:2100)
==6484==by 0x80A31FA: do_cmdline (ex_docmd.c:995)
==6484==by 0x8129F9A: nv_colon (normal.c:5179)
==6484==by 0x8123556: normal_cmd (normal.c:1152)
==6484==by 0x80E631D: main_loop (main.c:1181)
==6484==by 0x80E5E6D: main (main.c:940)
==6484== Address 0x51519C2 is 0 bytes after a block of size 2 alloc'd
==6484==at 0x4022765: malloc (vg_replace_malloc.c:149)
==6484==by 0x8113B6C: lalloc (misc2.c:862)
==6484==by 0x8113A8E: alloc (misc2.c:761)
==6484==by 0x8113EFB: vim_strsave (misc2.c:1166)
==6484==by 0x81355CD: op_yank (ops.c:2901)
==6484==by 0x8124AC6: do_pending_operator (normal.c:1890)
==6484==by 0x81235D1: normal_cmd (normal.c:1178)
==6484==by 0x80E631D: main_loop (main.c:1181)
==6484==by 0x80E5E6D: main (main.c:940)
3018 void
3019 cmdline_paste_str(s, literally)
3020 char_u *s;
3021 int literally;
3022 {
3023 int c, cv;
3024
3025 if (literally)
3026 put_on_cmdline(s, -1, TRUE);
3027 else
!!! 3028 while (*s != NUL)
3029 {
3030 cv = *s;
3031 if (cv == Ctrl_V s[1])
3032 ++s;
3033 #ifdef FEAT_MBYTE
3034 if (has_mbyte)
3035 {
!!! 3036 c = mb_ptr2char(s);
!!! 3037
Re: UTF-8 bomb showing up after :%!sort
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 able to temporarily remove the BOM, then execute the shell command, and finally place the BOM back at its original place, at the beginning of the file. I can't follow the logic of that. If a BOM is requested, then it will be inserted if the file is saved. Sending it to an external program requires that the file be saved, and the whole point of the BOM is to tell the external program what encoding to use. It's not quite that simple. I can't do any testing at the moment, but what happens when a part of the file not including the first line of the buffer is filtered through an external command? Should the BOM be added to the start of the filtered text and removed afterwards? I suppose it all depends on whether the BOM is considered to be part of the buffer or part of the file. I think the BOM should be considered part of the encoding and thus output regardless of which lines of the file are sent to the filter. (Likewise, I think endofline is much the same and if not set, the last EOL should be omitted whichever lines are sent to a filter, too, but that's another story, and Bram disagrees with me on that one, I think.) Vim has the flexibility of saving files and sending them to filters in any encoding you choose, with or without a BOM, by setting fileencoding and bomb options, and I think this behaviour should be kept. If you want to pipe your data through a filter that doesn't understand BOM, set nobomb. If you don't want a BOM ending up in your text when it is read back in after filtering (i.e. when a filter outputs a valid BOM at the beginning of its output), set fileencodings (note the S) appropriately. Likewise, if you have a filter that only deals with Latin1 or cp1252 or whatever and not Unicode, set the options appropriately when using that filter (yes, this is a muckaround, but Vim doesn't know what every external filter needs so can't do this automatically). Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: authoritative source repository
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 changes propagate down to the cvs and svn repos? Bram is the man at the top and publishes patches. I don't think he believes in doing version control with a system like CVS or SVN but prefers making good, solid patches and doing code read-throughs and so on. I could be completely wrong on that, though, and can't really speak for him. Smiles, Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vimscript compiled
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:
A: Hi all, I'm playing with datetime functions. Can someone help me, please?
I
need a function which converts Mar to 3.
B: try strlen()
I like it.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: clientserver --remote-send and map
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. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: RFE: Prevent maps from being overwritten with :map final
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 install the plugin. Pretty much no matter how much effort is put in, people will still be able to write bad code, bad interfaces, etc., etc., and it's the user's choice whether they make use of it. I think a final modifier to a map would just become a bit awkward figuring out what its scope should be, etc.: should it apply to all mappings, buffer-local and global? It could also just start making more problems, too...e.g. what if a plugin author (ab)used it? You'd end up with an almost indestructible plugin rather than allowing the user to have another say later as they can now, etc.. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch for mode() function
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. It extends the mode() function to
return a more full set of modes.
The one bearing most comment is the one for when a shell is running
(:shell in the GUI). I'm not entirely convinced having this as a
separate 'mode' is really the best thing. Hoewver, the alternative
would be somehow delaying a server's processing and reply to
--remote-expr et al. and I suspect this is pretty non-trivial. Having
mode() return something different is a good step even if it isn't the
final one, I think.
Would you be able to include this?
Problem with this change is that it's not backwards compatible. E.g.,
currently Vim would return n in operator-pending mode, after the
change it would return o.
How about giving mode() an argument? When present and non-zero it would
switch to return more information. I would then return both the major
mode and the detail. E.g., for Vim Ex mode it would be cv, normal Ex
mode ce and for command-line mode c. Then for those places where it
doesn't matter what kind of command-line mode is being used you would
only check the first letter. Also makes it easier for future changes,
so long as it fits in the current major modes.
Yep, sounds good. Here's a revised patch.
I made the '-- more --' prompt a separate minor mode, as that seemed
sensible--can't really see any use for the distinction, but better to have it
than
try to add it later once we figure out what it's for and then have more
compatibility issues (no pun intended!).
I kept '!' as a major mode as really none of the other modes apply--even though
the function used to return 'n', it's not necessarily true that you will be in
normal mode after an external command finishes. So I'd view that change as a
bugfix not a breaking of compatibility. If you think that's a bad call, it
could
be changed to 'n!' I suppose.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
index fc6aa5d..3d9402b 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -1750,7 +1750,7 @@ max({list}) Number maximum value of items in {list}
min({list}) Number minimum value of items in {list}
mkdir({name} [, {path} [, {prot}]])
Number create directory {name}
-mode()String current editing mode
+mode( [expr]) String current editing mode
nextnonblank( {lnum}) Number line nr of non-blank line = {lnum}
nr2char( {expr}) String single char with ASCII value {expr}
pathshorten( {expr}) String shorten directory names in a path
@@ -3846,8 +3846,12 @@ mkdir({name} [, {path} [, {prot}]])
:if exists(*mkdir)
*mode()*
-mode() Return a string that indicates the current mode:
+mode([expr]) Return a string that indicates the current mode.
+ If an expression is supplied that results in a non-zero number
+ or a non-empty string, then the full mode is returned,
+ otherwise only the first letter is returned.
n Normal
+ no Operator-pending
v Visual by character
V Visual by line
CTRL-V Visual blockwise
@@ -3857,9 +3861,15 @@ mode() Return a string that indicates the current mode:
i Insert
R Replace
c Command-line
+ cv Vim Ex mode |gQ|
+ ce Normal Ex mode |Q|
r Hit-enter prompt
- This is useful in the 'statusline' option. In most other
- places it always returns c or n.
+ rm The -- more -- prompt
+ r? A |:confirm| query of some sort
+ ! Shell or external command is executing
+ This is useful in the 'statusline' option or when used
+ with |remote_expr()| In most other places it always returns
+ c or n.
nextnonblank({lnum}) *nextnonblank()*
Return the line number of the first line at or below {lnum}
diff --git a/src/eval.c b/src/eval.c
index 4ec28fd..508935d 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -7197,7 +7197,7 @@ static struct fst
#ifdef vim_mkdir
{mkdir, 1, 3, f_mkdir},
#endif
-{mode, 0, 0, f_mode},
+{mode, 0, 1, f_mode},
{nextnonblank, 1, 1, f_nextnonblank},
{nr2char, 1, 1, f_nr2char},
{pathshorten, 1, 1, f_pathshorten},
@@ -12865,7 +12865,9 @@ f_mode(argvars, rettv)
typval_T *argvars;
typval_T *rettv;
{
-char_u buf[2];
+char_u buf[3];
+
+buf[1] = NUL;
#ifdef FEAT_VISUAL
if (VIsual_active)
@@ -12877,8 +12879,17 @@ f_mode(argvars, rettv)
}
else
#endif
- if (State == HITRETURN || State == ASKMORE || State == SETWSIZE)
+ if (State == HITRETURN || State == ASKMORE || State == SETWSIZE ||
+ State == CONFIRM)
+{
buf[0] = 'r';
+ if (State == ASKMORE
Floating point syntax
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 perhaps may see them if part of a new thread!
The first proposal was mine:
- I pointed out that there is actually possibly ambiguity in the current
syntax unless a float is required to have a decimal point or exponent,
as 123.456 could mean float 123.456 or float 123 (123.0) concatenated
with integer 456. If the requirement is added, the ambiguity is
removed, but 123 is invalid, which is a bit of a shame.
- I proposed an alternative syntax that I prefer and I think is likely
to be more robust in the long run: enclosing floats in curly braces.
E.g. {123.456}. Specifically, a set of curly braces would be taken to
represent a float if and only if it is (1) not preceded by a valid
variable name character and (2) contains a valid float. Nobody came up
with any reason this would not work.
The second was a proposal to represent floats as numbers with decimal
points but no additional punctuation which was implicit in this report
from Ilya Bobir:
- I did a search for vim scripts that use concatenation operation
between two numbers without interleaving space. It appears that
Google Code Search was able to find only 39 matches and all were
false positives.
Nobody gave any reply to the message.
I would like to note, though, that this doesn't solve the problem for
exponent notation. However, I suspect a search of vim scripts containing
numbers of that form would yield even less results, though I have not
tried it. The search also doesn't take into account expressions that may
be built dynamically in vim scripts rather than being hard coded, but
again, I doubt many if any of these exist.
I personally would prefer either of these syntaxes to the notation with
the ampersand.
Do people have further comments/thoughts on this? Is Bram still
interested in hearing them?
The earlier thread which contains more details can be read here:
http://groups.google.com/group/vim_dev/browse_thread/thread/1c8806e536ec12cd
The relevant posts are at the end. The last 7 or so, which happen to
nicely form the second page of posts at present.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
