Re: Vim's ole functionality

[A.J.Mechelynck]

Sebastian Menge wrote:

Am Donnerstag, den 26.04.2007, 14:08 +0200 schrieb Sebastian Menge:

 Perhaps this Mail from eclipse helps:

[ ... ]

quote from that mail:


SWT supports the embedding of OleDocuments and Active X Controls only.
In order to be an ActiveX control, the control must support a minimum
set of interfaces.  The error you are getting is "Interface not
supported".  
[...] 

but my guess is it does not have the minimum set of API required to be
an ActiveX Control.
 
Some of the required interfaces are:
 
IOleObject

IOleInPlaceObject
IOleInPlaceActiveObject
IOleControl


Are the if_ole developers around? Does gvim implement these
interfaces !? I don't see them in the "OLEViewer" from M$ ...

Sebastian.



I don't think gvim ever meant to be an "ActiveX control". 

Best regards,
Tony.
--
Baker's First Law of Federal Geometry:
A block grant is a solid mass of money surrounded on all sides
by governors.

Re: vim 7.1?

[A.J.Mechelynck]

Jonathan Smith wrote:
[...]
Even if BM is the only one who can actually make a release, I'd imagine 
others have opinions on the matter. Anyway, I was just wondering.


-smithj



AFAICT, the current bugs are all (or almost all) mere bugfixes. I don't feel a 
release is imperatively called-for (but Bram has of course the final say). On 
Unix-like systems (like yours and mine) compiling Vim is really no problem; 
yet if you absolutely want it, I can make my binaries available. I don't know, 
however, whether they will even load without perl, python, ruby and tcl all 
installed, and I think the GUI won't load without Gnome2.



Best regards,
Tony.
--
Automobile, n.:
A four-wheeled vehicle that runs up hills and down
pedestrians.

Re: vim 7.1?

[Jonathan Smith]

A.J.Mechelynck wrote:
- Insane? All is relative. We're only at 7.0.233 as of today. FYI, Vim 
6.2 went to 532 patches, see http://ftp.vim.org/pub/vim/patches/


Release early, release often :)

- What devel tree? I'll believe that a 7.1 is on the rails when I see at 
least an alpha. Before that, AFA-anyone-CT, there's no "devel tree". 
Let's not "presume" about what we know nothing about.


Hence "presume".

- It's not "anyone", it's Bram Moolenaar and no-one else; and since he 
now has a full-time job again, it's a small sort of miracle that he 
still finds "some" time for Vim.


Even if BM is the only one who can actually make a release, I'd imagine others 
have opinions on the matter. Anyway, I was just wondering.


-smithj

feedkeys() allowed in sandbox

[Tomas Golembiovsky]

Greetings mortals,

today somebody came to #vim, and pasted some modeline (containig joke or
such). He muttered something about not knowing what that means and left
before long. But (!) what I noticed is that feedkeys() was used as part of
foldexpression and it turned out that feedkeys() is allowed in sandbox,
which means malicious file can run arbitrary command via modeline like
this:

vim: fdm=expr fde=feedkeys("\\:!touch\ phantom_was_here\\")

I guess you can see the consequences. Is this known/intentional?

-- 

Best regards,
Tomas Golembiovsky

--
||- - -
|
| Alan's Law of Research
| 
| The theory is supported as long as the funds are.
| 
|- - -

possible bug: lowercase dotless "i" and langmap

[Ali Polatel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,
  I was playing around with langmap and found out there is a problem with
characters
'ı'[1] - 0131;LATIN SMALL LETTER DOTLESS I - and
'ğ'[2] - 011F;LATIN SMALL LETTER G WITH BREVE
  The Turkish keyboard looks like this[3] for those who don't know about
it.
  The problem is when I set langmap=ıi small dotless I doesn't work as
expected. I'm using tr_TR.UTF-8 locale and I tried it both on the
console,with consoles on X and with gvim. The same is true
for g with breve. The other turkish keys work fine with langmap. I wasn't sure
if this was about my system or vim so I made some people with turkish keyboards
try this:
[EMAIL PROTECTED] ~ $ vim -c "set lmap=ıi
> execute \"normal ıhi\\"
> let line = getline(1)
> if line =~ \"hi\"
>echo \"The dotless small I works as expected\"
> else
>echo \"The dotless small I doesn't work with langmap\"
> endif "
- - there is probably a shorter way but anyway :) -
and they could reproduce the problem. 
  Internationalizing dotted and dotless letter "I" has always been a problem[4]
but I don't think this is the issue here because the same problem exists for g 
with
breve.

  Regards,

[1] http://www.fileformat.info/info/unicode/char/0131/index.htm
[2] http://www.fileformat.info/info/unicode/char/011f/index.htm
[3] 
http://upload.wikimedia.org/wikipedia/commons/thumb/6/63/KB_Turkey.svg/540px-KB_Turkey.svg.png
[4] http://www.i18nguy.com/unicode/turkish-i18n.html

- -- 
Ali Polatel (hawking) <[EMAIL PROTECTED]>
http://hawking.nonlogic.org/
gpg: 0x8E724EDC fp: DBC2 2BC7 95B8 6D6C 8BC3  37EC CA00 CFC1 8E72 4EDC
()  ascii ribbon campaign - against html mail
/\
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)

iD8DBQFGMRvFygDPwY5yTtwRAl34AKCR03ale9/J1wTZHd+iC2T4Jykl/ACgkoqE
NaEI8m12uXStnfwAZdt/MG8=
=pI61
-END PGP SIGNATURE-

Re: vim 7.1?

[A.J.Mechelynck]

Jonathan Smith wrote:
With the insane number of patches collecting against 7.0, and presumably 
the new features accumulating in the devel tree, is anyone thinking 
about when a 7.1 release might be made?


-smithj



- Insane? All is relative. We're only at 7.0.233 as of today. FYI, Vim 6.2 
went to 532 patches, see http://ftp.vim.org/pub/vim/patches/ .


- What devel tree? I'll believe that a 7.1 is on the rails when I see at least 
an alpha. Before that, AFA-anyone-CT, there's no "devel tree". Let's not 
"presume" about what we know nothing about.


- It's not "anyone", it's Bram Moolenaar and no-one else; and since he now has 
a full-time job again, it's a small sort of miracle that he still finds "some" 
time for Vim.



Best regards,
Tony.
--
There is no distinctly native American criminal class except Congress.
-- Mark Twain

vim 7.1?

[Jonathan Smith]

With the insane number of patches collecting against 7.0, and presumably the new 
features accumulating in the devel tree, is anyone thinking about when a 7.1 
release might be made?


-smithj

Re: syntax highlighting addition

[Bram Moolenaar]

Jonathan Smith wrote:

> sorry for the long time between replies. i've been busy on other things :)
> 
> Nikolai Weibull wrote:
>  > Well, the rpm spec file-type has been with us a long time, well before
>  > we knew better.  Try to give your file-type an as specific name as
>  > possible.  You will not be getting the name "recipe"; it's way too
>  > generic in this day and age.  Go with "conrecipe" or something
>  > similar.  Remember: Bram has his own build system, called Aap, which
>  > also uses recipes.  Also, if Vim will never edit a (Conary) changeset,
>  > then why will we have to worry about a name-clash between different
>  > conary file-types?
> 
> done - changed to conaryRecipe.

No other filetype has an uppercase letter.  I would call it
conaryrecipe.  It's a bit long, but clear.

Now all items in the syntax file need to start with "conaryrecipe" to
avoid any confusion with other syntax files and highlighting items.
"b:current_syntax" also needs to be set to the same name.

>  > Nitpick: remove the empty comment.
> 
> done
> 
>  > Just do
>  >
>  > if exists("b:current_syntax")
>  >  finish
>  > endif
>  >
>  > No one will be using your syntax definition with vim 5 anyway.  Let's
>  > keep new files clean from (now) unnecessary cruft.
> 
> done
> 
>  >> syn match   conaryUse   "Use\.[a-z0-9.]*" contains=conaryUseFlag
>  >
>  > Sure that * shouldn't be a \+?  And can you have a sequence of dots,
>  > as in Use...?
> 
> done
> 
>  > A better way of doing this is to do (substitute \w with whatever
>  > pattern your parser actually allows)
>  >
>  > syn match conaryUse
>  > \ "Use\.\w\+"
>  > \ nextgroup=conaryUseFlag
>  >
>  > syn keyword conaryUseFlag
>  > \ contained
>  > \ nextgroup=conaryUseFlagSeparator
>  > \ pcre
>  > \ tcpwrappers
>  > \ ...
>  >
>  > syn match conaryUseFlagSeparator
>  > \ contained
>  > \ nextgroup=conaryUseFlag
>  > \ '\.'
> 
> that didn't work for me for some reason. perhaps i'm misunderstanding?
> 
>  >> "syn match   conaryR"r\.\w*" contains=conaryFunction
>  >
>  > Leftover?
> 
> yes. axed.
> 
>  >> if version >= 508 || !exists("did_python_syn_inits")
>  >>   if version <= 508
>  >>let did_python_syn_inits = 1
>  >> command -nargs=+ HiLink hi link 
>  >>   else
>  >> command -nargs=+ HiLink hi def link 
>  >>   endif
>  >
>  > Just skip this.  No one will be using your syntax definition with Vim 5.
> 
> yep, removed. as i said, rPath has been maintaining this for a long time. :)

You might as well use "hi def link" instead of HiLink.

>  >>   "HiLink pythonStatement   Statement
>  >>   "HiLink pythonFunctionFunction
>  >>   "HiLink pythonConditional Conditional
>  >>   "HiLink pythonRepeat  Repeat
>  >>   "HiLink pythonString  String
>  >>   "HiLink pythonRawString   String
>  >>   "HiLink pythonEscape  Special
>  >>   "HiLink pythonOperatorOperator
>  >>   "HiLink pythonPreCondit   PreCondit
>  >>   "HiLink pythonComment Comment
>  >>   "HiLink pythonTodoTodo
>  >
>  > ?
> 
> all wacked. just crufty.

But the "python" syntax items are still there.  This doesn't look right.

>  >> " vim: ts=8
>  >
>  > This is the default setting.
> 
> removed
> 
> new version attached, as before. thanks for the feedback. further feedback 
> requested :)

-- 
hundred-and-one symptoms of being an internet addict:
27. You refer to your age as 3.x.

 /// 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///

Re: syntax highlighting addition

[Nikolai Weibull]

It's getting there.

On 4/26/07, Jonathan Smith <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:



 > A better way of doing this is to do (substitute \w with whatever
 > pattern your parser actually allows)
 >
 > syn match conaryUse
 > \ "Use\.\w\+"
 > \ nextgroup=conaryUseFlag


Oops.  That should be

syn keyword conaryUse
 \ nextgroup=conaryUseFlagSeparator
 \ Use


" Vim syntax file
" Language: Conary Recipe
" Maintainer:   rPath Inc 
" Updated:  2007-04-26
"


The empty comment is still there.  Just leave that line blank.  No
biggie, of course, just aesthetics.


runtime! syntax/python.vim


Just to make sure: Python is allowed anywhere in a conary recipe?


syn keyword conarySFunction mainDir addAction addSource addArchive addPatch


If you change the filetype name to conaryrecipe (note: no caps),
you'll also have to change the syntax-group names.


syn match   conaryMacro "%(\w*)[sd]" contained
syn match   conaryBadMacro  "%(\w*)[^sd]" contained " no final marker


OK, so you can have the following:

%()s

or should it be "%(\w\+)[sd]"


" strings
syn region pythonString matchgroup=Normal start=+[uU]\='+ end=+'+ 
skip=+\|\\'+ contains=pythonEscape,conaryMacro,conaryBadMacro
syn region pythonString matchgroup=Normal start=+[uU]\="+ end=+"+ 
skip=+\|\\"+ contains=pythonEscape,conaryMacro,conaryBadMacro
syn region pythonString matchgroup=Normal start=+[uU]\="""+ end=+"""+ 
contains=pythonEscape,conaryMacro,conaryBadMacro
syn region pythonString matchgroup=Normal start=+[uU]\='''+ end=+'''+ 
contains=pythonEscape,conaryMacro,conaryBadMacro
syn region pythonRawString  matchgroup=Normal start=+[uU]\=[rR]'+ end=+'+ 
skip=+\|\\'+ contains=conaryMacro,conaryBadMacro
syn region pythonRawString  matchgroup=Normal start=+[uU]\=[rR]"+ end=+"+ 
skip=+\|\\"+ contains=conaryMacro,conaryBadMacro
syn region pythonRawString  matchgroup=Normal start=+[uU]\=[rR]"""+ 
end=+"""+ contains=conaryMacro,conaryBadMacro
syn region pythonRawString  matchgroup=Normal start=+[uU]\=[rR]'''+ 
end=+'''+ contains=conaryMacro,conaryBadMacro


I wonder if naming them pythonX is very good.  Bram?


if version >= 508 || !exists("did_python_syn_inits")
  command -nargs=+ HiLink hi def link 

  " The default methods for highlighting.  Can be overridden later
  HiLink conaryMacroSpecial
  HiLink conaryBFunctionFunction
  HiLink conaryGFunctionFunction
  HiLink conarySFunctionOperator
  HiLink conaryPFunctionTypedef
  HiLink conaryFlagsPreCondit
  HiLink conaryArches   Special
  HiLink conarySubArchesSpecial
  HiLink conaryBad  Error
  HiLink conaryBadMacro Error
  HiLink conaryKeywords Special
  HiLink conaryUseFlag  Typedef

  delcommand HiLink
endif


Substitute that with

hi def link conaryrecipeMacro Macro
hi def link conaryrecipeFunction Function
hi def link conaryrecipeBFunction conaryrecipeFunction
hi def link conaryrecipeGFunction conaryrecipeFunction
:
:

(If conary recipe macros aren't much like macros in C, then perhaps
Special is better.  Also note the linking of a generic group to
function and then other groups linking to them so that a user can
change them all en masse, to something they like.)

That HiLink cruft is also Vim5 compatibility stuff.  And remove the if
statement.


let b:current_syntax = "recipe"


This should be

let b:current_syntax = "conaryrecipe"

 nikolai

Re: syntax highlighting addition

[Jonathan Smith]

sorry for the long time between replies. i've been busy on other things :)

Nikolai Weibull wrote:
> Well, the rpm spec file-type has been with us a long time, well before
> we knew better.  Try to give your file-type an as specific name as
> possible.  You will not be getting the name "recipe"; it's way too
> generic in this day and age.  Go with "conrecipe" or something
> similar.  Remember: Bram has his own build system, called Aap, which
> also uses recipes.  Also, if Vim will never edit a (Conary) changeset,
> then why will we have to worry about a name-clash between different
> conary file-types?

done - changed to conaryRecipe.

> Nitpick: remove the empty comment.

done

> Just do
>
> if exists("b:current_syntax")
>  finish
> endif
>
> No one will be using your syntax definition with vim 5 anyway.  Let's
> keep new files clean from (now) unnecessary cruft.

done

>> syn match   conaryUse   "Use\.[a-z0-9.]*" contains=conaryUseFlag
>
> Sure that * shouldn't be a \+?  And can you have a sequence of dots,
> as in Use...?

done

> A better way of doing this is to do (substitute \w with whatever
> pattern your parser actually allows)
>
> syn match conaryUse
> \ "Use\.\w\+"
> \ nextgroup=conaryUseFlag
>
> syn keyword conaryUseFlag
> \ contained
> \ nextgroup=conaryUseFlagSeparator
> \ pcre
> \ tcpwrappers
> \ ...
>
> syn match conaryUseFlagSeparator
> \ contained
> \ nextgroup=conaryUseFlag
> \ '\.'

that didn't work for me for some reason. perhaps i'm misunderstanding?

>> "syn match   conaryR"r\.\w*" contains=conaryFunction
>
> Leftover?

yes. axed.

>> if version >= 508 || !exists("did_python_syn_inits")
>>   if version <= 508
>>let did_python_syn_inits = 1
>> command -nargs=+ HiLink hi link 
>>   else
>> command -nargs=+ HiLink hi def link 
>>   endif
>
> Just skip this.  No one will be using your syntax definition with Vim 5.

yep, removed. as i said, rPath has been maintaining this for a long time. :)

>>   "HiLink pythonStatement   Statement
>>   "HiLink pythonFunctionFunction
>>   "HiLink pythonConditional Conditional
>>   "HiLink pythonRepeat  Repeat
>>   "HiLink pythonString  String
>>   "HiLink pythonRawString   String
>>   "HiLink pythonEscape  Special
>>   "HiLink pythonOperatorOperator
>>   "HiLink pythonPreCondit   PreCondit
>>   "HiLink pythonComment Comment
>>   "HiLink pythonTodoTodo
>
> ?

all wacked. just crufty.

>> " vim: ts=8
>
> This is the default setting.

removed

new version attached, as before. thanks for the feedback. further feedback 
requested :)


-smithj

--- vim63/runtime/filetype.vim.old	2005-07-29 18:16:25.0 -0400
+++ vim63/runtime/filetype.vim	2005-07-29 18:16:32.0 -0400
@@ -1216,6 +1216,9 @@
   endif
 endfun
 
+" Conary Recipe
+au BufNewFile,BufRead *.recipe		setf conaryRecipe
+
 " Remind
 au BufNewFile,BufRead .reminders*		setf remind
 
" Vim syntax file
" Language: Conary Recipe
" Maintainer:   rPath Inc 
" Updated:  2007-04-26
"
if exists("b:current_syntax")
  finish
endif

runtime! syntax/python.vim
syn keyword conarySFunction mainDir addAction addSource addArchive addPatch
syn keyword conarySFunction addRedirect

syn keyword conaryGFunction add addAll addNewGroup addReference createGroup
syn keyword conaryGFunction addNewGroup startGroup remove removeComponents
syn keyword conaryGFunction replace setByDefault setDefaultGroup 
syn keyword conaryGFunction setLabelPath addCopy setSearchPath

syn keyword conaryBFunction Run Automake Configure ManualConfigure 
syn keyword conaryBFunction Make MakeParallelSubdir MakeInstall
syn keyword conaryBFunction MakePathsInstall CompilePython
syn keyword conaryBFunction Ldconfig Desktopfile Environment SetModes
syn keyword conaryBFunction Install Copy Move Symlink Link Remove Doc
syn keyword conaryBFunction Create MakeDirs disableParallelMake
syn keyword conaryBFunction ConsoleHelper Replace SGMLCatalogEntry
syn keyword conaryBFunction XInetdService XMLCatalogEntry TestSuite
syn keyword conaryBFunction PythonSetup

syn keyword conaryPFunction NonBinariesInBindirs FilesInMandir 
syn keyword conaryPFunction ImproperlyShared CheckSonames CheckDestDir
syn keyword conaryPFunction ComponentSpec PackageSpec 
syn keyword conaryPFunction Config InitScript GconfSchema SharedLibrary
syn keyword conaryPFunction ParseManifest MakeDevices DanglingSymlinks
syn keyword conaryPFunction AddModes WarnWriteable IgnoredSetuid
syn keyword conaryPFunction Ownership ExcludeDirectories
syn keyword conaryPFunction BadFilenames BadInterpreterPaths ByDefault
syn keyword conaryPFunction ComponentProvides ComponentRequires Flavor
syn keyword conaryPFunction EnforceConfigLogBuildRequirements Group
syn keyword conaryPFunction EnforceSonameBuildRequirements InitialContents
syn keyword conary

patch 7.0.233 (extra)

[Bram Moolenaar]

Patch 7.0.233 (extra)
Problem:Mac: code formatted badly.
Solution:   Fix code formatting
Files:  src/gui_mac.c


*** ../vim-7.0.232/src/gui_mac.cThu Apr 26 18:22:12 2007
--- src/gui_mac.c   Fri Mar 16 11:26:05 2007
***
*** 28,38 
   *
   */
  
!  /* TODO (Jussi)
!   *   * Clipboard does not work (at least some cases)
!   *   * ATSU font rendering has some problems
!   *   * Investigate and remove dead code (there is still lots of that)
!   */
  
  #include  /* included first to avoid CR problems */
  #include "vim.h"
--- 28,38 
   *
   */
  
! /* TODO (Jussi)
!  *   * Clipboard does not work (at least some cases)
!  *   * ATSU font rendering has some problems
!  *   * Investigate and remove dead code (there is still lots of that)
!  */
  
  #include  /* included first to avoid CR problems */
  #include "vim.h"
***
*** 504,512 
  /* Get number of files in list */
  *error = AECountItems(theList, numFiles);
  if (*error)
! {
!   return(fnames);
! }
  
  /* Allocate the pointer list */
  fnames = (char_u **) alloc(*numFiles * sizeof(char_u *));
--- 504,510 
  /* Get number of files in list */
  *error = AECountItems(theList, numFiles);
  if (*error)
!   return fnames;
  
  /* Allocate the pointer list */
  fnames = (char_u **) alloc(*numFiles * sizeof(char_u *));
***
*** 526,532 
{
/* Caller is able to clean up */
/* TODO: Should be clean up or not? For safety. */
!   return(fnames);
}
  
/* Convert the FSSpec to a pathname */
--- 524,530 
{
/* Caller is able to clean up */
/* TODO: Should be clean up or not? For safety. */
!   return fnames;
}
  
/* Convert the FSSpec to a pathname */
***
*** 589,603 
  
  error = AEGetParamPtr(theAEvent, keyDirectObject, typeChar, &typeCode, 
(Ptr) &SearchData, sizeof(WindowSearch), &actualSize);
  if (error)
! {
!   return(error);
! }
  
  error = HandleUnusedParms(theAEvent);
  if (error)
! {
!   return(error);
! }
  
  for (buf = firstbuf; buf != NULL; buf = buf->b_next)
if (buf->b_ml.ml_mfp != NULL
--- 587,597 
  
  error = AEGetParamPtr(theAEvent, keyDirectObject, typeChar, &typeCode, 
(Ptr) &SearchData, sizeof(WindowSearch), &actualSize);
  if (error)
!   return error;
  
  error = HandleUnusedParms(theAEvent);
  if (error)
!   return error;
  
  for (buf = firstbuf; buf != NULL; buf = buf->b_next)
if (buf->b_ml.ml_mfp != NULL
***
*** 668,676 
  
  error = HandleUnusedParms(theAEvent);
  if (error)
! {
!   return(error);
! }
  
  /* Send the reply */
  /*  replyObject.descriptorType = typeNull;
--- 662,668 
  
  error = HandleUnusedParms(theAEvent);
  if (error)
!   return error;
  
  /* Send the reply */
  /*  replyObject.descriptorType = typeNull;
***
*** 679,687 
  /* AECreateDesc(typeChar, (Ptr)&title[1], title[0], &data) */
  error = AECreateList(nil, 0, false, &replyList);
  if (error)
! {
!   return(error);
! }
  
  #if 0
  error = AECountItems(&replyList, &numFiles);
--- 671,677 
  /* AECreateDesc(typeChar, (Ptr)&title[1], title[0], &data) */
  error = AECreateList(nil, 0, false, &replyList);
  if (error)
!   return error;
  
  #if 0
  error = AECountItems(&replyList, &numFiles);
***
*** 775,783 
  error = AEGetParamPtr(theAEvent, keyDirectObject, typeChar, &typeCode, 
(Ptr) &GetTextData, sizeof(GetTextData), &actualSize);
  
  if (error)
! {
!   return(error);
! }
  
  for (buf = firstbuf; buf != NULL; buf = buf->b_next)
if (buf->b_ml.ml_mfp != NULL)
--- 765,771 
  error = AEGetParamPtr(theAEvent, keyDirectObject, typeChar, &typeCode, 
(Ptr) &GetTextData, sizeof(GetTextData), &actualSize);
  
  if (error)
!   return error;
  
  for (buf = firstbuf; buf != NULL; buf = buf->b_next)
if (buf->b_ml.ml_mfp != NULL)
***
*** 826,837 
  }
  
  error = HandleUnusedParms(theAEvent);
- if (error)
- {
-   return(error);
- }
  
! return(error);
  }
  
  /*
--- 814,821 
  }
  
  error = HandleUnusedParms(theAEvent);
  
! return error;
  }
  
  /*
***
*** 1017,1025 
  /* the direct object parameter is the list of aliases to files (one or 
more) */
  error = AEGetParamDesc(theAEvent, keyDirectObject, typeAEList, &theList);
  if (error)
! {
!   return(error);
! }
  
  
  error = AEGetParamPtr(theAEvent, keyAEPosition, typeChar, &typeCode, 
(Ptr) &thePosition, sizeof(SelectionRange), &actualSize);
--- 1001,1007 
  /* the direct object parameter is the list of aliases to files (one or 
more) */
  error = AEGetParamDesc(the

Re: [PATCH] Determining whether a window used :lcd

[Nikolai Weibull]

On 4/26/07, Bob Hiestand <[EMAIL PROTECTED]> wrote:

On 4/26/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
> > > Either way, wouldn't it be more useful to alter getcwd() to take an
> > > optional argument stating whether we want the local or global cwd?
>
> > The problem is that my plugin needs to change the current working
> > directory, perform an action, and then restore the previous working
> > directory.  I need to know whether to use :lcd or :cd to do that.  If
> > I use :cd in a window that had previously used :lcd, then I clobbered
> > the :lcd usage and that window is now stuck to the global directory;
> > additionally, the global directory is changed to whatever the prior
> > value.  If I instead use :lcd always, and the window wasn't previously
> > using a local directory, it now is.
>
> let saved_cwd = getcwd('local')
> let cd_cmd = (saved_cwd != getcwd('global')) ? 'lcd' : 'cd'
> exec cd_cmd '…'
> ⋮
> exec cd_cmd saved_cwd
>
> (assuming getcwd('local') returns the local directory, if there is
> one, or whatever getcwd('global') would, if not.)

While, again, that functionality would suit my plugin's need, I can't
help but feel that that's a pretty inefficient way of checking
compared to:


As in, what, perhaps 8 ms instead of 6 ms?


let cd_cmd = haslocaldir() ? 'lcd' : 'cd'

In the larger picture, I don't know why you'd want to distinguish
between local and global directory normally, other than to determine
the correct ':l?cd' to use, so I don't think that specifying a
parameter to getcwd() to be very useful.


Say that you want to change the local directory to the global directory:

:exec 'cd' getcwd('local')


haslocaldir() has the advantage of (imo) being simpler.


And the disadvantage of being incredibly specific, adding another
function, and more documentation.

And still, wouldn't it be a lot cleaner to have something like
:pushd/:popd for a directory stack.  Then one could write

:pushd ...
⋮
:popd

That way one can easily change directories and later get back to the
state one was in.

It would have to keep track of global and local changes somehow, but
that shouldn't be impossible.

 nikolai

patch 7.0.232 (extra)

[Bram Moolenaar]

Patch 7.0.232 (extra)
Problem:Mac: doesn't support GUI tab page labels.
Solution:   Add GUI tab page labels. (Nicolas Weber)
Files:  src/feature.h, src/gui.c, src/gui.h, src/gui_mac.c,
src/proto/gui_mac.pro


*** ../vim-7.0.231/src/feature.hWed Nov  1 18:10:36 2006
--- src/feature.h   Thu Mar 15 19:02:15 2007
***
*** 756,761 
--- 756,762 
  #if defined(FEAT_WINDOWS) && defined(FEAT_NORMAL) \
  && (defined(FEAT_GUI_GTK) \
|| (defined(FEAT_GUI_MOTIF) && defined(HAVE_XM_NOTEBOOK_H)) \
+   || defined(FEAT_GUI_MAC) \
|| (defined(FEAT_GUI_MSWIN) && (!defined(_MSC_VER) || _MSC_VER > 1020)))
  # define FEAT_GUI_TABLINE
  #endif
*** ../vim-7.0.231/src/gui.cTue Oct 10 17:36:50 2006
--- src/gui.c   Thu Mar 15 19:02:15 2007
***
*** 1159,1165 
  #endif
  
  # if defined(FEAT_GUI_TABLINE) && (defined(FEAT_GUI_MSWIN) \
!   || defined(FEAT_GUI_MOTIF))
  if (gui_has_tabline())
text_area_y += gui.tabline_height;
  #endif
--- 1159,1165 
  #endif
  
  # if defined(FEAT_GUI_TABLINE) && (defined(FEAT_GUI_MSWIN) \
!   || defined(FEAT_GUI_MOTIF) || defined(FEAT_GUI_MAC))
  if (gui_has_tabline())
text_area_y += gui.tabline_height;
  #endif
*** ../vim-7.0.231/src/gui.hThu Apr 27 01:52:33 2006
--- src/gui.h   Thu Mar 15 19:02:15 2007
***
*** 421,427 
  #endif/* FEAT_GUI_GTK */
  
  #if defined(FEAT_GUI_TABLINE) \
!   && (defined(FEAT_GUI_W32) || defined(FEAT_GUI_MOTIF))
  int   tabline_height;
  #endif
  
--- 425,432 
  #endif/* FEAT_GUI_GTK */
  
  #if defined(FEAT_GUI_TABLINE) \
!   && (defined(FEAT_GUI_W32) || defined(FEAT_GUI_MOTIF) \
!  || defined(FEAT_GUI_MAC))
  int   tabline_height;
  #endif
  
*** ../vim-7.0.231/src/gui_mac.cThu Mar  8 20:39:02 2007
--- src/gui_mac.c   Fri Mar 16 11:26:05 2007
***
*** 4,10 
   *GUI/Motif support by Robert Webb
   *Macintosh port by Dany St-Amant
   *  and Axel Kielhorn
!  *Port to MPW by Bernhard PrŸmmer
   *Initial Carbon port by Ammon Skidmore
   *
   * Do ":help uganda"  in Vim to read copying and usage conditions.
--- 4,10 
   *GUI/Motif support by Robert Webb
   *Macintosh port by Dany St-Amant
   *  and Axel Kielhorn
!  *Port to MPW by Bernhard Pruemmer
   *Initial Carbon port by Ammon Skidmore
   *
   * Do ":help uganda"  in Vim to read copying and usage conditions.
***
*** 260,265 
--- 260,270 
  OSErr HandleUnusedParms(const AppleEvent *theAEvent);
  #endif
  
+ #ifdef FEAT_GUI_TABLINE
+ static void initialise_tabline(void);
+ static WindowRef drawer = NULL; // TODO: put into gui.h
+ #endif
+ 
  /*
   * 
   * Conversion Utility
***
*** 2357,2362 
--- 2323,2335 
  
  thePart = FindWindow(theEvent->where, &whichWindow);
  
+ #ifdef FEAT_GUI_TABLINE
+ /* prevent that the vim window size changes if it's activated by a
+click into the tab pane */
+ if (whichWindow == drawer)
+ return;
+ #endif
+ 
  switch (thePart)
  {
case (inDesk):
***
*** 3097,3102 
--- 3070,3082 
  #endif
  */
  
+ #ifdef FEAT_GUI_TABLINE
+ /*
+  * Create the tabline
+  */
+ initialise_tabline();
+ #endif
+ 
  /* TODO: Load bitmap if using TOOLBAR */
  return OK;
  }
***
*** 5895,5901 
  theCPB.dirInfo.ioFDirIndex = 0;
  theCPB.dirInfo.ioNamePtr   = file.name;
  theCPB.dirInfo.ioVRefNum   = file.vRefNum;
!   /*theCPB.hFileInfo.ioDirID   = 0;*/
  theCPB.dirInfo.ioDrDirID   = file.parID;
  
  /* As ioFDirIndex = 0, get the info of ioNamePtr,
--- 5875,5881 
  theCPB.dirInfo.ioFDirIndex = 0;
  theCPB.dirInfo.ioNamePtr   = file.name;
  theCPB.dirInfo.ioVRefNum   = file.vRefNum;
! /*theCPB.hFileInfo.ioDirID   = 0;*/
  theCPB.dirInfo.ioDrDirID   = file.parID;
  
  /* As ioFDirIndex = 0, get the info of ioNamePtr,
***
*** 6093,6096 
--- 6073,6479 
  return (script != smRoman
&& script == GetScriptManagerVariable(smSysScript)) ? 1 : 0;
  }
+ 
  #endif /* defined(USE_IM_CONTROL) || defined(PROTO) */
+ 
+ 
+ 
+ 
+ #if defined(FEAT_GUI_TABLINE) || defined(PROTO)
+ // drawer implementation
+ static MenuRef contextMenu = NULL;
+ enum
+ {
+ kTabContextMenuId = 42,
+ };
+ 
+ // the caller has to CFRelease() the returned string
+ static CFStringRef
+ getTabLabel(tabpage_T *page)
+ {
+ get_tabline_label(page, FALSE);
+ #ifdef MACOS_CONVERT
+ return mac_enc_to_cfstring(NameBuff, STR

Re: Vim's ole functionality

[Sebastian Menge]

Am Donnerstag, den 26.04.2007, 14:08 +0200 schrieb Sebastian Menge:
>  Perhaps this Mail from eclipse helps:
[ ... ]

quote from that mail:

> SWT supports the embedding of OleDocuments and Active X Controls only.
> In order to be an ActiveX control, the control must support a minimum
> set of interfaces.  The error you are getting is "Interface not
> supported".  
[...] 
> but my guess is it does not have the minimum set of API required to be
> an ActiveX Control.
>  
> Some of the required interfaces are:
>  
> IOleObject
> IOleInPlaceObject
> IOleInPlaceActiveObject
> IOleControl

Are the if_ole developers around? Does gvim implement these
interfaces !? I don't see them in the "OLEViewer" from M$ ...

Sebastian.

patch 7.0.231

[Bram Moolenaar]

Patch 7.0.231
Problem:When recovering from a swap file the page size is likely to be
different from the minimum.  The block used for the first page
then has a buffer of the wrong size, causing a crash when it's
reused later.  (Zephaniah Hull)
Solution:   Reallocate the buffer when the page size changes.  Also check that
the page size is at least the minimum value.
Files:  src/memline.c


*** ../vim-7.0.230/src/memline.cTue Mar  6 20:27:03 2007
--- src/memline.c   Thu Apr 19 16:10:39 2007
***
*** 1015,1032 
--- 1015,1053 
msg_end();
goto theend;
  }
+ 
  /*
   * If we guessed the wrong page size, we have to recalculate the
   * highest block number in the file.
   */
  if (mfp->mf_page_size != (unsigned)char_to_long(b0p->b0_page_size))
  {
+   unsigned previous_page_size = mfp->mf_page_size;
+ 
mf_new_page_size(mfp, (unsigned)char_to_long(b0p->b0_page_size));
+   if (mfp->mf_page_size < previous_page_size)
+   {
+   msg_start();
+   msg_outtrans_attr(mfp->mf_fname, attr | MSG_HIST);
+   MSG_PUTS_ATTR(_(" has been damaged (page size is smaller than 
minimum value).\n"),
+   attr | MSG_HIST);
+   msg_end();
+   goto theend;
+   }
if ((size = lseek(mfp->mf_fd, (off_t)0L, SEEK_END)) <= 0)
mfp->mf_blocknr_max = 0;/* no file or empty file */
else
mfp->mf_blocknr_max = (blocknr_T)(size / mfp->mf_page_size);
mfp->mf_infile_count = mfp->mf_blocknr_max;
+ 
+   /* need to reallocate the memory used to store the data */
+   p = alloc(mfp->mf_page_size);
+   if (p == NULL)
+   goto theend;
+   mch_memmove(p, hp->bh_data, previous_page_size);
+   vim_free(hp->bh_data);
+   hp->bh_data = p;
+   b0p = (ZERO_BL *)(hp->bh_data);
  }
  
  /*
*** ../vim-7.0.230/src/version.cThu Apr 26 17:08:16 2007
--- src/version.c   Thu Apr 26 17:11:38 2007
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 231,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
23. You can't call your mother...she doesn't have a modem.

 /// 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///

Re: [PATCH] Determining whether a window used :lcd

[Bob Hiestand]

On 4/26/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:

> > Either way, wouldn't it be more useful to alter getcwd() to take an
> > optional argument stating whether we want the local or global cwd?

> The problem is that my plugin needs to change the current working
> directory, perform an action, and then restore the previous working
> directory.  I need to know whether to use :lcd or :cd to do that.  If
> I use :cd in a window that had previously used :lcd, then I clobbered
> the :lcd usage and that window is now stuck to the global directory;
> additionally, the global directory is changed to whatever the prior
> value.  If I instead use :lcd always, and the window wasn't previously
> using a local directory, it now is.

let saved_cwd = getcwd('local')
let cd_cmd = (saved_cwd != getcwd('global')) ? 'lcd' : 'cd'
exec cd_cmd '…'
⋮
exec cd_cmd saved_cwd

(assuming getcwd('local') returns the local directory, if there is
one, or whatever getcwd('global') would, if not.)


While, again, that functionality would suit my plugin's need, I can't
help but feel that that's a pretty inefficient way of checking
compared to:

let cd_cmd = haslocaldir() ? 'lcd' : 'cd'

In the larger picture, I don't know why you'd want to distinguish
between local and global directory normally, other than to determine
the correct ':l?cd' to use, so I don't think that specifying a
parameter to getcwd() to be very useful.  haslocaldir() has the
advantage of (imo) being simpler.

Thank you,

bob

patch 7.0.230

[Bram Moolenaar]

Patch 7.0.230
Problem:After using ":lcd" a script doesn't know how to restore the
current directory.
Solution:   Add the haslocaldir() function. (Bob Hiestand)
Files:  runtime/doc/usr_41.txt, runtime/doc/eval.txt, src/eval.c


*** ../vim-7.0.229/runtime/doc/usr_41.txt   Sun May  7 17:02:39 2006
--- runtime/doc/usr_41.txt  Thu Apr 26 17:06:48 2007
***
*** 1,4 
! *usr_41.txt*  For Vim version 7.0.  Last change: 2006 Apr 30
  
 VIM USER MANUAL - by Bram Moolenaar
  
--- 1,4 
! *usr_41.txt*  For Vim version 7.0.  Last change: 2007 Apr 26
  
 VIM USER MANUAL - by Bram Moolenaar
  
***
*** 703,708 
--- 703,709 
isdirectory()   check if a directory exists
getfsize()  get the size of a file
getcwd()get the current working directory
+   haslocaldir()   check if current window used |:lcd|
tempname()  get the name of a temporary file
mkdir() create a new directory
delete()delete a file
*** ../vim-7.0.229/runtime/doc/eval.txt Tue Mar 27 10:20:58 2007
--- runtime/doc/eval.txtTue Apr 24 21:50:49 2007
***
*** 1,4 
! *eval.txt*  For Vim version 7.0.  Last change: 2006 Nov 01
  
  
  VIM REFERENCE MANUALby Bram Moolenaar
--- 1,4 
! *eval.txt*  For Vim version 7.0.  Last change: 2007 Apr 24
  
  
  VIM REFERENCE MANUALby Bram Moolenaar
***
*** 1623,1628 
--- 1633,1639 
  globpath( {path}, {expr}) String  do glob({expr}) for all dirs in {path}
  has( {feature})   Number  TRUE if feature {feature} 
supported
  has_key( {dict}, {key})   Number  TRUE if {dict} has entry {key}
+ haslocaldir() Number  TRUE if current window executed |:lcd|
  hasmapto( {what} [, {mode} [, {abbr}]])
Number  TRUE if mapping to {what} exists
  histadd( {history},{item})String  add an item to a history
***
*** 3016,3021 
--- 3041,3049 
The result is a Number, which is 1 if |Dictionary| {dict} has
an entry with key {key}.  Zero otherwise.
  
+ haslocaldir() *haslocaldir()*
+   The result is a Number, which is 1 when the current
+ window has set a local path via |:lcd|, and 0 otherwise.
  
  hasmapto({what} [, {mode} [, {abbr}]])*hasmapto()*
The result is a Number, which is 1 if there is a mapping that
*** ../vim-7.0.229/src/eval.c   Thu Apr 26 10:55:46 2007
--- src/eval.c  Thu Apr 26 10:52:09 2007
***
*** 541,546 
--- 541,547 
  static void f_globpath __ARGS((typval_T *argvars, typval_T *rettv));
  static void f_has __ARGS((typval_T *argvars, typval_T *rettv));
  static void f_has_key __ARGS((typval_T *argvars, typval_T *rettv));
+ static void f_haslocaldir __ARGS((typval_T *argvars, typval_T *rettv));
  static void f_hasmapto __ARGS((typval_T *argvars, typval_T *rettv));
  static void f_histadd __ARGS((typval_T *argvars, typval_T *rettv));
  static void f_histdel __ARGS((typval_T *argvars, typval_T *rettv));
***
*** 7110,7115 
--- 7111,7117 
  {"globpath",  2, 2, f_globpath},
  {"has",   1, 1, f_has},
  {"has_key",   2, 2, f_has_key},
+ {"haslocaldir",   0, 0, f_haslocaldir},
  {"hasmapto",  1, 3, f_hasmapto},
  {"highlightID",   1, 1, f_hlID},  /* obsolete */
  {"highlight_exists",1, 1, f_hlexists},/* obsolete */
***
*** 11131,11136 
--- 11133,11150 
  
  rettv->vval.v_number = dict_find(argvars[0].vval.v_dict,
  get_tv_string(&argvars[1]), -1) != NULL;
+ }
+ 
+ /*
+  * "haslocaldir()" function
+  */
+ /*ARGSUSED*/
+ static void
+ f_haslocaldir(argvars, rettv)
+ typval_T  *argvars;
+ typval_T  *rettv;
+ {
+ rettv->vval.v_number = (curwin->w_localdir != NULL);
  }
  
  /*
*** ../vim-7.0.229/src/version.cThu Apr 26 16:50:05 2007
--- src/version.c   Thu Apr 26 17:04:15 2007
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 230,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
22. You've already visited all the links at Yahoo and you're halfway through
Lycos.

 /// 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///

patch 7.0.229

[Bram Moolenaar]

Patch 7.0.229
Problem:When 'pastetoggle' starts with Esc then pressing Esc in Insert
mode will not time out. (Jeffery Small)
Solution:   Use KL_PART_KEY instead of KL_PART_MAP, so that 'ttimeout' applies
to the 'pastetoggle' key.
Files:  src/getchar.c


*** ../vim-7.0.228/src/getchar.cSun Mar  4 21:25:44 2007
--- src/getchar.c   Thu Apr 19 22:13:37 2007
***
*** 2183,2189 
}
/* Need more chars for partly match. */
if (mlen == typebuf.tb_len)
!   keylen = KL_PART_MAP;
else if (max_mlen < mlen)
/* no match, may have to check for termcode at
 * next character */
--- 2187,2193 
}
/* Need more chars for partly match. */
if (mlen == typebuf.tb_len)
!   keylen = KL_PART_KEY;
else if (max_mlen < mlen)
/* no match, may have to check for termcode at
 * next character */
*** ../vim-7.0.228/src/version.cThu Apr 26 16:28:43 2007
--- src/version.c   Thu Apr 26 16:48:59 2007
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 229,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
20. When looking at a pageful of someone else's links, you notice all of them
are already highlighted in purple.

 /// 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///

patch 7.0.228

[Bram Moolenaar]

Patch 7.0.228
Problem:Cygwin: problem with symlink to DOS style path.
Solution:   Invoke cygwin_conv_to_posix_path(). (Luca Masini)
Files:  src/os_unix.c


*** ../vim-7.0.227/src/os_unix.cTue Mar  6 20:27:03 2007
--- src/os_unix.c   Mon Apr 23 22:27:16 2007
***
*** 55,60 
--- 55,66 
  # endif
  #endif
  
+ #ifdef __CYGWIN__
+ # ifndef WIN32
+ #  include  /* for cygwin_conv_to_posix_path() */
+ # endif
+ #endif
+ 
  #if defined(HAVE_SELECT)
  extern int   select __ARGS((int, fd_set *, fd_set *, fd_set *, struct timeval 
*));
  #endif
***
*** 2228,2233 
--- 2258,2270 
  
  #ifdef VMS
  fname = vms_fixfilename(fname);
+ #endif
+ 
+ #ifdef __CYGWIN__
+ /*
+  * This helps for when "/etc/hosts" is a symlink to "c:/something/hosts".
+  */
+ cygwin_conv_to_posix_path(fname, fname);
  #endif
  
  /* expand it if forced or not an absolute path */
*** ../vim-7.0.227/src/version.cThu Apr 26 16:11:47 2007
--- src/version.c   Thu Apr 26 16:27:29 2007
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 228,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
19. All of your friends have an @ in their names.

 /// 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///

patch 7.0.227

[Bram Moolenaar]

Patch 7.0.227
Problem:Crash when closing a window in the GUI. (Charles Campbell)
Solution:   Don't call out_flush() from win_free().
Files:  src/window.c


*** ../vim-7.0.226/src/window.c Sun Mar 11 15:53:27 2007
--- src/window.cWed Apr 18 22:31:52 2007
***
*** 2084,2089 
--- 2084,2096 
  }
  #endif
  
+ #ifdef FEAT_GUI
+ /* Avoid trouble with scrollbars that are going to be deleted in
+  * win_free(). */
+ if (gui.in_use)
+   out_flush();
+ #endif
+ 
  /*
   * Close the link to the buffer.
   */
***
*** 4174,4180 
  #ifdef FEAT_GUI
  if (gui.in_use)
  {
-   out_flush();
gui_mch_destroy_scrollbar(&wp->w_scrollbars[SBAR_LEFT]);
gui_mch_destroy_scrollbar(&wp->w_scrollbars[SBAR_RIGHT]);
  }
--- 4181,4186 
*** ../vim-7.0.226/src/version.cThu Apr 26 11:01:16 2007
--- src/version.c   Thu Apr 26 16:09:30 2007
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 227,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
16. You step out of your room and realize that your parents have moved and
you don't have a clue when it happened.

 /// 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///

Re: Vim's ole functionality

[Sebastian Menge]

Am Mittwoch, den 25.04.2007, 23:30 +0530 schrieb Nageshwar:
> I am sending you the code that I wrote to start a ole window.The

Thanks, I get the same error. Perhaps this Mail from eclipse helps:

http://dev.eclipse.org/newslists/news.eclipse.tools/msg37640.html

Sebastian.

patch 7.0.226

[Bram Moolenaar]

Patch 7.0.226
Problem:Display flickering when updating signs through the netbeans
interface. (Xavier de Gaye)
Solution:   Remove the redraw_later(CLEAR) call.
Files:  src/netbeans.c


*** ../vim-7.0.225/src/netbeans.c   Tue Nov 14 18:29:00 2006
--- src/netbeans.c  Sat Apr 21 18:14:00 2007
***
*** 2143,2150 
coloncmd(":sign jump %d buffer=%d", serNum,
   buf->bufp->b_fnum);
}
-   /* XXX only redraw what changed. */
-   redraw_later(CLEAR);
  #endif
  /* =*/
}
--- 2143,2148 
*** ../vim-7.0.225/src/version.cThu Apr 26 10:55:46 2007
--- src/version.c   Thu Apr 26 11:00:01 2007
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 226,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
site address in print or on TV, even though you've never had heart
problems before.

 /// 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///

patch 7.0.225

[Bram Moolenaar]

Patch 7.0.225
Problem:When using setline() in an InsertEnter autocommand and doing "A"
the cursor ends up on the last byte in the line. (Yukihiro
Nakadaira)
Solution:   Only adjust the column when using setline() for the cursor line.
Move it back to the head byte if necessary.
Files:  src/eval.c, src/misc2.c


*** ../vim-7.0.224/src/eval.c   Tue Mar 27 16:57:54 2007
--- src/eval.c  Thu Apr 26 10:52:09 2007
***
*** 14397,14403 
if (u_savesub(lnum) == OK && ml_replace(lnum, line, TRUE) == OK)
{
changed_bytes(lnum, 0);
!   check_cursor_col();
rettv->vval.v_number = 0;   /* OK */
}
}
--- 14411,14418 
if (u_savesub(lnum) == OK && ml_replace(lnum, line, TRUE) == OK)
{
changed_bytes(lnum, 0);
!   if (lnum == curwin->w_cursor.lnum)
!   check_cursor_col();
rettv->vval.v_number = 0;   /* OK */
}
}
*** ../vim-7.0.224/src/misc2.c  Tue Feb 20 03:18:20 2007
--- src/misc2.c Tue Mar 27 21:59:56 2007
***
*** 516,522 
--- 516,529 
|| virtual_active())
curwin->w_cursor.col = len;
else
+   {
curwin->w_cursor.col = len - 1;
+ #ifdef FEAT_MBYTE
+   /* prevent cursor from moving on the trail byte */
+   if (has_mbyte)
+   mb_adjust_cursor();
+ #endif
+   }
  }
  
  #ifdef FEAT_VIRTUALEDIT
*** ../vim-7.0.224/src/version.cTue Mar 27 16:57:54 2007
--- src/version.c   Thu Apr 26 10:53:33 2007
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 225,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
14. You start introducing yourself as "Jim at I-I-Net dot net dot au"

 /// 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///

Re: [PATCH] Determining whether a window used :lcd

[Nikolai Weibull]

On 4/25/07, Bob Hiestand <[EMAIL PROTECTED]> wrote:


On 4/25/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:



> OK, I guess then I don't understand your todo entry and Yakov's need for it.

I should clarify, it is my need, and I have no idea who added the
todo.  I found it while trying to discern if the functionality I
needed was provided already.


Ah, Yakov was only suggesting a way of doing it.

I realize you didn't add it, I'm just using "your" here to separate it
from "mine", that is, the one I suggested could be used for your need.


> Either way, wouldn't it be more useful to alter getcwd() to take an
> optional argument stating whether we want the local or global cwd?



The problem is that my plugin needs to change the current working
directory, perform an action, and then restore the previous working
directory.  I need to know whether to use :lcd or :cd to do that.  If
I use :cd in a window that had previously used :lcd, then I clobbered
the :lcd usage and that window is now stuck to the global directory;
additionally, the global directory is changed to whatever the prior
value.  If I instead use :lcd always, and the window wasn't previously
using a local directory, it now is.


let saved_cwd = getcwd('local')
let cd_cmd = (saved_cwd != getcwd('global')) ? 'lcd' : 'cd'
exec cd_cmd '…'
⋮
exec cd_cmd saved_cwd

(assuming getcwd('local') returns the local directory, if there is
one, or whatever getcwd('global') would, if not.)

 nikolai