Hi,

After starting vim with vim -u NONE I get a core dump by
   :call input("foo")

Input and call functions seem to work properly if I use them in sensible
contexts, e.g.
   :let myvar = input("foo")
is ok.

This happens only with version 6.0w, at least 6.0v is ok.
I run vim in HP-UX 10.20 - I compiled vim with c89 and gcc, and vim crashed
in both cases.

Best regards,
Sami Salonen

P.S Here is the output of :version (from version compiled with gcc)

VIM - Vi IMproved 6.0w ALPHA (2001 Feb 24, compiled Mar  1 2001 10:11:32)
Compiled by samsalon@ouh36
Normal version with X11-Motif GUI.  Features included (+) or not (-):
+autocmd -balloon_eval +browse +builtin_terms +byte_offset -cde_colors
+cindent
+cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv -cscope
+dialog_con_gui +digraphs -ebcdic -emacs_tags +eval +ex_extra +extra_search
-farsi +file_in_path -osfiletype +find_in_path +folding -footer +fork()
-gettext -hangul_input +insert_expand -keymap -langmap +libcall +linebreak
+lispindent +listcmds +localmap -keymap +menu +mksession +modify_fname
+mouse
+mouseshape -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm +mouse_xterm
-multi_byte +multi_lang +path_extra -perl -python +quickfix -rightleft -ruby
+scrollbind -signs +smartindent -sniff +statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse
+textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual
+visualextra +viminfo +wildignore +wildmenu +windows +writebackup +X11
+xfontset +xim +xterm_clipboard -xterm_save
    system vimrc file: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
       user exrc file: "$HOME/.exrc"
   system gvimrc file: "$VIM/gvimrc"
     user gvimrc file: "$HOME/.gvimrc"
     system menu file: "$VIMRUNTIME/menu.vim"
   fall-back for $VIM: "/disks/ouusers0/samsalon/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF
-I/usr/dt/incl
ude   -O -Wall -I/usr/include/X11R5
Linking: gcc -L/usr/dt/lib -L/usr/lib/X11R5  -L/usr/local/lib -o vim  -lXext
-lX
m -lXp -lXt -lX11 -ltermlib

See the previous post on this:

Date: Mon, 26 Feb 2001 11:30:28 -0800 (PST)
From: Lonny Cordell <lcordell@...>
Subject: Re: WIN32 console build broken


In summary, you need to add -DWIN32 to the makefile.

(or build on NT4, where it works anyway by magic :)

--
Vince Negri (vnegri@...)
Application Solutions Ltd. Tel:+44(0)1273-476608 Fax:+44(0)1273-478888

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.

But Iam building on NT4 , doesn't that contradict u'r
statement in braces.
thanks
vipin
----- Original Message -----
From: Vince Negri <vnegri@...>
To: 'vipin aravind' <vipin.aravind@...>
Cc: VIM Mailing list <vim-dev@...>
Sent: Thursday, March 01, 2001 2:21 PM
Subject: RE: broken build


> See the previous post on this:
>
> Date: Mon, 26 Feb 2001 11:30:28 -0800 (PST)
> From: Lonny Cordell <lcordell@...>
> Subject: Re: WIN32 console build broken
>
>
> In summary, you need to add -DWIN32 to the makefile.
>
> (or build on NT4, where it works anyway by magic :)
>
> --
> Vince Negri (vnegri@...)
> Application Solutions Ltd. Tel:+44(0)1273-476608 Fax:+44(0)1273-478888
>
> 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.
>
>

> But Iam building on NT4 , doesn't that contradict u'r
> statement in braces.

Strange... Vim built fine for me without having to define
WIN32 in the makefile - I have no idea why it works on my
machine in that case, by rights it shouldn't.... I'm
using VC++6 with service pack 4.

--
Vince Negri (vnegri@...)
Application Solutions Ltd. Tel:+44(0)1273-476608 Fax:+44(0)1273-478888
> -
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.

[6.0v]

   If the error message from a line out of :make is such that it *exactly*
fills the statusbar upon :cc, it still adds the '...' abbreviation - but
because it /is/ the right length, repeated ':cc's never give the whole
text, IYSWIM.

   E.g.,

:cc
(7 of 21): too few argument...o function `clip_own_selection'
398,6-13      15%

                            ^^^ == "s t"

   Normally, a second :cc after an abbreviated line such as this would
given the long text. But the long text is the same length, & so again gets
abbreviated.

--
=====================- http://www.thalesgroup.com/ -=====================
   Neil Bird   Principal Engineer                     |
        work - mailto:neil.bird@...    |    $> cd /pub
    personal - mailto:neil@...                 |    $> more beer

I've noticed a bug using gvim 6.0w under windows.
You can reproduce it the following way.

start gvim with an empty window.

insert a few lines of text, select it
and hit zf to fold it. Then click with the mouse,
just below the fold (and off the text, in the ~'s area).

You should get lots of errors/Hit Return prompts.

	 Mark Brophy.

From: Mark Brophy [mailto:mbrophy@...]
> I've noticed a bug using gvim 6.0w under windows.
> You can reproduce it the following way.
>
> start gvim with an empty window.
>
> insert a few lines of text, select it
> and hit zf to fold it. Then click with the mouse,
> just below the fold (and off the text, in the ~'s area).
>
> You should get lots of errors/Hit Return prompts.


I can't reperoduce this (gvim 6.0w on Windows 2000, compiled myself with
MSVC). Can you be a little more specific in what you did?

Paul.

"Moore, Paul" wrote:
>
> From: Mark Brophy [mailto:mbrophy@...]
> > I've noticed a bug using gvim 6.0w under windows.
> > You can reproduce it the following way.
> >
> > start gvim with an empty window.
> >
> > insert a few lines of text, select it
> > and hit zf to fold it. Then click with the mouse,
> > just below the fold (and off the text, in the ~'s area).
> >
> > You should get lots of errors/Hit Return prompts.
>
> I can't reperoduce this (gvim 6.0w on Windows 2000, compiled myself with
> MSVC). Can you be a little more specific in what you did?
>
> Paul.

Ok, I just tried it without my vimrc, and it still
happens. I only have the standard plugins distributed with
6.0.

Start gvim.
itest<return>test<ESC>Vkzf

Now, click on any ~ line with the left mouse button.
You should get an error message (more messages the
further down you click), and the cursor will be where you
clicked (outside the text).

	 Mark Brophy


VIM - Vi IMproved 6.0w ALPHA (2001 Feb 24, compiled Feb 26 2001
09:08:36)
MS-Windows 16/32 bit GUI version
Big version with GUI.  Features included (+) or not (-):
+autocmd -balloon_eval +browse ++builtin_terms +byte_offset +cindent
+cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv -cscope
+dialog_gui +digraphs -ebcdic +emacs_tags +eval +ex_extra +extra_search
+farsi
+file_in_path -osfiletype +find_in_path +folding -footer -gettext
-hangul_input
+insert_expand +keymap +langmap +libcall +linebreak +lispindent
+listcmds
+localmap +keymap +menu +mksession +modify_fname +mouse +mouseshape
+multi_byte
+multi_lang -ole +path_extra +perl +python +quickfix +rightleft -ruby
+scrollbind -signs +smartindent -sniff +statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white -tcl -tgetent -termresponse
+textobjects +title +toolbar +user_commands +vertsplit +virtualedit
+visual
+visualextra +viminfo +wildignore +wildmenu +windows +writebackup
-xfontset
-xim -xterm_save
    system vimrc file: "$VIM\vimrc"
      user vimrc file: "$HOME\_vimrc"
  2nd user vimrc file: "$VIM\_vimrc"
       user exrc file: "$HOME\_exrc"
   2nd user exrc file: "$VIM\_exrc"
   system gvimrc file: "$VIM\gvimrc"
     user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
     system menu file: "$VIMRUNTIME\menu.vim"

Hi,

I'm slowly moving over from 5.7 to 6.0? and have hit a slight
problem.  Using 'syntax on' resets the default highlight colors.  The
only way I have found so far to easily keep my higlighting colors is
to keep on using the mysyntaxfile variable.  However, the docs say it
is now only supported for backward compatability with 5.x.  So what
is the 6.0 way of overriding the default highlighting?

TTFN

Mike
--
Que sera, seesaw: What will be, will go up and down.

Benoit Cerrina wrote:

> there seems to be a bug in the way vim handles the %p^ errorformat,
> at least there is inconsistant behavior when using javac due to the compiler
> expanding tabs to spaces at the start of a line.
> this is my line of code:
> <TAB><TAB>java.lang.reflect.Method lMethod = _BEAN_CLASS_.getMethod(iName,
iParamTypes);
>
> this is the output of javac:
>
>
>
C:\dev\NewGen\src\com\dassault_systemes\NewGen\PersistAttributeNodeBeanInfo.java\
:57: cannot resolve
> symbol
> symbol  : variable iName
> location: class com.dassault_systemes.NewGen.PersistAttributeNodeBeanInfo
>                 java.lang.reflect.Method lMethod =
_BEAN_CLASS_.getMethod(iName, iParamTypes);
>
^
>
> notice that javac expands the tabs to 8 spaces, I have ts=4 and this leads
> to a differenctial of 8 in the column number and the %p^ incorrectly
> computes error line.
>
> possible correction would be to strip the leading tab and spaces for column
> computation.

Vim can't know how many spaces to strip.  I think the only solution is to work
with 'tabstop' set to 8.  Yet another reason to keep 'tabstop' at the standard
value of eight!

--
Q: What is the difference betwee open-source and commercial software?
A: If you have a problem with commercial software you can call a phone
    number and they will tell you it might be solved in a future version.
    For open-source sofware there isn't a phone number to call, but you
    get the solution within a day.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

horos wrote:

> well, that's a start, but I was looking for something a little more
> sophisticated. When you say, in perl:
>
> use FileHandle;
>
> perl looks through a variable called @INC to locate the module, and then
> tags '.pm' on the end of it. Hence, I'd want to be able to *program* the *f
> commands, and furthermore tie them to a given suffix (.pm, .pl, etc)

The 'suffixesadd' option helps a bit here.  But the file name must be valid
for this to work, not end in "*" or have "." for file name separator.

> ps -- this is also true for python and java, which do similar transforms...
> doing it really right would involve being able to handle 'import package.*'
> and split on multiple files.

This works for the commands that look for an included file with 'includeexpr'.
Using 'includeexpr' also for "gf" (when it doesn't work without modification)
would be a solution.

> pps -- for some reason, my posts aren't making it to the list from my other
> address (edwardp@...). Could someone check to see what's going on/
> if I am being accidentally dropped?

You can only send messages to the list from the address where you subscribed.
Unfortunately you don't get a warning now.  I have asked the maillist
maintainer to make it send a reply to you to let you know the message was
refused, but apparently this still doesn't work.

You could subscribe from the other address too, and then disable receiving
messages there (Send a message to the vim-dev-help@... address to find out
how).

--
hundred-and-one symptoms of being an internet addict:
28. You have comandeered your teenager's phone line for the net and even his
     friends know not to call on his line anymore.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Andrew Rodionoff wrote:

> [...]
> >>  I've also included new option 'metaesc', aimed to make GUI Vim send
> >> <esc>  before Meta-modified key, like xterm does. This one supposed to
> >> solve a  problem of entering Meta-modified 8bit chars.
>
> BM> There are a few problems with this:
> BM> - An extra option.  Would be better if meta keys work the same way always.
> BM> - Using <M-x> in mappings won't work when 'metaesc' is set.
>     I see your point. I guess the whole meta-key recognition can be rewritten
> to use <Esc> as a prefix. I know at least one editor that use similar
> approach, it's John Harper's Jade.

You can't use <Esc>-char when you want to insert the character with the 8th
bit set, like it's done now.  You don't want to insert the <Esc> anyway, thus
it would only be for mappings.

> BM> - Using an ESC causes trouble in Insert mode, it's not normally used for
> BM> special keys in the GUI.
>     It's a matter of setting 'esckeys' option. It can be force-set when
> 'metaesc' is being set.

I don't like side effects like this.  The GUI uses CSI to avoid this mixup of
the <Esc> key and special keys using <Esc>.  I want to keep it that way.
There already is a special code for prepending a modifier to a character, I
don't see why a new mechanism is needed.

> BM>  It's not clear what problem this option is trying to solve.
>     I guess I speak English like Two Conkers from Discworld Noir do :) It's
> apparently a problem of i18n. When one is typing 8-bit (I mean 8th bit on)
> text, he can't use Meta-combos to trigger macros. Meta-modified key and
> actual keysym just appear to be the same.

You mean that when you have a character for which the 8th bit is already set,
the META modifier can't be noticed?  Well, that should be solved by putting a
META modifer code before the character.  It's quite simple to change the code
for this.  I'm not sure if mappings with <M-x> (where x is a character with
the 8th bit set) work right away, please check that in the next version.

--
Give a man a computer program and you give him a headache,
but teach him to program computers and you give him the power
to create headaches for others for the rest of his life...
         R. B. Forest

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Ron Aaron wrote:

> My clean machine [Mandrake Linux 7.2, with the addition of 'libiconv' added],
> fails compiling 6.0w:
>
>  make distclean
>  ./configure
>  make
>
> The failure is that it seems to be unable to determine the size of an int (!):
>
> configure:5704: checking size of int
> configure:5723: gcc -o conftest -g -O2 -Wall  -I/usr/local/include 
-L/usr/local/lib conftest.c -lncurses -lelf  -liconv -lgpm 1>&5
> configure:5715: warning: return-type defaults to `int'
> configure: failed program was:
> #line 5712 "configure"
> #include "confdefs.h"
> #include <stdio.h>
> 	 main()
> 	 {
> 		  FILE *f=fopen("conftestval", "w");
> 		  if (!f) exit(1);
> 		  fprintf(f, "%d\n", (int)sizeof(int));
> 		  exit(0);
> 	 }
>
>
> Far be it from me to whine, but shouldn't inability to determine
> 'sizeof(int)' be a FATAL error that causes all the compilation to cease?

The problem is probably that linking failed.  Strange that there is no error
message.  Check the other lines in the config.log around this, I suspect other
tests that compile and link a program also failed.

> I mean, the current behavior of just setting it to '0' is ludicrous:
>  1) there is never an int size of zero
>  2) it makes it incredibly difficult to pinpoint the problem, since the
> 	   compile just 'goes on' even though there is something pretty wrong!
>  3) if we just blithely set SIZEOF_INT to something, wouldn't it make
> 	   somewhat more sense to choose '4' as the value, as that is what 98%
> 	   of the machines out there are using?

Using a default for SIZEOF_INT would just hide the problem.  And when you
would continue to compile Vim, you run into the check in vim.h, which clearly
explains what the problem is when SIZEOF_INT is zero.  Finding a solution is
a bit more difficult though...

> Anyway, I don't have any clue why this behaviour is occurring.  My laptop,
> also running Mandrake 7.2 (albeit with *tons* of patches and additions)
> compiles just fine.  Sometimes it is interesting to wipe a disk and start
> over...

I would suspect a problem with the libraries.  Although it's unclear to me why
a check would find a library and then later fail to link with it.  Perhaps a
problem with the ordering of -L arguments?

--
hundred-and-one symptoms of being an internet addict:
25. You believe nothing looks sexier than a man in boxer shorts illuminated
     only by a 17" inch svga monitor.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Robert Webb wrote:

> > Was there a WinEnd group in Vim 5.7?  I can't find it.
>
> Maybe it was from an even older version, but still worked for
> back-compatibility only.

Well, I did a grep in the 5.7 source directory and the runtime/syntax
directory and couldn't find it.  Spelling?  Or do you set the 'highlight'
option to refer to this group?

> > Perhaps we should use NonText for the "~" lines and 'showbreak', and
> > use SpecialKey for unprintable characters?
>
> Yeah, sounds good to me.

I'll make it like that then.

> > >     - I would have expected the vertical split bar to be in the
> > >     same colour as the horizontal split bar, using the StatusLine
> > >     group.  Would this be possible?  Or maybe to have its own
> > >     highlight group?  I couldn't find one in the docs.
> >
> > There is the FillColumn group for this.
>
> Ah, right you are!  The name didn't leap out at me when browsing the
> help.  How about calling it "VertSplit" instead?

I don't remember where that name came from.  Nothing else is called "Fill".
If nobody objects, I'll rename it to "VertSplit".

> And I don't suppose it can inherit from StatusLineNC when not set?

That would be a new mechanism.  And there always is the default setting, which
is equal to StatusLineNC.

> Hmm, I guess it doesn't worry me too much, but I imagine it seeming
> strange to a new user.  You might have a window one column wide just
> to get it out of the way temporarily, and use ^W^W to travel between
> windows, passing through the thin window on the way to the one you
> want to get to.  In this case the thin window would get wider when you
> don't expect it to, or want it to.

It's also not very nice to put the cursor in a window and having to resize it
manually to be able to read the text.  This is one of those things where you
want the automatic behavior sometimes but not always.  I think the default is
OK.  If you are working with narrow vertical windows you can set 'winwidth' to
get the behavior you want.

> Doesn't seem like it should be too hard, since the windows must
> already be in a tree structure, and I assume this is used when finding
> which window the mouse was in.  Of course, this is a stupid thing to
> say not having looked at the code :-)

It's indeed a tree structure, thus it requires searching up in the tree to
find out if the statusline continues to the right.  This isn't easy, but since
it was solved for redrawing the statusline, the rest shouldn't be too
difficult.

> Hmm, pity (although I didn't know about ":ta /" which is great!).
> Another place where this is a shame is when using K.  I was editing
> my _vimrc and put the cursor on "winwidth" as in "set winwidth=1" and
> hit K.  It went to help for "winwidth()" instead of "'winwidth'", and
> it seems there's no easy way to move to the next best match.

I can understand that doing ":tn" to find other matching help tags would be
nice.  The problem is that the way it currently works doesn't keep the list of
matching tags but selects one and jumps to that.  It's not a simple change to
make this work.

> > >     - The Edit menu has the usual Cut, Copy and Paste, but then it
> > >     has Put Before and Put After, which use vim's yank buffer
> > >     rather than the clipboard like the previous commands.  Maybe
> > >     we should also have Paste Before and Paste After to avoid
> > >     confusion?
> >
> > What does Paste normally do?  I guess it puts the text before the
> > cursor (at least in Insert mode).  Perhaps we should make it
> > "Paste", "Paste after", "put" and "put after"?
>
> The difference is that the "Before" and "After" commands use "[p" and
> "]p" which also indents the pasted text to line up with surrounding
> text.  Don't know whether we need a whole set of all combinations, but
> I would like to see Paste Before and Paste After.

I've seen programs that have a "Paste" entry and then a "Paste special"
submenu with several ways of pasting.  However, I don't know if someone using
the menus will understand the different kinds of pasting.  Would be difficult
to make a short name to explain what it does.

--
hundred-and-one symptoms of being an internet addict:
31. You code your homework in HTML and give your instructor the URL.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

From: Mark Brophy [mailto:mbrophy@...]
> "Moore, Paul" wrote:
> >
> > From: Mark Brophy [mailto:mbrophy@...]
> > > I've noticed a bug using gvim 6.0w under windows.
> > > You can reproduce it the following way.
> > >
> > > start gvim with an empty window.
> > >
> > > insert a few lines of text, select it
> > > and hit zf to fold it. Then click with the mouse,
> > > just below the fold (and off the text, in the ~'s area).
> > >
> > > You should get lots of errors/Hit Return prompts.
> >
> > I can't reperoduce this (gvim 6.0w on Windows 2000,
> compiled myself with
> > MSVC). Can you be a little more specific in what you did?
> >
> > Paul.
>
> Ok, I just tried it without my vimrc, and it still
> happens. I only have the standard plugins distributed with
> 6.0.
>
> Start gvim.
> itest<return>test<ESC>Vkzf
>
> Now, click on any ~ line with the left mouse button.
> You should get an error message (more messages the
> further down you click), and the cursor will be where you
> clicked (outside the text).

Right. I get it now, with gvim -u NONE. I don't get it with my vimrc.

Trimming it down, it's the nowrap option.

gvim -u NONE -U NONE gives the problem
gvim -u NONE -U NONE -c "set nowrap" does not.

Not that I know how to fix it, of course...

Paul.

----- Original Message -----
From: "Vince Negri" <vnegri@...>
To: "'vipin aravind'" <vipin.aravind@...>
Cc: "VIM Mailing list" <vim-dev@...>
Sent: Thursday, March 01, 2001 4:26 AM
Subject: RE: broken build


> > But Iam building on NT4 , doesn't that contradict u'r
> > statement in braces.
>
> Strange... Vim built fine for me without having to define
> WIN32 in the makefile - I have no idea why it works on my
> machine in that case, by rights it shouldn't.... I'm
> using VC++6 with service pack 4.

It also built fine for me on Win2K without having to modify any files.  WIN32
does get defined for me.  This is because in Make_mvc.mak, CFLAGS is initialized
to include $(CVARS).  Just a bit earlier, CVARS was set to either $(cvars), or
$(cvarsmt) for multithreaded, or $(cvarsd) whenever DEBUG is defined.  It gets
these from win32.mak which is !included.  The problem is that $(cvarsd) does not
exist, at least in my win32.mak (VC++ 6, SP4).  Vipin is trying to compile the
debug version.

There is a similar problem with CON_LIB.  When compiling the debug version, it
gets set to $(conlibsd) or $(conlibsdlld).  On my system, neither of these exist
in win32.mak.

Attached is a new Make_mvc.mak that I've tested using debug/non-debug and
GUI/console (a total of four combinations).  Below are the diffs.

C:\Vim\latest\src>diff Make_mvc.mak.orig Make_mvc.mak
120c120,122
< !ifdef MULTITHREADED
---
> !if defined(USE_MSVCRT)
> CVARS = $(cvarsdll)
> !elseif defined(MULTITHREADED)
122,126d123
< ! ifndef USE_MSVCRT
< CON_LIB = $(conlibsmt)
< ! else
< CON_LIB = $(conlibsdll)
< ! endif
128d124
< !ifdef NODEBUG
130,142d125
< ! ifndef USE_MSVCRT
< CON_LIB = $(conlibs)
< ! else
< CON_LIB = $(conlibsdll)
< ! endif
< !else
< CVARS= $(cvarsd)
< ! ifndef USE_MSVCRT
< CON_LIB = $(conlibsd)
< ! else
< CON_LIB = $(conlibsdlld)
< ! endif
< !endif
144a128
> # need advapi32.lib for GetUserName()
146c130
< CON_LIB = $(CON_LIB) shell32.lib
---
> CON_LIB = advapi32.lib shell32.lib
380c364
< LINKARGS1 = $(linkdebug) $(conflags)
---
> LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc

I ran vcvars32, am using vc++6.00 and WINDOWSNT4.0 (service pack 6.0)
vipin
----- Original Message -----
From: Vince Negri <vnegri@...>
To: 'vipin aravind' <vipin.aravind@...>
Cc: VIM Mailing list <vim-dev@...>
Sent: Thursday, March 01, 2001 2:56 PM
Subject: RE: broken build


> > But Iam building on NT4 , doesn't that contradict u'r
> > statement in braces.
>
> Strange... Vim built fine for me without having to define
> WIN32 in the makefile - I have no idea why it works on my
> machine in that case, by rights it shouldn't.... I'm
> using VC++6 with service pack 4.
>
> --
> Vince Negri (vnegri@...)
> Application Solutions Ltd. Tel:+44(0)1273-476608 Fax:+44(0)1273-478888
> > -
> 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.
>
>

craig,
U found out correctly, its debug build, I had put on the mailing list
to get an answer and nobody did, but u gave it  correctly,
I was able to hardcode the -DWIN32 and was able to get thru the compilation
stage  couple of hrs  ago, u'r mail came a  bit late.
I had put it on the mailing list so that I don't had to go thru the mailing
list
But linking is failing

LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs;
use
/NODEFAULTLIB:library
edit.obj : error LNK2001: unresolved external symbol _vim_strnicmp
ex_getln.obj : error LNK2001: unresolved external symbol _hkmap
normal.obj : error LNK2001: unresolved external symbol _hkmap
option.obj : error LNK2001: unresolved external symbol _buflist_slash_adjust
os_win32.obj : error LNK2001: unresolved external symbol
__imp__GetUserNameA@8
vimd.exe : fatal error LNK1120: 4 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.

The above problems answer is there in u'r mail.
I WISH THIS REPORT   BY CRAIG SHOULD BE TAKEN AS A PATCH FOR  MAKEFILES.
thanks
vipin

----- Original Message -----
From: Craig Barkhouse <craig@...>
To: VIM Developers <vim-dev@...>
Sent: Thursday, March 01, 2001 7:20 PM
Subject: Re: broken build



----- Original Message -----
From: "Vince Negri" <vnegri@...>
To: "'vipin aravind'" <vipin.aravind@...>
Cc: "VIM Mailing list" <vim-dev@...>
Sent: Thursday, March 01, 2001 4:26 AM
Subject: RE: broken build


> > But Iam building on NT4 , doesn't that contradict u'r
> > statement in braces.
>
> Strange... Vim built fine for me without having to define
> WIN32 in the makefile - I have no idea why it works on my
> machine in that case, by rights it shouldn't.... I'm
> using VC++6 with service pack 4.

It also built fine for me on Win2K without having to modify any files.
WIN32 does get defined for me.  This is because in Make_mvc.mak, CFLAGS is
initialized to include $(CVARS).  Just a bit earlier, CVARS was set to
either $(cvars), or $(cvarsmt) for multithreaded, or $(cvarsd) whenever
DEBUG is defined.  It gets these from win32.mak which is !included.  The
problem is that $(cvarsd) does not exist, at least in my win32.mak (VC++ 6,
SP4).  Vipin is trying to compile the debug version.

There is a similar problem with CON_LIB.  When compiling the debug version,
it gets set to $(conlibsd) or $(conlibsdlld).  On my system, neither of
these exist in win32.mak.

Attached is a new Make_mvc.mak that I've tested using debug/non-debug and
GUI/console (a total of four combinations).  Below are the diffs.

C:\Vim\latest\src>diff Make_mvc.mak.orig Make_mvc.mak
120c120,122
< !ifdef MULTITHREADED
---
> !if defined(USE_MSVCRT)
> CVARS = $(cvarsdll)
> !elseif defined(MULTITHREADED)
122,126d123
< ! ifndef USE_MSVCRT
< CON_LIB = $(conlibsmt)
< ! else
< CON_LIB = $(conlibsdll)
< ! endif
128d124
< !ifdef NODEBUG
130,142d125
< ! ifndef USE_MSVCRT
< CON_LIB = $(conlibs)
< ! else
< CON_LIB = $(conlibsdll)
< ! endif
< !else
< CVARS= $(cvarsd)
< ! ifndef USE_MSVCRT
< CON_LIB = $(conlibsd)
< ! else
< CON_LIB = $(conlibsdlld)
< ! endif
< !endif
144a128
> # need advapi32.lib for GetUserName()
146c130
< CON_LIB = $(CON_LIB) shell32.lib
---
> CON_LIB = advapi32.lib shell32.lib
380c364
< LINKARGS1 = $(linkdebug) $(conflags)
---
> LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc

----- Original Message -----

From: vipin aravind

To: VIM Mailing list

Sent: Wednesday, February 28, 2001 9:18 PM

Subject: build success for win32 debug

add a line in the makefile_mvc.mak

 

 

for misc2.obj   and its done

 

 

thanks                                                                                                 vipin

 

----- Original Message -----

From: Craig Barkhouse

To: VIM Mailing list

Sent: Thursday, March 01, 2001 8:02 PM

Subject: Re: build success for win32 debug

You message is a bit vague.  :)  I didn't have to add anything to the version of Make_mvc.mak that I posted.  What did you have to add, and where?

 

----- Original Message -----

From: vipin aravind

To: VIM Mailing list

Sent: Wednesday, February 28, 2001 9:18 PM

Subject: build success for win32 debug

add a line in the makefile_mvc.mak

 

 

for misc2.obj   and its done

 

 

thanks                                                                                                 vipin

 

sami.j.salonen@... wrote:
>
> Hi,
>
> After starting vim with vim -u NONE I get a core dump by
>   :call input("foo")
>
> Input and call functions seem to work properly if I use them in sensible
> contexts, e.g.
>   :let myvar = input("foo")
> is ok.
>
> This happens only with version 6.0w, at least 6.0v is ok.
> I run vim in HP-UX 10.20 - I compiled vim with c89 and gcc, and vim crashed
> in both cases.
>
> Best regards,
> Sami Salonen
>
> P.S Here is the output of :version (from version compiled with gcc)
[snip]

      I think this bug was already reported, and a patch posted.  I think
the problem crept in when input() was changed to allow a default.  Check
the archives of this mailing list.

HTH 			 --Benji Fisher

I'm aware that beginning in vim60w, "set tags" can be unique for
each buffer.  But knowing this, I'm unsure if the following is
suppose to work.  I first noticed the situation starting in
vim60w.

----- My reduced .vimrc file -----
set nocompatible
set &tags="/home/pkippes/tags/tags-bw65"
----------------------------------

In vim60w, tagging to a tag within the current file is fine.
But once I tag outside the current file, my "set tags?" becomes
"tags=./tags,tags".

Also, if I start vim with line #2 of the above .vimrc file
removed and then "set tags=/home/pkippes/tags/tags-bw65" things
work as before vim60w.  (I.e. tagging to outside the current
file does not modify the tags setting.)

Is this the new behavior?  Also, how does one modify
local/global settings?

Thanks


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

Mike Williams wrote:

> I'm slowly moving over from 5.7 to 6.0? and have hit a slight
> problem.  Using 'syntax on' resets the default highlight colors.  The
> only way I have found so far to easily keep my higlighting colors is
> to keep on using the mysyntaxfile variable.  However, the docs say it
> is now only supported for backward compatability with 5.x.  So what
> is the 6.0 way of overriding the default highlighting?

Sorry, I forgot to change the highlight commands that define the default
colors to skip this when a color is already defined.  I'll do that now.

Note that there is one side effect:  Previously you could do this to reset the
colors to their default:

	 :syntax off
	 :syntax on

Since the new way is to keep colors that are already defined that won't work
anymore.  Does this matter?  Perhaps this will be fixed by implementing the
todo item for color schemes.

--
A day without sunshine is like, well, night.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Craig Barkhouse wrote:

> It also built fine for me on Win2K without having to modify any files.
> WIN32 does get defined for me.  This is because in Make_mvc.mak, CFLAGS is
> initialized to include $(CVARS).  Just a bit earlier, CVARS was set to
> either $(cvars), or $(cvarsmt) for multithreaded, or $(cvarsd) whenever
> DEBUG is defined.  It gets these from win32.mak which is !included.  The
> problem is that $(cvarsd) does not exist, at least in my win32.mak (VC++ 6,
> SP4).  Vipin is trying to compile the debug version.
>
> There is a similar problem with CON_LIB.  When compiling the debug version,
> it gets set to $(conlibsd) or $(conlibsdlld).  On my system, neither of
> these exist in win32.mak.
>
> Attached is a new Make_mvc.mak that I've tested using debug/non-debug and
> GUI/console (a total of four combinations).  Below are the diffs.

Looks OK to me.  I'll include this, unless someone has a problem with that.

--
hundred-and-one symptoms of being an internet addict:
34. You laugh at people with 14400 baud modems.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Neil Bird wrote:

>   [6.0v]
>
>   If the error message from a line out of :make is such that it *exactly*
> fills the statusbar upon :cc, it still adds the '...' abbreviation - but
> because it /is/ the right length, repeated ':cc's never give the whole
> text, IYSWIM.
>
>   E.g.,
>
> :cc
> (7 of 21): too few argument...o function `clip_own_selection'
> 398,6-13      15%
>
>                            ^^^ == "s t"
>
>   Normally, a second :cc after an abbreviated line such as this would
> given the long text. But the long text is the same length, & so again gets
> abbreviated.

I see the problem.  It's an off-by-one error.  It would also be wrong when
"uhex" is used in 'display'.  This patch should fix both:

*** ../dist/vim60w/src/message.c Sat Feb 24 15:28:36 2001
--- message.c Thu Mar  1 16:00:14 2001
***************
*** 216,225 ****
  		 else
   #endif
  		 {
! 		    for (i = STRLEN(s) - 1; len < room; --i)
! 		 len += ptr2cells(s + i);
! 		    if (len > room)
! 		 ++i;
  		 }
  		 STRCAT(buf, s + i);
  	     }
--- 219,227 ----
  		 else
   #endif
  		 {
! 		    for (i = STRLEN(s); len + (n = ptr2cells(s + i - 1)) <= room;
! 									  --i)
! 		 len += n;
  		 }
  		 STRCAT(buf, s + i);
  	     }
--
hundred-and-one symptoms of being an internet addict:
35. Your husband tells you he's had the beard for 2 months.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Mark Brophy wrote:

> I've noticed a bug using gvim 6.0w under windows.
> You can reproduce it the following way.
>
> start gvim with an empty window.
>
> insert a few lines of text, select it
> and hit zf to fold it. Then click with the mouse,
> just below the fold (and off the text, in the ~'s area).
>
> You should get lots of errors/Hit Return prompts.

I see it on Unix too.  This patch should fix it:

*** ui.c.orig Fri Feb 23 22:50:24 2001
--- ui.c Thu Mar  1 16:25:04 2001
***************
*** 2041,2047 ****
  		     break;
  		 first = FALSE;
   #ifdef FEAT_FOLDING
! 	 hasFolding(curwin->w_topline, NULL, &curwin->w_topline);
   #endif
  	     }
  	     redraw_later(VALID);
--- 2041,2049 ----
  		     break;
  		 first = FALSE;
   #ifdef FEAT_FOLDING
! 	 if (hasFolding(curwin->w_topline, NULL, &curwin->w_topline)
! 		 && curwin->w_topline == curbuf->b_ml.ml_line_count)
! 		    break;
   #endif
  	     }
  	     redraw_later(VALID);
***************
*** 2163,2177 ****
  		 col += curwin->w_skipcol;
  		 break;
  	     }
  	     if (lnum == curbuf->b_ml.ml_line_count)
  	     {
  		 retval = TRUE;
  		 break;  /* past end of file */
  	     }
  	     row -= count;
- #ifdef FEAT_FOLDING
- 	    (void)hasFolding(lnum, NULL, &lnum);
- #endif
  	     ++lnum;
  	 }
       }
--- 2165,2179 ----
  		 col += curwin->w_skipcol;
  		 break;
  	     }
+ #ifdef FEAT_FOLDING
+ 	    (void)hasFolding(lnum, NULL, &lnum);
+ #endif
  	     if (lnum == curbuf->b_ml.ml_line_count)
  	     {
  		 retval = TRUE;
  		 break;  /* past end of file */
  	     }
  	     row -= count;
  	     ++lnum;
  	 }
       }

--
hundred-and-one symptoms of being an internet addict:
37. You start looking for hot HTML addresses in public restrooms.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Paul Kippes spake saying:
> I'm aware that beginning in vim60w, "set tags" can be unique for
> each buffer.  But knowing this, I'm unsure if the following is
> suppose to work.  I first noticed the situation starting in
> vim60w.
>
> ----- My reduced .vimrc file -----
> set nocompatible
> set &tags="/home/pkippes/tags/tags-bw65"
> ----------------------------------
I could be wrong, but I thing you want to:
set &tags
set tags+=/home/pkippes/tags/tags-bw65

You want to make sure that tags are first set to the default setting,
and then add your tags file location to it.  Is this your intent?
Because your line above, doesn't even work for me.  It gives an error:
Unknown option: &tags=

Or perhaps you meant let &tags=...
>
> In vim60w, tagging to a tag within the current file is fine.
> But once I tag outside the current file, my "set tags?" becomes
> "tags=./tags,tags".
>
> Also, if I start vim with line #2 of the above .vimrc file
> removed and then "set tags=/home/pkippes/tags/tags-bw65" things
> work as before vim60w.  (I.e. tagging to outside the current
> file does not modify the tags setting.)
>
> Is this the new behavior?  Also, how does one modify
> local/global settings?
:h local-options
:h global-local

HTH,
-Doug

--
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Douglas L. Potts Spectral Systems, Inc. http://www.bigfoot.com/~pottsdl
"But you can't expect to wield supreme executive power just 'cause some
watery tart threw a sword at you!"
-Dennis, "Monty Python and the Holy Grail"
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*