Re: doc nitpicking
On Oct 12, 9:31 pm, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > The docs are correct, ":silent !true" doesn't mess up the display for > > > me. > > > > Check your shell init scripts for something that produces output. > ... > > Apparently your termcap settings are causing this. Try this: > :set t_ti= t_ks= > > But then something else might break... > > It might have something to do with the colorscheme you are using, esp. > if you are using a non-default background color. > I am curious, because it was always like this for me : 'silent! cmd' clears the screen (debian + xterm) and forces a redraw. I tried all you mentioned ( default colors, xterm with white bg, no output from loginscripts checked, setting the t_ opts ) ,but it does not change it. -ap --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Integration of Vim
Yeh that is true, It was my first preference because it's an editor that I like, but the overall complexity of integrating it suggest that it'll probably best to start looking at alternatives. I'm still hopeful that the client-server design will work as expected. Cheers -Wynand --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
use of uninitialized memory when diffing 3 files
Hi, Valgrind memory checker finds use of uninitialized memory in vim7/src/diff.c when diffing 3 files or more. I don't see such errors when diffing 2 files only. I can reproduce the problem by diffing 3 vim source files for example: $ cd vim7/src $ valgrind ./vim -u NONE -U NONE -d syntax.c spell.c screen.c 2> vg.log (admittedly it does not make much sense to diff those 3 files but it shows the bug) ==24682== Conditional jump or move depends on uninitialised value(s) ==24682==at 0x805964D: diff_infold (diff.c:1964) ==24682==by 0x80C644A: foldlevelDiff (fold.c:2991) ==24682==by 0x80C5100: foldUpdateIEMS (fold.c:2294) ==24682==by 0x80C30C5: foldUpdate (fold.c:861) ==24682==by 0x80C3838: checkupdate (fold.c:1226) ==24682==by 0x80C220D: hasFoldingWin (fold.c:164) ==24682==by 0x8058EB8: diff_set_topline (diff.c:1705) ==24682==by 0x8115178: check_scrollbind (normal.c:3975) ==24682==by 0x80D7939: main (main.c:903) ==24682== ==24682== Conditional jump or move depends on uninitialised value(s) ==24682==at 0x805964D: diff_infold (diff.c:1964) ==24682==by 0x80C644A: foldlevelDiff (fold.c:2991) ==24682==by 0x80C59D7: foldUpdateIEMSRecurse (fold.c:2644) ==24682==by 0x80C50CD: foldUpdateIEMS (fold.c:2284) ==24682==by 0x80C30C5: foldUpdate (fold.c:861) ==24682==by 0x80C3838: checkupdate (fold.c:1226) ==24682==by 0x80C220D: hasFoldingWin (fold.c:164) ==24682==by 0x8058EB8: diff_set_topline (diff.c:1705) ==24682==by 0x8115178: check_scrollbind (normal.c:3975) ==24682==by 0x80D7939: main (main.c:903) (etc, more errors) When pressing "Pg-down" to scroll down, valgrind reports more errors in diff.c as well as in fold.c but they may possibly all have the same root cause). The first reported error is in src/diff.c at line 1964: 1961 if (dp->df_lnum[idx] - diff_context > lnum) 1962 break; 1963 /* If this change ends before the line we have a match. */ !!1964 if (dp->df_lnum[idx] + dp->df_count[idx] + diff_context > lnum) 1965 return FALSE; As a result, I believe function diff_infold(...) may return TRUE or FALSE at random. Line 1964 uses several variables so any of them could be the uninitialized one. However, variables dp->df_lnum[idx], diff_context and lnum have been used in a test at line 1961 without error. So the only variable that must be uninitialized at line 1964 has to be dp->df_count[idx]. So I've added some printf(...) to see whether df_count[...] was initialized earlier with something uninitialized. I can see that dp->df_count[i] is set with something uninitialized in diff.c at line 1315 (before valgrind error is reported at line 1964): 1313 for (i = idx_orig; i < idx_new + !notset; ++i) 1314 if (curtab->tp_diffbuf[i] != NULL) 1315 dp->df_count[i] = dpl->df_lnum[i] + dpl->df_count[i] 1316 - dp->df_lnum[i] + off; Adding printf() shows that variable dpl->df_count[i] (on the right) is uninitialized at line 1315, so left term dp->df_count[i] is also uninitialized as a result. When that happens i == 2, idx_new == 2 and notset is 0 (so !notset is 1). I have no patch, I could not find more than that yet. It's not clear to me how this should be initialized. I'm using vim-7.1.138 built on Linux with: - configure --with-features=huge - changed src/Makefile to compile without optimisation (-O0) - changed src/Makefile to enable PROFILE_CFLAGS = -DEXITFREE -- Dominique --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: the netbeans function 'remove' fails to remove a single line
On 10/13/07, Bram Moolenaar wrote: > Yeah, it appears it's currently only possible to delete characters > within a line or delete 2 lines or more. Quite strange. I wonder how > this ever worked with the actual Netbeans. > > I think we should change it to the proper solution: > 1. If less than one line, delete characters in one line > 2. otherwise: > a. Delete characters in the starting line (if not a whole line) > b. Delete whole lines (if at least one) > c. Delete characters in the ending line (if not a whole line) I am trying to do the following patch. What do you think ? = algorithm: next is position of first byte (if exists) after deleted section partial 1st line if: first->col != 0 or (next != NULL and first->lnum == next->lnum) partial last line if: first->lnum != last->lnum and next != NULL and last->lnum == next->lnum delete full lines: if partial 1st line: from = first + 1 else first if partial last line: to = last - 1 else last if to >= from: move cursor to from delete to:from remove all uses of netbeansSuppressNoLines: not needed fix incorrect use of pointer returned by ml_get to readonly data whenreplacing partial line remove wasChanged: seems to be not needed = Xavier --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: syntaxset error
Gary Johnson wrote:
> > > I just encountered this error message while trying to debug a
> > > problem with extracting vimballs. It's not related to
> > > vimballs--that's just how I happened to find it. I executed
> > >
> > >vim -V9verbose.out DrawIt.vba.gz
> > >
> > > and discovered this message among the others in the verbose.out log
> > > file:
> > >
> > >...
> > >continuing in /home/garyjohn/share/vim/vim71/syntax/manual.vim
> > >Error detected while processing
> > > /home/garyjohn/share/vim/vim71/syntax/manual.vim:
> > >line 20:
> > >E216: No such group or event: syntaxset FileType
> > >finished sourcing /home/garyjohn/share/vim/vim71/syntax/manual.vim
> > >...
> > >
> > > Here is that section of manual.vim, with line numbers enabled:
> > >
> > > 19 " Remove the connection between FileType and Syntax autocommands.
> > > 20 silent! au! syntaxset FileType
> > >
> > > Is this a bug or is this error expected under some conditions and
> > > hence the "silent!" command? If the latter, it would be nice if a
> > > comment to that effect could be added to syntax/manual.vim so that
> > > folks could know to ignore the message when it appears in their
> > > debug logs.
> > >
> > > I see this running vim 7.1.79 on Cygwin and 7.1.77 on SunOS 5.8.
> >
> > I would think this is normal: When doing :syntax manual twice there are
> > no syntaxset autocommands. That's why there is a ":silent!" before the
> > command. However, when I try to reproduce it by executing the command
> > directly I don't get this error. So somewhere the "syntaxset" augroup
> > must have been deleted.
>
> I haven't looked into the reasons for the syntaxset autocommands so
> I don't know if attempting to remove a non-existent syntaxset group
> at that point is normal or not. You seem to think it is and you
> must have thought it was when you wrote the script since you saw the
> need to suppress the error message with ":silent!".
>
> One concern I had about the error message was that I thought it
> indicated a bug in one or more vim scripts and that I should report
> it.
>
> My other concern about the message is that I found it while trying
> to troubleshoot another problem. I had no idea what was causing the
> problem and I was looking for any clue to the cause. I spent some
> time determining that that error message was not related to the
> problem at hand. I also spent some time reporting it since I
> thought it might indicate a real problem somewhere. I think it
> would help the process of troubleshooting if the vim code did not
> produce any error messages at all, expected or not, when operating
> normally. I think a better approach to inhibiting this particular
> error message would be the following:
>
>if exists("#syntaxset")
> au! syntaxset FileType
>endif
>
> I think the behavior is the same as the original code, but no
> distracting error message appears in the verbose output.
Right. This kind of exists() was added later.
It's indeed better to use this than silencing errors. But don't be
surprised if there are a few places where it happens anyway.
--
Far back in the mists of ancient time, in the great and glorious days of the
former Galactic Empire, life was wild, rich and largely tax free.
Mighty starships plied their way between exotic suns, seeking adventure and
reward among the furthest reaches of Galactic space. In those days, spirits
were brave, the stakes were high, men were real men, women were real women
and small furry creatures from Alpha Centauri were real small furry creatures
from Alpha Centauri. And all dared to brave unknown terrors, to do mighty
deeds, to boldly split infinitives that no man had split before -- and thus
was the Empire forged.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: the netbeans function 'remove' fails to remove a single line
Xavier de Gaye wrote:
> ===
> Description:
> ===
>
> a) The buffer number 3 contains the following three lines
> (the two first lines are 28 chars long, including the newline):
>
> 123456789012345678901234567
>t ={*} 1
> FIN
>
>
> b) Send the following netbeans functions
> (purpose: try to insert a 'u' line in front of the 't' line
> and replace the '*' by a '=' in the 't' line):
>
> 3:remove/91 28 28
> 3:insert/92 28 " u ={*} 1\n"
> 3:insert/93 56 " t ={=} 1\n"
>
>
> c) After completion of the functions, the buffer content is
> (note the '1' standing at first column on line 4):
>
> 123456789012345678901234567
>u ={*} 1
>t ={=} 1
> 1 t ={*} 1
> FIN
>
>
> d) The vim log traces say:
>
> FUN 91: (3) remove 28 28
> FIRST POS: line 2, col 0
> LAST POS: line 2, col 27
> NEW LINE 2: 1 t ={*} 1
> REP 91:
> FUN 92: (3) insert
> REP 92:
> FUN 93: (3) insert
> REP 93:
>
> ===
>
> I think the problem is that the remove function does not handle the case
> where the 'FIRST POS' and 'LAST POS' include the whole line that must be
> removed entirely. It tries to do a ml_replace() in all the cases where
> 'FIRST POS' and 'LAST POS' are on the same line.
>
> The workaround used currently by clewn is to insert a newline just
> before the line to remove, and to remove the two lines in one shot.
>
> The following patch fixes this problem. However it is not complete as it
> does not handle the case where the section to delete is muli-lines and
> starts with a partial line. The original code does not handle this case
> either.
>
>
> ===
> 1373a1374
> > linenr_T lnum_of_next;
> 1425a1427,1433
> > /* get the position of the next character after the deleted
> > section */
> > pos = off2pos(buf->bufp, off + count);
> > if (!pos)
> > lnum_of_next = last.lnum;
> > else
> > lnum_of_next = pos->lnum;
> >
> 1427c1435,1436
> < if (first.lnum == last.lnum && first.col != last.col)
> ---
> > if (first.lnum == last.lnum && first.col != last.col
> > && (first.col != 0 || lnum_of_next == last.lnum))
> 1436c1445,1446
> < if (first.lnum < last.lnum)
> ---
> > if (first.lnum < last.lnum
> > || (first.col == 0 && lnum_of_next != last.lnum))
> ===
Yeah, it appears it's currently only possible to delete characters
within a line or delete 2 lines or more. Quite strange. I wonder how
this ever worked with the actual Netbeans.
I think we should change it to the proper solution:
1. If less than one line, delete characters in one line
2. otherwise:
a. Delete characters in the starting line (if not a whole line)
b. Delete whole lines (if at least one)
c. Delete characters in the ending line (if not a whole line)
--
Don't Panic!
-- The Hitchhiker's Guide to the Galaxy
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: is this a bug or a feature??
denis wrote:
> Hello,
>
> I am seeing a problem where execution of seemingly unrelated commands
> causes a problem with resetting 'lines' variable
>
> " here, lines is set to 23
> let g:foo = tempname()
> call system('touch ' . g:foo)
> " here it is reset to the height of my xterm - in this case 50
>
> eh? is this a bug or a feature?
It's a feature.
The point is that terminal might be resized when running
the external command so VIM will try to re-detect it
after executing any external command.
Detection of the terminal size is described in
:he window-size
--
Beating the averages: http://www.paulgraham.com/avg.html
Python paradox: http://www.paulgraham.com/pypar.html
Bad Vista:http://badvista.org/
XML sucks:http://c2.com/cgi/wiki?XmlSucks
For robots (please don't mail me there): [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Integration of Vim
It seems that vim is not designed to be an editor component and too advanced to be a game engine script editor. So I suggest another choice - scintilla. Scintilla is a free source code editing component. It comes with complete source code and a license that permits use in any free project or commercial product. Scintilla is writen in C++ and used as editor component in many editors like SciTE, Nodepad++, etc. You can find it on http://www.scintilla.org/ B.G. On 10月11日, 下午2时38分, Wynand <[EMAIL PROTECTED]> wrote: > I wrote a game engine with embedded script engines and would like to > integrate vim as the primary editor for the scripts and other > functions. I googled it for several days now and cant really come up > with anything useful, I also downloaded the source and found it quite > overwhelming at first glance. Is there any documentation on how to > interface with Vim, or any C/C++ libraries that I can use to do so? > i.e libVim or similar? --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
