Re: Fastest way to append line or char to a buffer
On 16/08/06, Brad Beveridge <[EMAIL PROTECTED]> wrote:
On 16/08/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Brad -
>
> > As a side note, if I wanted to get really fast char append, how does
> > this method sound:
> > 1) In a structure (not sure if a mem_line or bufT struct), have three
> > new entries
> > uint current_line_num;
> > uchar *current_line_buffer;
> > uint current_line_alloced;
> > 2) current_line_buffer points to the string data for the current line,
> > it starts off at a sane size (say 80, or screen_width), and doubles in
> > alloced size when it is too full.
> > 3) ml_append_char (or whatever I call it), will check the target line
> > number against current_line_number, if the match then
> > - append the char, possibly reallocing the current_line_buffer if we
> > have run out of space
> > ELSE, the edit line number and our "cached line" don't match
> > - trim the size of the current_line_buffer to match the STRLEN of the line
> > - alloc a new oversized line buffer and copy the new edit line into it
> > - append the char as above
>
> Vim caches the last changed line, you could do something with that.
> Start looking at ml_flush_line(), you can find the rest from there.
>
> > Would this kind of optimisation be more widely useful?
>
> Perhaps. Changing the same line several times is not unusual. It
> mostly depends on how much code would need to be changed compared to
> how much we would gain.
>
> - Bram
>
Thanks for the tips, I'll test all this out and see what I can come up
with. I also accidentally posted just to Bram, so I've included the
list in this reply.
Thanks
Brad
I ended up writing a string append function, that has sped up my
output code by a couple of orders of magnitude :) Here it is, does it
look sane?
Cheers
Brad
/*
* Append string to line lnum, with buffering, in current buffer.
*
* Always makes a copy of the incoming string
*
* Check: The caller of this function should probably also call
* changed_lines(), unless update_screen(NOT_VALID) is used.
*
* return FAIL for failure, OK otherwise
*/
int
ml_append_string(lnum, string, slen)
linenr_Tlnum;
char_u *string;
int slen;
{
int append_len = 0;
int line_len = 0;
if (slen == -1)
append_len = STRLEN(string);
else
append_len = slen;
if (string == NULL) /* just checking... */
return FAIL;
if (lnum == 0)
ml_append (lnum, string, slen, 0);
/* When starting up, we might still need to create the memfile */
if (curbuf->b_ml.ml_mfp == NULL && open_buffer(FALSE, NULL) == FAIL)
return FAIL;
#ifdef FEAT_NETBEANS_INTG
/*
#error I am 99% sure this is broken
if (usingNetbeans)
{
netbeans_removed(curbuf, lnum, 0, (long)STRLEN(ml_get(lnum)));
netbeans_inserted(curbuf, lnum, 0, string, (int)STRLEN(string));
}
*/
#endif
if (curbuf->b_ml.ml_line_lnum != lnum) /* other line buffered */
{
ml_flush_line(curbuf); /* flush it, this frees
ml_line_ptr */
/* Take a pointer to the existing line, will get re-alloced right
* away below because it is not big enough */
curbuf->b_ml.ml_line_ptr = vim_strsave(ml_get(lnum));
curbuf->b_ml.ml_line_len = STRLEN(curbuf->b_ml.ml_line_ptr);
curbuf->b_ml.ml_line_lnum = lnum;
}
/* By here,
* curbuf->b_ml.ml_line_ptr - is filled with the correct existing line
* curbuf->b_ml.ml_line_len - is the alloced size of the line
*/
line_len = STRLEN(curbuf->b_ml.ml_line_ptr);
if (curbuf->b_ml.ml_line_len < line_len + append_len + 1)
{
int new_len = (curbuf->b_ml.ml_line_len + line_len + 1) * 2;
char_u *new_line;
if (new_len < 80) new_len = 80;
new_line = vim_strnsave(curbuf->b_ml.ml_line_ptr, new_len);
vim_free(curbuf->b_ml.ml_line_ptr);
curbuf->b_ml.ml_line_ptr = new_line;
curbuf->b_ml.ml_line_len = new_len;
}
/* by here:
* ml_line_ptr is allocated to fit the current line + the append
* ml_line_len is the total alloced size of the line
*/
STRCPY (&curbuf->b_ml.ml_line_ptr[line_len], string); /* Append
our string */
curbuf->b_ml.ml_line_ptr[line_len + append_len] = NUL; /* End the line */
curbuf->b_ml.ml_flags = (curbuf->b_ml.ml_flags | ML_LINE_DIRTY) & ~ML_EMPTY;
return OK;
}
How to trigger a screen update from RealWaitForChar
Hi all, I'm working with a Vim that has been hacked so that you can get callbacks when data appears on a socket. Basically, our callback system works in pretty much the same way as the code in FEAT_SNIFF. We add the filedescriptors that we are interested in to the select/poll code in os_unix, if there is data pending on a socket then we callback a registered function, which should clear the data from the socket. In my particular case, the callback calls into Lisp code in our embedded Lisp interpreter, which writes data to buffers using ml_replace and ml_append. Q1) Is using ml_append from (effectively) within RealWaitForChar a bad thing? At the moment it appears to work properly. At the moment, after the callback has run we call screen_update(NOT_VALID). However, from what I can see, calling screen_update may (does?) re-call RealWaitForChar, which can retrigger the callback, etc. Q2) Is this nesting of RealWaitForChar a bad thing? (I thing it may be) Q3) What is the correct way/place to trigger screen_update(NOT_VALID)? How should I trigger it from within RealWaitForChar? One other point to consider, although we may do callbacks, RealWaitForChar may not have keyboard input - what should RealWaitForChar return in this case? If the list would like to see this code, I can post a patch, or you can use Darcs to get a Vim+Callbacks+ECL from http://theclapp.org/repos/vim70+async+ecl/. Q4) Would this callback mechanism be more generally useful for other scripting engines? Cheers Brad
RE: gVim bug: Window stretched across 2 desktops gets resized on split
I'm on Windows Vista Beta 2, but this happens on XP / 2003 / what-have-you. Setting that GUI flag fixes it though; thanks for your help! -- Paul Betts <[EMAIL PROTECTED]> -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 2:00 PM To: Paul Betts Cc: vim-dev@vim.org Subject: Re: gVim bug: Window stretched across 2 desktops gets resized on split Paul Betts wrote: > I often stretch a gVim window across two monitors, putting the > vertical split in between the two monitors so that I can quickly > switch between them and edit in both monitors. However, if I size the > window then vertical split it, the window will resize itself to one > desktop. I suspect that gVim is using the wrong function to get the > size of the desktop, but I haven't investigated it myself. > > In summary, > > To reproduce: > 1. Open a gVim window in Windows on a dual-monitor machine 2. Stretch > it across both monitors (Not maximized, just stretched across both > desktops) 3. Type C-w v to create a vertical split > > Expected: > Vim should split the window without moving it > > Actual: > Vim splits the window and resizes it to the left monitor. > > Email me back and let me know if I can be of any help, thanks for the > great program! What kind of system are you on? You can probably work around the problem with: :set guioptions+=lr A real solution would be better though. I don't have such a system to try it out on. -- "Hit any key to continue" is very confusing when you have two keyboards. /// 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: Warnings in latest make
Tony Mechelynck wrote: > After applying the latest 10 patches (54-63) to Vim, I get a number of > warnings (below). Since the compile proceeds to completion, I shall > "install" the resulting executable; but you may (or may not) want to > investigate this more deeply. I don't feel competent to determine which > of these warnings (if any) are really important. > > - Using the top-level Makefile with "gcc (GCC) 3.3.5 20050117 > (prerelease) (SUSE Linux)" on SuSE 9.3 > > - Configuration settings: > export CONF_OPT_GUI='--enable-gnome-check' > export CONF_OPT_PERL='--enable-perlinterp' > export CONF_OPT_PYTHON='--enable-pythoninterp' > export CONF_OPT_TCL='--enable-tclinterp --with-tcl=tclsh8.4' > export CONF_OPT_RUBY='--enable-rubyinterp' > export CONF_OPT_MZSCHEME='--enable-mzschemeinterp' > export CONF_OPT_CSCOPE='--enable-cscope' > export CONF_OPT_MULTIBYTE='--enable-multibyte' > export CONF_OPT_OUTPUT='--enable-fontset' > export CONF_OPT_FEAT='--with-features=huge' > export CONF_OPT_COMPBY='"[EMAIL PROTECTED]"' > > (but mzscheme and xfontset are disabled by configure). > > - Extracts from the make log: > [...] > edit.c: In function `ins_compl_prep': > edit.c:3225: warning: `temp' might be used uninitialized in this function That is right, "temp" should be initialized. > [...] > if_perl.c: In function `boot_VIM': > if_perl.c:1490: warning: unused variable `items' These can't be avoided, they are caused by the Perl stuff. > [...] > In file included from /usr/include/python2.4/Python.h:8, > from if_python.c:41: > /usr/include/python2.4/pyconfig.h:832:1: warning: "_POSIX_C_SOURCE" > redefined > In file included from /usr/include/stdio.h:28, > from os_unix.h:21, > from vim.h:233, > from if_python.c:20: > /usr/include/features.h:150:1: warning: this is the location of the > previous definition This is a problem in a Python include file. > [...] > /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o)(.text+0x90a): In > function `posix_tmpnam': > : warning: the use of `tmpnam_r' is dangerous, better use `mkstemp' > /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o)(.text+0x9df): In > function `posix_tempnam': > : warning: the use of `tempnam' is dangerous, better use `mkstemp' > link.sh: Linked fine with a few libraries removed > [...] This also is a problem in Python. -- "Hit any key to continue" is a lie. /// 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: gVim bug: Window stretched across 2 desktops gets resized on split
Paul Betts wrote: > I often stretch a gVim window across two monitors, putting the vertical > split in between the two monitors so that I can quickly switch between > them and edit in both monitors. However, if I size the window then > vertical split it, the window will resize itself to one desktop. I > suspect that gVim is using the wrong function to get the size of the > desktop, but I haven't investigated it myself. > > In summary, > > To reproduce: > 1. Open a gVim window in Windows on a dual-monitor machine > 2. Stretch it across both monitors (Not maximized, just stretched across > both desktops) > 3. Type C-w v to create a vertical split > > Expected: > Vim should split the window without moving it > > Actual: > Vim splits the window and resizes it to the left monitor. > > Email me back and let me know if I can be of any help, thanks for the > great program! What kind of system are you on? You can probably work around the problem with: :set guioptions+=lr A real solution would be better though. I don't have such a system to try it out on. -- "Hit any key to continue" is very confusing when you have two keyboards. /// 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///
gVim bug: Window stretched across 2 desktops gets resized on split
I often stretch a gVim window across two monitors, putting the vertical split in between the two monitors so that I can quickly switch between them and edit in both monitors. However, if I size the window then vertical split it, the window will resize itself to one desktop. I suspect that gVim is using the wrong function to get the size of the desktop, but I haven't investigated it myself. In summary, To reproduce: 1. Open a gVim window in Windows on a dual-monitor machine 2. Stretch it across both monitors (Not maximized, just stretched across both desktops) 3. Type C-w v to create a vertical split Expected: Vim should split the window without moving it Actual: Vim splits the window and resizes it to the left monitor. Email me back and let me know if I can be of any help, thanks for the great program! -- Paul Betts <[EMAIL PROTECTED]>
Re: conceal-patch status
On 8/17/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Vince Negri wrote: > I'm still alive, just very busy :-) > > New home for conceal patches is: > > http://vince.negri.googlepages.com/ [...] OK. I've updated my W32 and Unix HowTo (compile Vim) pages to mention this, and while I was at it, I've mentioned Steve Hall's W32 download page on my main "vim" page http://users.skynet.be/antoine.mechelynck/vim/ I put the link to the 'conceal' patch into vimtip: http://www.vim.org/tips/tip.php?tip_id=1308 so that people who look for conceal patch on the vim.org can find the updated link. Yakov
Re: more on local additions in help.txt -- debian bug?
On Thu, Aug 17, 2006 at 08:33:23AM -0400, Benji Fisher wrote: > On Wed, Aug 16, 2006 at 03:33:42PM -0400, Gabriel Farrell wrote: > > > > Aha. Benji's explanation is correct. My $VIM points at > > /usr/share/vim/addons/ which contains doc/matchit.txt, doc/tags, and > > plugin/matchit.vim. This is the default for the Debian installation. > > The screwy thing is that unless I copy matchit.vim into > > $HOME/.vim/plugin/, matchit isn't installed, and I can't see any help > > for it because, as you surmised, :helptags hasn't been run on > > /usr/share/vim/addons/doc/ -- the tags file in that directory is > > empty. > > > > I'm not sure if this is a bug in vim or the debian package; I think > > mostly the package. > > > > gabe > > I think you are right that the package only partially installs the > plugin. Just to be clear, there are three related things; I will use > to denote a path that is in the 'runtimepath' option. > > (1) A line appears under :help local-additions if /doc/matchit.txt > exists. Yes. Maybe it should only appear once :helptags has been run? Is that possible? > (2) A tags file for /matchit.txt is created if you run > :helptags and :help will find those tags if is in > 'runtimepath'. Yes. > (3) The plugin will be effective if /plugin/matchit.vim exists. I wasn't sure about this one, but after some tests I see it's also true. > This particular plugin also relies on /ftplugin/*.vim to set > buffer-local variables that control its behavior. Yes. Thank you for the clarification. gabe
Re: more on local additions in help.txt -- debian bug?
On Wed, Aug 16, 2006 at 03:33:42PM -0400, Gabriel Farrell wrote: > > Aha. Benji's explanation is correct. My $VIM points at > /usr/share/vim/addons/ which contains doc/matchit.txt, doc/tags, and > plugin/matchit.vim. This is the default for the Debian installation. > The screwy thing is that unless I copy matchit.vim into > $HOME/.vim/plugin/, matchit isn't installed, and I can't see any help > for it because, as you surmised, :helptags hasn't been run on > /usr/share/vim/addons/doc/ -- the tags file in that directory is > empty. > > I'm not sure if this is a bug in vim or the debian package; I think > mostly the package. > > gabe I think you are right that the package only partially installs the plugin. Just to be clear, there are three related things; I will use to denote a path that is in the 'runtimepath' option. (1) A line appears under :help local-additions if /doc/matchit.txt exists. (2) A tags file for /matchit.txt is created if you run :helptags and :help will find those tags if is in 'runtimepath'. (3) The plugin will be effective if /plugin/matchit.vim exists. This particular plugin also relies on /ftplugin/*.vim to set buffer-local variables that control its behavior. HTH --Benji Fisher
