Re: Vim 7.0 x64
Andre Godoi wrote: Dear George! Thank you very much for the 64-bits binaries of Vim. I have just installed Windows XP x64 and your version of Vim. The only thing I couldn't do is install the Edit with Vim... entry on the right-click pop-up. I did what you described, I've set a %VIM% variable to where my Vim was uncompressed and ran install.exe. The option 14 says it will install the right-click context menu, but it doesn't. Is there anything I could do to solve it? That right-click context menu was very useful. =) Thank you very much for your attention and for your help. Andre Godoi I'm sorry, but I don't have access to a Win64 system at the moment, so there's no easy way for me to check out what you're saying. I don't know if it's a problem with the installer or with gvimext.dll. You may be able to get what you want by creating a vim.reg file with contents like this: REGEDIT4 [HKEY_CLASSES_ROOT\*\Shell\Open with Vim\command] @=\c:\\Program Files\\Vim\\vim70\\gvim.exe\ \%1\ I think a similar issue came up on the Vim Developers list recently, so I'm CCing that. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog
Re: Irritating column numbers with encoding=utf-8
On Wed, Jul 05, 2006 at 11:50:51AM +0200, Jürgen Krämer wrote: Hi, with 'encoding' set to utf-8 there is a quite confusing (to me) difference between the column number and my expectations (supported by the virtual column number) if there are non-ASCII characters on the line. Column number n is really the nth byte on that line. This is described at :help /\%c. This description should explain all the behavior you're seeing. This is the intended behavior and I'm not sure of a way off-hand to get the visual character count like you want. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Irritating column numbers with encoding=utf-8
Hi, James Vega wrote: On Wed, Jul 05, 2006 at 11:50:51AM +0200, Jürgen Krämer wrote: with 'encoding' set to utf-8 there is a quite confusing (to me) difference between the column number and my expectations (supported by the virtual column number) if there are non-ASCII characters on the line. Column number n is really the nth byte on that line. This is described at :help /\%c. This description should explain all the behavior you're seeing. This is the intended behavior and I'm not sure of a way off-hand to get the visual character count like you want. yes, it does *explain* the behaviour. But it makes things even worse. Suppose I have some lines with aligned data (just like a table) where I want to replace certain columns with dashes, e.g., PeterTraurig irgendwo 0 Hänschen Klein unterwegs 1 Jürgen Krämer hier 2 :%s/\%18c.*\%27c/-/ should strike out the third column of the table, but the result is PeterTraurig - 0 Hänschen Klein -s 1 Jürgen Krämer- 2 which is depending on the random number of non-ASCII characters in front of the used position, characters whose internal representations should never be relevant for this substitution, because the user cannot know them. Since it works as documented it is hard to call it a bug, but I would really consider it a mis-feature, because it works in such a non-predictable way. To work around the problem in this example is not that hard -- I can use /\%...v instead. The example in my original mail poses a bigger problem (to me) -- I'd like to switch to encoding=utf-8 as default, but I often need to work with text files of fixed line length. With encoding set to latin1 the difference between column number and virtual column number in the status line is a visual clue that there is a tabular or a control code in the line, reminding me to look for this character. With UTF-8 encoding this hint would be rendered useless because of all those little umlauts in German. :-( But perhaps this is just my special problem. Regards, Jürgen -- Jürgen Krämer Softwareentwicklung HABEL GmbH Co. KGmailto:[EMAIL PROTECTED] Hinteres Öschle 2 Tel: +49 / 74 61 / 93 53 - 15 78604 Rietheim-WeilheimFax: +49 / 74 61 / 93 53 - 99
Re: Irritating column numbers with encoding=utf-8
On 7/5/06, Jürgen Krämer [EMAIL PROTECTED] wrote: To work around the problem in this example is not that hard -- I can use /\%...v instead. Yes The example in my original mail poses a bigger problem (to me) -- I'd like to switch to encoding=utf-8 as default, but I often need to work with text files of fixed line length. With encoding set to latin1 the difference between column number and virtual column number in the status line is a visual clue that there is a tabular or a control code in the line, reminding me to look for this character. With UTF-8 encoding this hint would be rendered useless because of all those little umlauts in German. :-( There's yet another reason for col()!=virtcol(). It's unprintable characters like ^A ^@ ^[ Granted, they occur rarely in textfiles, but if they do, they'll cause virtcol() != col(). If you stick with virtcol() and \%v, you'll probably not feel any inconvenience. I mean, there are two types of columns (virtual and non-virtual), and if someone confuses the two, and uses %\c instead of %\v or col() instead of virtcol(), or vice versa, it's inconvenient. Once the confusion is fixed, and you use the right type of column index, doesn't it solve the inconvenience ? (except that there are still two types of columns, which requires increased attention as to which one to use in each case) ? Yakov
Re: Irritating column numbers with encoding=utf-8
On 7/5/06, Jürgen Krämer [EMAIL PROTECTED] wrote:
with 'encoding' set to utf-8 there is a quite confusing (to me)
difference between the column number and my expectations (supported by
the virtual column number) if there are non-ASCII characters on the
line.
And additional remark. As James noted, \%c
is not character offset (in case of multibyte chars),
but the bytes offset.
In case you want to match
not by visual columns (\%v) and not by byte
offset, but by character index in the line, you
can do this:
/^.\{22}xyz
This matches xyz at 23nd char position,
correctly counting each multibyte chars and
each single char for 1 position. Does this
possibly solve your matching problem ?
Yakov
Re: args list window
On Wed, 5 Jul 2006 at 9:01am, Yakov Lerner wrote: Let's say I start vim with multiple files on the command line. Is there any plugin, similar to directory browser, that show vim arguments (vim arguments file) in the file-list window ? So I can go up-down on vim arguments and press Enter to open them. Thanks Yakov I was just about to upload a new version of my lookupfile plugin when I saw your question, so I added an LUArgs command just for you. By default you have to type in at least 4 characters for the lookup to start (for performance reasons), but since you are not going to have too many arguments, you can change the g:LookupFile_MinPatLength to 0 (or type to match all names that are at least four chars long). Please let me know if you have any feedback. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Irritating column numbers with encoding=utf-8
Jürgen Krämer wrote: with 'encoding' set to utf-8 there is a quite confusing (to me) difference between the column number and my expectations (supported by the virtual column number) if there are non-ASCII characters on the line. I don't know what the intended meaning of column count and the intended behaviour of cursor() are, but it seems they both depend on the size of the encoded characters. I always thought nth column was more or less a synonym for nth character on a line while nth virtual column meant nth cell on a screen line. Here is how to reproduce the observed behaviour. Start vim -u NONE -U NONE and :set encoding=utf-8 :set laststatus=2 :set statusline=[%c/%v] (The last line tells VIM to display the column and the virtual column.) Now enter two lines abc äbc (The first letter in the second line is a lower case A with umlaut.) While moving the cursor over the different characters on the first line the status line shows [1/1], [2/2], and [3/3], respectively, telling you that column and virtual column are equal. That is the expected behaviour as long as there are no special characters like tabs and non-printable characters. Now move the cursor over the characters in the second line. While the cursor is over the ä [1/1] is displayed, but the next characters result in [3/2] and [4/3], respectively. It seems as if ä (or any non-ASCII character, for that matter) is accounting for (at least) two columns while encoding is set to utf-8. Although I know that ä is represented by two bytes in UTF-8 encoding, I find this behaviour irritating because on the surface it's only one character. It even gets worse (IMHO) with characters that need three bytes in UTF-8 encoding, like LATIN CAPITAL LETTER A WITH DOT BELOW (0x1EA0), which increase the column number by three. Also the cursor() function shows this kind of interpretation of non-ASCII characters. Both call cursor(2, 1) and call cursor(2, 2) place the cursor on ä. To place it on b you need to call cursor(2, 3) although I would expect that already the second example would place the cursor on b. I can think of two ways to circumvent this problem: 1) switching to encoding=latin1, which is not always an option because of the need for characters outside the scope of latin1; 2) using only virtual column numbers in the status line, but this gives different results when characters like tab or non-printables are displayed in more than one screen cell (which is of course reasonable). I don't know whether the shown behaviour is a bug or just a feature I don't like, but in summary I think column number should really represent a character count (i.e, corresponding to what the user sees), not a byte count depending on the underlying encoding. I have seen this behaviour in VIM 6.2, 6.3, 6.4, and 7.0, so changing the code will definitely introduce an incompatibility. So the final question is: What do you (Vimmers) and you (Bram) think: is there a need for a change. I don't know why you call this a column count, in most places it's called a byte count. Perhaps in some places in the docs the remark about this actually being a byte count is missing. You could also want a character count. But what is a character when using composing characters? E.g., when the umlaut is not included in a character but added as a separate composing character? It's not so obvious what to do. In these situations I rather keep it as it is. -- DENNIS: Look, strange women lying on their backs in ponds handing out swords ... that's no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
R: Launch a browser from url in text
-Messaggio originale-
Da: Bittner, Stefan [mailto:[EMAIL PROTECTED]
Inviato: lunedì 3 luglio 2006 19.19
A: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Oggetto: WG: Launch a browser from url in text
Hi Cesar,
if you consider to use the Utl-plugin mentioned by Tom below, please don't
hesitate to contact me if you have any questions. I think Utl.vim can do
what you need.
With the mapping
:nmap 2-LeftMouse Leadergu
you can doubleclick an URL. It would also be possible to use URLs without
embeddings, e.g. execute
http://www.vim.org/scripts/script.php?script_id=293
instead of
URL:http://www.vim.org/scripts/script.php?script_id=293
Regards,
Stefan (Creator of utl.vim plugin)
-Ursprüngliche Nachricht-
Von: Tom Purl [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 2. Juli 2006 04:30
An: Cesar Romani
Cc: Vim
Betreff: Re: Launch a browser from url in text
Check out the utl plugin:
* http://www.vim.org/scripts/script.php?script_id=293
It may not be exactly what you want, but it's very close.
HTH!
Tom Purl
On Sun, Jul 02, 2006 at 04:19:10AM +0200, Cesar Romani wrote:
Is it possible to doubleclick a highlighted URL in a text and thus
launch a
browser, f.e. internet explorer or firefox?
The command gf allows to open a file under a cursor. Isn't there
anything similar for URLS?
Many thanks in advance,
Andalou
I'm using utl.vim to open url under the cursor.
When I press \gu under an url, it opens the url but it appears at the
bottom:
:call Utl_goUrl('edit')
How can it be hidden?
Many thanks in advance,
Cesar
