todo? add :help vimfiles

hello,

just a suggestion. i know lots of people use vimfiles
directories to keep their "private" settings... however,
vimfiles is not mentioned in the help (other then under
runtimepath, i think)...

it seems adding a help item would be beneficial.
Unfortunately, I dont know enough about all aspects of
vimfiles (and maybe there are other directories like this
that I am not aware of?) to write something up, but it
sounds like its really short and simple for someone who
knows about it....

denis

--

-- 
// mailto: Denis Perelyubskiy <denisp <at> CS.UCLA.EDU>
// icq   : 12359698
// PGP   : http://www.cs.ucla.edu/~denisp/files/pgp.asc

Win32 Short filenames - comments?

A call to win32 vimmers!

I _have created_ a patch that adds a modifier which is currently :X
(from dir /x) that modifies 
the filename to be the windows short file name.

ie : expand('%:X') 

Would return the full short filename of the current file.
expand('%:X:.') also works (as does :~).

Currently I have :X on systems other than win32 behaving the same as :p
- which would make it generally useful and transportable.

At the moment I've hacked it into eval.c, given GetShortPathName takes
all the correct parameters... and modifies the filename in place.

Firstly, it would be nice to know if this were required on other systems
(is there modification to allow the short-filename concept at all in
unix or VMS or other systems).. It's really only useful for Win32
programmers.. but I have a real use for it.

I tried making a function that worked out the short filename, but it is
woefully inadequate, and all I can find out is that it is a mathematical
function used to translate the long name (after the first 4, which just
use the first 6 - non-space characters).  I just can't work out / find
out from MSDN what the function used is (a hash of some sort?).

The documentation says it uses the first 2 characters, and then performs
a mathematical transform on the remaining characters (I'm assuming that

Re: Win32 Short filenames - comments?

Michael Geddes wrote:

> A call to win32 vimmers!
> 
> I _have created_ a patch that adds a modifier which is currently :X
> (from dir /x) that modifies 
> the filename to be the windows short file name.
> 
> ie : expand('%:X') 
> 
> Would return the full short filename of the current file.
> expand('%:X:.') also works (as does :~).

Since this is just a small change and can be very useful for people who
need this, I'm not against including this feature.

Two questions:
- Why ":X"?  Isn't there a more obvious name to get the short filename?
- Does this only shorten the last part of the path or also the directory
  names before it?

--

-- 
From "know your smileys":
 (X0||)   Double hamburger with lettuce and tomato

 ///  Bram Moolenaar -- Bram <at> moolenaar.net -- http://www.moolenaar.net  \\\
///          Creator of Vim - Vi IMproved -- http://www.vim.org          \\\
\\\           Project leader for A-A-P -- http://www.a-a-p.org           ///
 \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///

RE: Win32 Short filenames - comments?

> To stuff that ALL up, though, there is an API call that allows you to
> set the short name of a file *sigh*.

Only on NTFS drives, thank heavens.

I agree that this is a useful patch (though it would
be possible to get the functionality without patching
Vim by writing a small DLL and using libcall()), since
there are plenty of old command-line utilities
knocking around which need 8.3 filenames. I also
agree that :X is a bit odd - it makes me think on
encryption...  can we have ":~"  instead - the mnemonic
is obvious to anyone who will need the function ;)

Vince

Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this 
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such 
privilege. Please advise the sender if you receive this e-mail by mistake.

patch: python buffer number

 hello,

 this little patch adds buffer number to a list of it's attribute
 members. i found it useful in my script, perhaps it'll be useful for
 someone else as well.

 example:

 :py import vim
 :py cb = vim.current.buffer
 :py print cb.number
 :py print cb.__members__

--

-- 
		fuf		(fuf <at> mageo.cz)

--- vim61-python_buffer_number/src/if_python.c	Tue Oct  1 11:23:59 2002
+++ vim61/src/if_python.c	Fri Jan 11 09:53:29 2002
 <at>  <at>  -1234,10 +1234,8  <at>  <at> 

     if (strcmp(name, "name") == 0)
 	return Py_BuildValue("s",this->buf->b_ffname);
-    else if (strcmp(name, "number") == 0)
-        return Py_BuildValue("i",this->buf->b_fnum);
     else if (strcmp(name,"__members__") == 0)
-	return Py_BuildValue("[s,s]", "name", "number");
+	return Py_BuildValue("[s]", "name");
     else
 	return Py_FindMethod(BufferMethods, self, name);

Re: Win32 Short filenames - comments?

From: "Vince Negri" <vnegri <at> asl-electronics.co.uk>
> 
> I also agree that :X is a bit odd - it makes me think on
> encryption...  can we have ":~"  instead - the mnemonic is obvious
> to anyone who will need the function ;)

/x is the WinXP switch for the dir command which shows short names.
But I agree with Vince that :~ is more clever and memorable.

Michael, I'm looking forward to trying your patch and will feedback
once I get to work and apply it.

Steve Hall  [ digitect <at> mindspring.com ]

patch: cursorhold event in insert, visual mode

 hello,

 this little patch adds firing up of CursorHold event in INSERT and
 VISUAL mode. i hope i'm not ruining vim's code too much with this.

-- 
		fuf		(fuf <at> mageo.cz)

--- vim61-cursorhold_event_ext/src/gui.c	Tue Oct  1 12:52:30 2002
+++ vim61/src/gui.c	Tue Oct  1 12:45:43 2002
 <at>  <at>  -2409,10 +2409,8  <at>  <at> 
 	if (gui_mch_wait_for_chars(p_ut) != OK)
     {
 #ifdef FEAT_AUTOCMD
-        int real_state = get_real_state();
-	if (has_cursorhold() &&
-            (real_state == NORMAL_BUSY || real_state == INSERT || real_state == VISUAL))
-        {
+	if (has_cursorhold() && get_real_state() == NORMAL_BUSY)
+	{
 	    apply_autocmds(EVENT_CURSORHOLD, NULL, NULL, FALSE, curbuf);
 	    update_screen(VALID);
 	    showruler(FALSE);
--- vim61-cursorhold_event_ext/src/os_unix.c	Tue Oct  1 12:53:49 2002
+++ vim61/src/os_unix.c	Thu Mar 14 22:05:16 2002
 <at>  <at>  -341,9 +341,7  <at>  <at> 
 	if (WaitForChar(p_ut) == 0)
 	{
 #ifdef FEAT_AUTOCMD

Re: patch: cursorhold event in insert, visual mode

 grr, the patches are reversed - my apologies. if there's a need to send
 them normal, i'll do it. once more my apology.

--

-- 
		fuf		(fuf <at> mageo.cz)

Fw: iminsert on Windows

He wrote extra informations about this to me that he use these mappings:

    inoremap <Down> <C-O>g<Down>
    inoremap <Up> <C-O>g<Up>

This unexpected IM activation is caused by i_<C-O> in these mappings.
When input i_<C-O> to vim, ins_esc() is called and it call
im_save_status().  But im_save_status() doesn't save any values when
KeyTyped is FALSE: in the mapping.  So 'iminsert' will have old value.

I wrote 3 type patches for fixing this.  Each and all can fix this
problem, but I can't decide which one is the best (without side effects
and logically correct) solution.  Please check attached patches.

Thanks.
----
MURAOKA Taro  <koron <at> tka.att.ne.jp>

Hiroshi Iwatani wrote to vim <at> vim.org:
> In the writing mode, after you have used the input method
> more than once, up and down arrow keys keep playing the role
> of the <im-invoking-key> as if someone has assigned the
> extra key mapping.
> 
> This phenomenon never occurs on another Windows applications
> including other editors which I, a mild Vim addict, now dislike.
> 
> Setting iminsert=0 in the _vimrc file has no effect on this
> problem. Quite annoying if you want to continue inputting
> plain ASCII chars over multiple lines.

RE: Win32 Short filenames - comments?

Ok, I'll fix it up, make sure it has doco.

I wasn't realy convinced about :X either, but 
1) :S might be useful for something else
2) :~ is already taken (sorry Vince & Steve, that's home-directory
expansion),

 I could used :8 I guess (for 8.3) 

I didn't choose :X very carefully, just a proof of concept, but 
1) it's way out of the way for any other further extensions to the
syntax..
2) secondly it matched the /X  from DIR /X  which is how you can view
the short filenames in a prompt.

Vince, Steve - what do you think - any votes?

As to the other question - it shortens the whole path.  That's what the
API function does...

I had to modify/optimise :~ and :. so that if the path had already been
expanded (via :p or :X), then it wouldn't
try expanding it again.  Somebody will need to cast their eyes over that
bit to make sure it handles everything correctly as far as memory
allocation/deallocation.  I think it's correct, but I'm not familiar
enough with that code to do it.

Is it OK to have the WinAPI function as it is? Or would you prefer me to
wrap it in a mch_ wrapper? I guess it'd be 
nice if it worked across Samba shares from linux.