mysterious unc path issue on windows
Hi, I have a terribly annoying - but minor - issue on one of my windows vista ultimate 64-bit machines, which hits my productivity now and then, and I would really love to have it solved - and I hope this can contribute to the project as well. Long story short - on this machine everything works fine, but accessing files with a UNC-path (\\computer\share\file) in vim/gvim (tried both 32-bit and 64-bit versions, from 7.2 and back to 5.8) bogs vim down - locks up for 2 minutes or so. Everything else works as it should. My simple test case is to try to load a file on the share //localhost/ share/file.txt My troubleshooting has lead me to suspect that there is something in this machine's configuration that causes problems for vim. Any tips on how I can proceed in locating this further? I am getting desperate! (Long story below...) * It applies to not only files on \\localhost * Turned off swap files * Loaded vim without any plugins/vimrc etc * Tried setting vim env var to blank * Played with different settings for %path% variable * Tried to examine what is happening using Procmon - shows that not much is happening when vim locks up. * When vim locks up - cpu is not pegged, nor is memory racing - it is just not responding * Applies to both console vim and gvim * Cygwin vim runs fine, does not have this issue * The system runs fine otherwise * Do not have an idea what caused this, but it was fine before a certain point... * Unfortunately didn't have any restore point... * Other programs like notepad, word, type.exe, firefox don't have this problem. * Tried to play a bit with WinDbg, but I am not literate enough in debugging to get anything useful out of this... * Tried with both shellslash on/off - no difference * The other Vista win64 machine I have should have a very similar set up - yet doesn't have this issue... Both are fresh installs, about a month old, and not upgraded. * vim loads the files file if the share is mount as a drive letter - e.g. z:\file.txt - also on remote computers * A very odd thing: //localhost/c$/file.txt loads fast - //localhost/ share/file.txt boggs down vim (where the share has a name longer than a few characters) * Filename completion when I start typing :e //localhost/share/fiTAB works fast - it is just the loading that takes time --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim Lib [Was: List Questions]
I personally think part of the problem is that vim is a rather fragile environment (because it's a really versatile editor that can adapt to different usage styles). A script that works well for me doesn't necessarily work for you because you use different options etc. and IMHO it is too much to ask from script authors to take into account all possible options. But it doesn't have to be. A simple solution like an environment stack(store the current env onto a stack, make any changes, pop it off to restore the old env) would make it handleable. But no one makes code to make other peoples coding easier because other people have to actively seek it out. They don't even see the problem, much less the solution. So the solution to this problem, if it really exists, seems to me to be rather a social evolutionary one in that script authors should get better feedback on their scripts, and users should provide more/better feedback (instead of simply uninstalling the script and moving on to the next one). In conjunction with a slightly improved assessment system, in time bad plugins would disappear and good plugins would be ranked top. The karma points were a nice system to get an idea of how good a script is. But there is room for improvements. Eg scripts could lose karma points (or votes) over time in order to weed out unmaintained scripts. Also, some people seem to have manipulated the karma points (eg check out the powershell files) -- I guess you wouldn't even have to write your own script if you used curl. So maybe there should be a captcha for people who want to vote on a script. And maybe 1 to 5 stars + number of votes would give people a more concise idea of a script's quality. Nothing you're saying here is wrong, except your only solution to a bugged script is to vote it down. That implies that someone will post a 'corrected' version that will get voted up. And that people will come back long after they downloaded and started using a script to vote it down if they find a hidden bug. Slightly better would be to allow anyone to edit scripts wiki style. But you're still relying on them stopping what they're doing, loading up a web page and changing it. And if they're making a change based on their environment there's a high likely hood that it's wrong and will break it for someone else. And everyone who already has this script doesn't even realize there are broken versions floating around because no one updates it if it works. The centralized repository forces you to upgrade and could(should) have a simple mechanism for reporting bugs(and submitting patches). No one has to go to an outside application. Futhermore by encouraging code resuse we avoid God only knows how many bugs in the first place. If every script needs to impliment their own environment stack function, we may be in trouble when 2 overlap. If there's only one environment stack, then they are working with the same data. Here's the rub though, why can't we do both? If hundreds of people volounteered to get involved with this project it still wouldn't be operational for months. And even when it was, there will still be scripts that don't fit into what should go into a VimL Centralized Repository(VCR). They can still be available under the current system, but things that should be the same everywhere can be moved into the VCR(I'm trademarking that term). The current system is ad-hoc and full of misplaced intelectual capitol. It was a great try and shouldn't be thrown away but it can definatly be improved upon. I think that what Ag suggests is a massive leap in the right direction. Now if you'll excuse me, I have to go write an environment stack function. --Whaledawg --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: :help prints broken-down-alphabets when the text file is encoded with cp949
On 07/02/09 14:47, Dewr wrote: :help blahblah prints broken-down-alphabets when the text file is encoded with cp949 have a look at the file attached. If you want a help file to look right, it should be encoded in Latin1 if possible, otherwise in UTF-8. In the latter case it may have a BOM to ensure correct decoding whenever 'fileencodings' starts with ucs-bom. All the help files distributed with Vim are in one of these two encodings, with the exception of farsi.txt which is in ISIRI-3342 and doesn't look right (the keyboard picture doesn't display Farsi letters). Best regards, Tony. -- And Bezel saideth unto Sham: `Sham,' he saideth, `Thou shalt goest unto the town of Begorrah, and there thou shalt fetcheth unto thine bosom 35 talents, and also shalt thou fetcheth a like number of cubits, provideth that they are nice and fresh.' -- Dave Barry, Getting Religion --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Visual Block + cursorcolumn highlighting
On 07/02/09 16:06, Bram Moolenaar wrote: [...] The 'cursorline' highlighting is always confusing, no matter what kind of Visual selection you are doing. Unles perhaps you have set the color to be hardly noticable. The default setting of term=underline cterm=underline guibg=Grey90 isn't bad, though personally I raise it to #F4F4F4 (96% grey) in GUI mode. Currently it doesn't appear in Visual mode, not even beyond the end-of-line (though in non-visual mode it does extend to the screen border). It might be an improvement to have it be shown on the part of the line which is not included in the Visual highlight (including the part beyond the end-of-line). Best regards, Tony. -- Amnesia used to be my favorite word, but then I forgot it. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: mysterious unc path issue on windows
Hugo Ahlenius said: Long story short - on this machine everything works fine, but accessing files with a UNC-path (\\computer\share\file) in vim/gvim (tried both 32-bit and 64-bit versions, from 7.2 and back to 5.8) bogs vim down - locks up for 2 minutes or so. Everything else works as it should. What OS are you running, exactly? The first thing I would try is Process Explorer from SysInternals (http://www.sysinternals.com). Start it up, and set the filter to only show activity for vim.exe (or gvim.exe). Then start Vim and have it open the UNC file like you said. Process Explorer should show you everything that happens, with timestamps and success/error codes. This might help narrow down the problem. You can save the events to a file for later analysis. Craig --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: mysterious unc path issue on windows
Hugo Ahlenius wrote: My simple test case is to try to load a file on the share //localhost/ share/file.txt I assume you replace 'localhost' with the name of the computer? And the space in the above is just a typo. There is no space in the UNC? * The other Vista win64 machine I have should have a very similar set up - yet doesn't have this issue. That shows the issue is something on your problem system. * Filename completion when I start typing :e //localhost/share/fiTAB works fast - it is just the loading that takes time I was going to mention your network protocols again, but the above rather rules out any protocol issue. Some antivirus software interacting with what Vim is doing? What if you start with 'vim -u NONE'? John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
A few questions(accessing the Vim code in VimL)
I would like to be able to access all the variables at a given time in Vim
without necessarily knowing what they are. Basically everything you would
see if you typed :let and :set. So in increasing order of difficulty
1. Is there a way to redirect the output from :let and :set? It would be
pretty simple to parse that up, but I can't figure it out.
2. Is there a way to call functions in the Vim code from VimL? Browsing
through the source I see list_hashtable_vars seems to have the info I need.
3. Is there a way to access the actual C data structures from VimL? If I
could read the various hashtables myself I could do what I needed.
I suspect there's no way to do any of this, but I thought I'd ask before I
took a more...cumbersome route. Oh, also what is this declaration structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the arguments
but before the body?
--Whaledawg
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Sun, Feb 8, 2009 at 11:40 PM, Garrett Whelan whaled...@gmail.com wrote: I would like to be able to access all the variables at a given time in Vim without necessarily knowing what they are. Basically everything you would see if you typed :let and :set. So in increasing order of difficulty There's no easy way to get all options, afaik. All variables, though, isn't too tough: you can treat the scopes as a dictionary keyed by names of values in that scope. So, for example: for [var, val] in items(g:) echo Global variable \ . var . \ is \ . val \ The type might change, so we unlet it before it's assigned again unlet val endfor Is there a way to redirect the output from :let and :set? It would be pretty simple to parse that up, but I can't figure it out. Yes. :help :redir - but, again, probably not what you want to do. Is there a way to call functions in the Vim code from VimL? Browsing through the source I see list_hashtable_vars seems to have the info I need. Is there a way to access the actual C data structures from VimL? If I could read the various hashtables myself I could do what I needed. No... those would be awfully strange features for a scripting language... I suspect there's no way to do any of this, but I thought I'd ask before I took a more...cumbersome route. Oh, also what is this declaration structure: KR style C. Vim's old. Back when ANSI C was still not so popular. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On 09/02/09 05:40, Garrett Whelan wrote:
I would like to be able to access all the variables at a given time in
Vim without necessarily knowing what they are. Basically everything you
would see if you typed :let and :set. So in increasing order of difficulty
1. Is there a way to redirect the output from :let and :set? It would
be pretty simple to parse that up, but I can't figure it out.
:help :redir
2. Is there a way to call functions in the Vim code from VimL?
Browsing through the source I see list_hashtable_vars seems to
have the info I need.
You cannot access arbitrary functions in the binary code from vimscript.
The only things you can execute from vimscript are vimscript functions,
ex-commands, and keybindings, see
:help function-list
:help ex-cmd-index
:help index.txt
:help :normal
You can view the C _source_ code if you've downloaded it, but of course
this is done by loading the actual source files in the editor, not by
disassembly.
3. Is there a way to access the actual C data structures from VimL?
If I could read the various hashtables myself I could do what I
needed.
AFAIK, there isn't -- nothing equivalent to the PEEK and POKE functions
available in some versions of BASIC.
I suspect there's no way to do any of this, but I thought I'd ask before
I took a more...cumbersome route. Oh, also what is this declaration
structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the
arguments but before the body?
--Whaledawg
It's not variables, it's the arguments: int *first here means that
first, the argument, is a pointer to int. I'm told doing it this way
rather than static void list_func_vars(int *first) makes the source
more portable among various C compilers.
IIUC, the Vim C source obeys the C89 standard, as shown by this line
which I see in the logfile where I saved the stdout/stderr of configure:
checking for gcc option to accept ISO C89... none needed
See an explanation of Vim source coding style at :help coding-style,
and this particular case somewhat below :help style-examples, in the
section starting Functions start with:.
Best regards,
Tony.
--
Pure drivel tends to drive ordinary drivel off of the TV screen.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Sun, Feb 8, 2009 at 9:13 PM, Matt Wozniski m...@drexel.edu wrote: On Sun, Feb 8, 2009 at 11:40 PM, Garrett Whelan whaled...@gmail.com wrote: I would like to be able to access all the variables at a given time in Vim without necessarily knowing what they are. Basically everything you would see if you typed :let and :set. So in increasing order of difficulty There's no easy way to get all options, afaik. All variables, though, isn't too tough: you can treat the scopes as a dictionary keyed by names of values in that scope. So, for example: for [var, val] in items(g:) echo Global variable \ . var . \ is \ . val \ The type might change, so we unlet it before it's assigned again unlet val endfor Is there a way to redirect the output from :let and :set? It would be pretty simple to parse that up, but I can't figure it out. Yes. :help :redir - but, again, probably not what you want to do. Perfect. Either of those should be able to get me what I want(with a little massaging). And I had no idea that each scope was just a dictionary, genius. Is there a way to call functions in the Vim code from VimL? Browsing through the source I see list_hashtable_vars seems to have the info I need. Is there a way to access the actual C data structures from VimL? If I could read the various hashtables myself I could do what I needed. No... those would be awfully strange features for a scripting language... For a pure scripting language I'd agree, but this is a scripting language in an environment. Allowing direct access to core functions/variables allows huge flexibility *without having to recompile the code*. When using UnrealScipt you can even extend classes from the Unreal Engine. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On 2009-02-09, Matt Wozniski m...@drexel.edu wrote: On Sun, Feb 8, 2009 at 11:40 PM, Garrett Whelan whaled...@gmail.com wrote: I would like to be able to access all the variables at a given time in Vim without necessarily knowing what they are. Basically everything you would see if you typed :let and :set. So in increasing order of difficulty There's no easy way to get all options, afaik. :set all Regards, Gary --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A few questions(accessing the Vim code in VimL)
On Sun, 8 Feb 2009 20:40:09 -0800, Garrett Whelan wrote:
... Oh, also what is this declaration structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043 list_hashtable_vars(current_funccal-l_vars.dv_hashtab,
2044 (char_u *)l:, FALSE, first);
2045 }
I've never seen that in C before. Declaring variables after the
arguments but before the body?
That is the original style of function declaration in C, from back in the KR
first edition days.
Spencer
--
Eagles may soar, but weasels don't get sucked into jet engines
7:52am up 56 days 23:12, 1 user, load average: 1.01, 0.97, 0.60
Registered Linux User #232457 | LFS ID 11703
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
