taglist: ctrl ] azerty
Hello there, I am trying to use taglist on my AZERTY keyboard and I cannot get ctrl ] to work. If I type :ts + tagname I can see that taglist is working. thanks, -- Mathieu
Re: taglist: ctrl ] azerty
Hi, Mathieu Malaterre wrote: I am trying to use taglist on my AZERTY keyboard and I cannot get ctrl ] to work. If I type :ts + tagname I can see that taglist is working. this depends heavily on the operating system you use and the installed keyboard driver. For me on Windows XP with a German keyboard pressing Ctrl++ works. It seems that ctrl-combinations that do not involve alphabetic keys but only symbols have not moved from their original position on an english/american keyboard, e.g., Ctrl+ü is equivalent to Ctrl+[ and Ctrl+6 is the same as Ctrl+^. You might try to press Ctrl and the rightmost key in the AZERTY row. Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)
Re: taglist: ctrl ] azerty
Thanks ! On 5/24/07, Jürgen Krämer [EMAIL PROTECTED] wrote: Hi, Mathieu Malaterre wrote: I am trying to use taglist on my AZERTY keyboard and I cannot get ctrl ] to work. If I type :ts + tagname I can see that taglist is working. this depends heavily on the operating system you use and the installed keyboard driver. For me on Windows XP with a German keyboard pressing Ctrl++ works. It seems that ctrl-combinations that do not involve alphabetic keys but only symbols have not moved from their original position on an english/american keyboard, e.g., Ctrl+ü is equivalent to Ctrl+[ and Ctrl+6 is the same as Ctrl+^. You might try to press Ctrl and the rightmost key in the AZERTY row. Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin) -- Mathieu
Re: A performance question
Charles E Campbell Jr wrote:
Sounds like the filesize is getting stored in a 32bit signed
number, and overflowing.
Yes, definitely.
Please let me know what getfsize() is actually returning
The return value is the bit pattern for the low 32 bits of the
true 64-bit file size:
3,146,839,490 file actual size
-1,148,127,806 returned by getfsize()
The sum of the absolute values is exactly 4G. I confirmed the
above with a file exactly 8G + 512 bytes (getfsize() said it was
512 bytes).
I was going to suggest that you treat a negative getfsize()
value as a large file (may as well do that even if the value is
-1 for an error indication).
I suppose that would be useful until some better solution is
implemented. I didn't propose it because it would be quite ugly
for the script to give results like this:
3GB file is large
5GB file is not large
7GB file is large
9GB file is not large
Another ugly (but accurate) workaround would be:
- Provide the source for a small executable called islargefile
to do the calculation.
- Provide an option in the script to use the executable.
- Have the script execute system('islargefile xxx 123456').
Return value 0 means no, 1 means yes, 2 means error
(return is first character of system() string).
Need to work out how to pass arguments:
xxx = path of file to be tested
123456 = limit at which file is large
John
Re: A performance question
Yongwei Wu wrote: Even FAT32 supports files much larger than 4GB. Not true. FAT32 supports files up to 4 GB. Sorry I shot my mouth off there - I realised my blunder about ten minutes after sending. I haven't actually used a FAT32 partition for over ten years, and was confusing the maximum size of a FAT32 partition with its maximum file size. On NTFS of course, as you mentioned, the sky is the limit. I have made files larger than 4GB, and have written a couple of simple programs to work with such files, so my basic point is valid. The Win32 API supports files much larger than 4GB. John
Re: A performance question
panshizhu wrote:
Yes, but on all systems, vim script could not take 64-bit
integers
I know that. My proposal is for a new Vim script function:
islargefile({fname}, {limit})
which would return nonzero if the size of the file is greater
than the 32-bit signed {limit} argument.
Vim could easily handle the 64-bit arithmetic that is available
on several systems, so the proposed islargefile() would
accurately indicate whether the file size was greater than the
specified limit. The limit would be up to 2G - I don't think
there's any need to get cute and allow the caller to pass a
negative value which would then be treated as unsigned.
John
Re: taglist: ctrl ] azerty
Mathieu Malaterre wrote: Hello there, I am trying to use taglist on my AZERTY keyboard and I cannot get ctrl ] to work. If I type :ts + tagname I can see that taglist is working. thanks, I also have an AZERTY keyboard, and neither do I know whether (and where) it has Ctrl-] but that doesn't bug me because of the following mapping: :mapF9 C-] Best regards, Tony. -- If you're right 90% of the time, why quibble about the remaining 3%?
Re: A performance question
John Beckett wrote:
Charles E Campbell Jr wrote:
Sounds like the filesize is getting stored in a 32bit signed
number, and overflowing.
Yes, definitely.
Please let me know what getfsize() is actually returning
The return value is the bit pattern for the low 32 bits of the
true 64-bit file size:
3,146,839,490 file actual size
-1,148,127,806 returned by getfsize()
The sum of the absolute values is exactly 4G. I confirmed the
above with a file exactly 8G + 512 bytes (getfsize() said it was
512 bytes).
I was going to suggest that you treat a negative getfsize()
value as a large file (may as well do that even if the value is
-1 for an error indication).
I suppose that would be useful until some better solution is
implemented. I didn't propose it because it would be quite ugly
for the script to give results like this:
3GB file is large
5GB file is not large
7GB file is large
9GB file is not large
Another ugly (but accurate) workaround would be:
- Provide the source for a small executable called islargefile
to do the calculation.
- Provide an option in the script to use the executable.
- Have the script execute system('islargefile xxx 123456').
Return value 0 means no, 1 means yes, 2 means error
(return is first character of system() string).
Need to work out how to pass arguments:
xxx = path of file to be tested
123456 = limit at which file is large
John
What about a different function to return, say, the number of 1K blocks (or
the number of times 2^n bytes, with a parameter passed to the function) that a
file uses?
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
252. You vote for foreign officials.
Re: A performance question
John Beckett wrote: Yongwei Wu wrote: Even FAT32 supports files much larger than 4GB. Not true. FAT32 supports files up to 4 GB. Sorry I shot my mouth off there - I realised my blunder about ten minutes after sending. I haven't actually used a FAT32 partition for over ten years, and was confusing the maximum size of a FAT32 partition with its maximum file size. On NTFS of course, as you mentioned, the sky is the limit. I have made files larger than 4GB, and have written a couple of simple programs to work with such files, so my basic point is valid. The Win32 API supports files much larger than 4GB. John ...not to mention Unix/Linux, with its variety of not only FAT12, FAT16, FAT32 and NTFS but also ext2, ext3, reiserfs, etc., supported. I see a backups.tgz file of 7GB (which normally isn't mounted) so big files exist here too. Best regards, Tony. -- While I, with my usual enthusiasm, Was exploring in Ermintrude's busiasm, She explained, They are flat, But think nothing of that -- You will find that my sweet sister Susiasm.
Feature request: swig syntax
Hello, I cannot find a swig.vim in my debian installation so I suspect this is not part of the main vim project. Could someone please add the syntax/indent file. Tarball is not attached, but can be found here: http://jwx.sourceforge.net/INTERNALS.html (see swig-vim). HTH -- Mathieu
RE: Remapping mouse-wheel
So, nobody has any comments on this? I get the same behavior when I start gvim with -u NONE -U NONE. -Original Message- From: Waters, Bill Sent: Thursday, May 17, 2007 1:01 PM To: vim Subject: Remapping mouse-wheel Is there a way to map mouse-wheel to CTRL-mouse-wheel? I tried this... map MouseUp C-MouseUp map MouseDown C-MouseDown And this... nnoremap MouseUp C-MouseUp nnoremap MouseDown C-MouseDown But it doesn't work the same as when I manually hold down Ctrl while using the mouse wheel. When I have a split window (horizontal or vertical), the mouse wheel only works in one of the two splits. It works in either (as it should) when I do a CTRL-mouse-wheel. I am looking for a work-around to this problem. Thanks, Bill
Re: Remapping mouse-wheel
Waters, Bill wrote: When I have a split window (horizontal or vertical), the mouse wheel only works in one of the two splits. It works in either (as it should) when I do a CTRL-mouse-wheel. I don't think I understand your problem. Ctrl-mouse wheel has no particular effect on my system (Vim 7.1 Gtk on Debian) and it's not supposed to, according to the manual. On my Vim the mouse wheel only scrolls in the active window, both with and without Ctrl, I am looking for a work-around to this problem. If I understand you correctly, you want the mouse wheel to always scroll in all windows simultaneously? Then put this in your .vimrc: set scrollbind HTH Tobia
RE: Remapping mouse-wheel
If I understand you correctly, you want the mouse wheel to always scroll in all windows simultaneously? No. I want it to behave as yours does, mouse wheel only scrolls in the active window. This seems to be a problem specific to Microsoft Windows. (I am running XP.) I should have mentioned that before. --Bill -Original Message- From: Tobia [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 2:45 PM To: vim Subject: Re: Remapping mouse-wheel Waters, Bill wrote: When I have a split window (horizontal or vertical), the mouse wheel only works in one of the two splits. It works in either (as it should) when I do a CTRL-mouse-wheel. I don't think I understand your problem. Ctrl-mouse wheel has no particular effect on my system (Vim 7.1 Gtk on Debian) and it's not supposed to, according to the manual. On my Vim the mouse wheel only scrolls in the active window, both with and without Ctrl, I am looking for a work-around to this problem. If I understand you correctly, you want the mouse wheel to always scroll in all windows simultaneously? Then put this in your .vimrc: set scrollbind HTH Tobia
Re: A performance question
A.J.Mechelynck wrote: What about a different function to return, say, the number of 1K blocks (or the number of times 2^n bytes, with a parameter passed to the function) that a file uses? Yes, that's a much more general and better idea. Since there's probably not much need for this, I think that simplicity would be good. That is, have the function work in a fixed way with no options. Re Dr.Chip's LargeFile script: It occurs to me that another workaround would be to use system() to capture the output of 'ls -l file' or 'dir file' (need an option for which). Then do some funky editing to calculate the number of digits in the file length. If more than 9, treat file as large. I'm playing with a tiny utility to help the LargeFile script. Bluesky: Its code (64-bit file size) could potentially be incorporated in Vim. I'll post results in vim-dev. John
ctrl-] jump to files that already opened in another tabpage
Hi list, I have a question (or request?). I'm using tab pages opening all the files in my project. I also have a tags file for C program symbols. If I use ctrl-] to jump to a symbol definition that is in another file, which was already opened in another tabpage, it now would not jump to that tab page, but opened the file in current tabpage. If I edited this file in current tabpage, another tabpage would automatically be synced. I wish that if I use ctrl-] to jump to a file that is already in another tabpage, it can automatically jump to that tabpage, but not open new file in the current tabpage. And if I use ctrl-T it can automatically jump back to the calling tabpage. I tried to modify it myself, but I could not find the settings about tags browsing in the /usr/share/vim folder. Only some documentations. Could anyone please give me some hints? Thanks. Regards, Franklin signature.asc Description: This is a digitally signed message part.
Re: Opening files matching tags in another window
:help CTRL-W_] :help CTRL-W_g_CTRL-] Exactly what I was looking for! Thanks, Krishna Vissale: I am using vim in the console mode. I don't use the mouse much while interacting with vim! But thanks for the suggestion! For a list of similar functions, see :help window-tag HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: ctrl-] jump to files that already opened in another tabpage
Hi, On 5/24/07, Franklin [EMAIL PROTECTED] wrote: Hi list, I have a question (or request?). I'm using tab pages opening all the files in my project. I also have a tags file for C program symbols. If I use ctrl-] to jump to a symbol definition that is in another file, which was already opened in another tabpage, it now would not jump to that tab page, but opened the file in current tabpage. If I edited this file in current tabpage, another tabpage would automatically be synced. I wish that if I use ctrl-] to jump to a file that is already in another tabpage, it can automatically jump to that tabpage, but not open new file in the current tabpage. And if I use ctrl-T it can automatically jump back to the calling tabpage. I tried to modify it myself, but I could not find the settings about tags browsing in the /usr/share/vim folder. Only some documentations. Could anyone please give me some hints? This is currently not supported by Vim. You need to use a Vim plugin and use the commands provided by that plugin to do this. This plugin has to provide the tag stack support also. - Yegappan
