Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
Comment #4 on issue 230 by brammool...@gmail.com: Vim: Caught deadly signal SEGV http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
Christian wrote:
Comment #3 on issue 230 by chrisbr...@googlemail.com: Vim: Caught deadly
signal SEGV
http://code.google.com/p/vim/issues/detail?id=230
I can sometimes reproduce it. This patch fixes the crash for me:
diff --git a/src/window.c b/src/window.c
--- a/src/window.c
+++ b/src/window.c
@@ -4721,6 +4721,8 @@ win_alloc_lines(wp)
win_free_lsize(wp)
win_T *wp;
{
+if (wp == NULL)
+ return;
vim_free(wp-w_lines);
wp-w_lines = NULL;
}
There is however some other strange going on. Half of the times I run
./vim -N -g -f --noplugin -u /tmp/vimrc file.c
the window opens fine, but Vim seems to get confused about the screensize.
The last line is not drawn correctly. If I do :set number, it jumps from 26
in the second last line to 32 in the last line.
Yes, it looks like we are fixing a symptom, not the cause. I'll include
this patch to avoid the crash, but we should keep looking for the cause.
--
Bravely bold Sir Robin, rode forth from Camelot,
He was not afraid to die, Oh Brave Sir Robin,
He was not at all afraid to be killed in nasty ways
Brave, brave, brave, brave Sir Robin.
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.317
Patch 7.4.317
Problem:Crash when starting gvim. Issue 230.
Solution: Check for a pointer to be NULL. (Christian Brabandt)
Files: src/window.c
*** ../vim-7.4.316/src/window.c 2014-05-28 13:42:59.884078184 +0200
--- src/window.c2014-06-12 11:36:53.619441640 +0200
***
*** 4721,4728
win_free_lsize(wp)
win_T *wp;
{
! vim_free(wp-w_lines);
! wp-w_lines = NULL;
}
/*
--- 4721,4732
win_free_lsize(wp)
win_T *wp;
{
! /* TODO: why would wp be NULL here? */
! if (wp != NULL)
! {
! vim_free(wp-w_lines);
! wp-w_lines = NULL;
! }
}
/*
*** ../vim-7.4.316/src/version.c2014-05-29 14:36:26.156862577 +0200
--- src/version.c 2014-06-12 11:37:37.907443315 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 317,
/**/
--
press CTRL-ALT-DEL for more information
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: global command slow when clipboard=unnamed
Christian wrote:
On So, 08 Jun 2014, Bram Moolenaar wrote:
Christian wrote:
On So, 01 Jun 2014, Bram Moolenaar wrote:
When restoring clip_unnamed, it's not too dificult to set the
clipboard then. Would require checking that it would have been set
(default register changed). Then the remarks about doesn't work for
some commands can be changed to for some commands disabled until the
end. I'm sure this avoids surprises for users.
I am not sure how to do it.
This would require a flag, e.g. did_set_selection. When resetting
clip_unnamed before doing a global operation, this flag would be reset.
Then when text is deleted or yanked, clip_own_selection() will be
called, and if the register used matches the register that would be
associated with clip_unnamed, then set the did_set_selection flag.
When restoring clip_unnamed, check if did_set_selection was set, and
if it is call clip_own_selection() to get the current unnamed register
into the clipboard.
It's a bit sketchy, there are probably a few more details to work out,
but basically it would work to avoid putting text on the clipboard many
times and still end up with the correct clipboard contents in the end.
If we can make this work properly we can avoid users having to be aware
of this and just enjoy the much faster operation.
Okay, I think I understood. Here is a patch.
Almost. This code now uses clip_did_set_selection for two purposes. I
would reset clip_unnamed before calling global_exe(), where you set
clip_did_set_selection to FALSE. Simlarly in ex_listdo().
Oh, and move the calls to clip_own_selection() to a function, instead of
copying this code to three places. That function would then also
restore clip_unnamed.
For consistency the code to start a sequence of global changes would
be in one function, and that function containing clip_own_selection()
would be callend the end function.
So, something like:
start_global_changes()
clip_unnamed_saved = clip_unnamed;
if (clip_unnamed)
{
clip_unnamed = FALSE;
clip-did_set_selection = FALSE;
}
end_global_changes()
if (clip_unnamed_saved)
{
clip_unnamed = TRUE;
if (clip_did_set_selection)
{
if (clip_unnamed CLIP_UNNAMED)
clip_own_selection(clip_star);
else if (clip_unnamed CLIP_UNNAMED_PLUS)
clip_own_selection(clip_plus);
}
}
Still sketchy.
For :global I think we can do this always, not only when ndone is large.
--
Microsoft: Windows NT 4.0 now has the same user-interface as Windows 95
Windows 95: Press CTRL-ALT-DEL to reboot
Windows NT 4.0: Press CTRL-ALT-DEL to login
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.318
Patch 7.4.318
Problem:Check for whether a highlight group has settings ignores fg and bg
color settings.
Solution: Also check cterm and GUI color settings. (Christian Brabandt)
Files: src/syntax.c
*** ../vim-7.4.317/src/syntax.c 2014-03-23 15:12:29.939264336 +0100
--- src/syntax.c2014-06-12 12:16:13.851530931 +0200
***
*** 8043,8050
--- 8043,8056
{
return ( HL_TABLE()[idx].sg_term_attr != 0
|| HL_TABLE()[idx].sg_cterm_attr != 0
+ || HL_TABLE()[idx].sg_cterm_fg != 0
+ || HL_TABLE()[idx].sg_cterm_bg != 0
#ifdef FEAT_GUI
|| HL_TABLE()[idx].sg_gui_attr != 0
+ || HL_TABLE()[idx].sg_gui_fg_name != NULL
+ || HL_TABLE()[idx].sg_gui_bg_name != NULL
+ || HL_TABLE()[idx].sg_gui_sp_name != NULL
+ || HL_TABLE()[idx].sg_font_name != NUL
#endif
|| (check_link (HL_TABLE()[idx].sg_set SG_LINK)));
}
*** ../vim-7.4.317/src/version.c2014-06-12 11:49:42.219470717 +0200
--- src/version.c 2014-06-12 12:17:25.607533645 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 318,
/**/
--
The software said it requires Windows 95 or better, so I installed Linux.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: 'isfname' and 'isprint' don't allow to include ^@ = 0
Christian wrote: On Di, 10 Jun 2014, Ingo Karkat wrote: Hello Vim developers, a question on Super User (http://superuser.com/questions/766817/hide-non-printable-characters-in-vim/) asks to show all non-printable (control) characters with a single display cell. One (hacky, and arguably not perfect) way to do this is by including all ASCII characters in 'isprint': :set isprint=0-255 However, this yields E474: Invalid argument. It only works by excluding ^@ = 0 (via :set isprint=1-255). Also, other variants such as :set isprint^=0 and :set isprint=0,1-255 and :set isprint=C-vC-@,1-255 do not work (verified up to current version 7.4.316). The same applies to the similar 'isfname' setting, even though its documentation (and 'isprint' refers to that, too) explicitly mentions the number 0: ,[ :help 'isfname' excerpt ] | The format of this option is a list of parts, separated with commas. | Each part can be a single character number or a range. A range is two | character numbers with '-' in between. A character number can be a | decimal number between 0 and 255 or the ASCII character itself (does | not work for digits). ` I see this as a bug in the :set command, or, if technical reasons prevent the use of ^@ in those option values, a bug in the documentation. (Preferably, to address the issue in the mentioned question, the first. :-) I don't know if it is a bug or it was done intentionally and I even don't know what :set isprint=0-255 is supposed to be doing. But here is a patch: diff --git a/src/charset.c b/src/charset.c --- a/src/charset.c +++ b/src/charset.c @@ -197,7 +197,7 @@ buf_init_chartab(buf, global) #endif c2 = *p++; } - if (c = 0 || c = 256 || (c2 c c2 != -1) || c2 = 256 + if (c 0 || c = 256 || (c2 c c2 != -1) || c2 = 256 || !(*p == NUL || *p == ',')) return FAIL; Well, this allows having a zero in the option value, but I very much doubt it actually works. In C the zero is used to terminate a string, thus sending a zero to the terminal just won't work. If you want to *display* control characters you need to do something else anyway, since sending a BS or other control character won't result in displaying anything. -- The greatest lies of all time: (1) The check is in the mail. (2) We have a really challenging assignment for you. (3) I love you. (4) All bugs have been fixed. (5) This won't hurt a bit. (6) Honey, I just need to debug this program and be home in 5 minutes. (7) I have just sent you an e-mail about that. (8) Of course I'll respect you in the morning. (9) I'm from the government, and I'm here to help you. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: 'isfname' and 'isprint' don't allow to include ^@ = 0
On 12-Jun-2014 12:51 +0200, Bram Moolenaar wrote: Christian wrote: On Di, 10 Jun 2014, Ingo Karkat wrote: Hello Vim developers, a question on Super User (http://superuser.com/questions/766817/hide-non-printable-characters-in-vim/) asks to show all non-printable (control) characters with a single display cell. One (hacky, and arguably not perfect) way to do this is by including all ASCII characters in 'isprint': :set isprint=0-255 However, this yields E474: Invalid argument. It only works by excluding ^@ = 0 (via :set isprint=1-255). Also, other variants such as :set isprint^=0 and :set isprint=0,1-255 and :set isprint=C-vC-@,1-255 do not work (verified up to current version 7.4.316). The same applies to the similar 'isfname' setting, even though its documentation (and 'isprint' refers to that, too) explicitly mentions the number 0: ,[ :help 'isfname' excerpt ] | The format of this option is a list of parts, separated with commas. | Each part can be a single character number or a range. A range is two | character numbers with '-' in between. A character number can be a | decimal number between 0 and 255 or the ASCII character itself (does | not work for digits). ` I see this as a bug in the :set command, or, if technical reasons prevent the use of ^@ in those option values, a bug in the documentation. (Preferably, to address the issue in the mentioned question, the first. :-) I don't know if it is a bug or it was done intentionally and I even don't know what :set isprint=0-255 is supposed to be doing. But here is a patch: diff --git a/src/charset.c b/src/charset.c --- a/src/charset.c +++ b/src/charset.c @@ -197,7 +197,7 @@ buf_init_chartab(buf, global) #endif c2 = *p++; } - if (c = 0 || c = 256 || (c2 c c2 != -1) || c2 = 256 + if (c 0 || c = 256 || (c2 c c2 != -1) || c2 = 256 || !(*p == NUL || *p == ',')) return FAIL; Well, this allows having a zero in the option value, but I very much doubt it actually works. In C the zero is used to terminate a string, thus sending a zero to the terminal just won't work. Well, at least I can do this in a terminal: $ printf foo\0bar\n foobar Seems like Bash handles this somehow, and the NUL is skipped / prints as nothing. If you want to *display* control characters you need to do something else anyway, since sending a BS or other control character won't result in displaying anything. The OP's use case is representing every character by a single display cell. Obviously, BS will mess up things. But probably, a (binary) file won't contain many of those (in the area of interest), but possibly a lot of NULs. Skipping those in the output might be okay for his use. -- regards, ingo -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.319
Patch 7.4.319
Problem:Crash when putting zero bytes on the clipboard.
Solution: Do not support the utf8_atom target when not using an Unicode
encoding. (Naofumi Honda)
Files: src/ui.c
*** ../vim-7.4.318/src/ui.c 2014-03-23 15:12:29.943264337 +0100
--- src/ui.c2014-06-12 13:25:21.791687853 +0200
***
*** 2324,2330
if ( *target != XA_STRING
#ifdef FEAT_MBYTE
*target != vimenc_atom
!*target != utf8_atom
#endif
*target != vim_atom
*target != text_atom
--- 2324,2330
if ( *target != XA_STRING
#ifdef FEAT_MBYTE
*target != vimenc_atom
!(*target != utf8_atom || !enc_utf8)
#endif
*target != vim_atom
*target != text_atom
*** ../vim-7.4.318/src/version.c2014-06-12 12:20:50.195541385 +0200
--- src/version.c 2014-06-12 13:26:09.147689645 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 319,
/**/
--
FIRST HEAD: Oh! quick! get the sword out I want to cut his head off.
THIRD HEAD: Oh, cut your own head off.
SECOND HEAD: Yes - do us all a favour.
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Highlighting artefacts / glitches prompted by low updatetime
Hello!
I have a plugin which updates signs when a CursorHold auto-command fires (among
other auto-commands). When `updatetime` is set to a low value, say anything
under 100, and highlighting is in effect, I see highlighting glitches on many
individual characters: specifically the foreground and background colours
differ from the characters around them.
Here's how I (and hopefully you) can reproduce the problem:
$ cd
$ mv .vimrc vimrc
$ cat .vimrc EOF
set updatetime=50
syntax enable
EOF
$ mv .vim vim
$ mkdir .vim
$ cp -r vim/bundle/vim-gitgutter/{autoload,plugin} .vim
The last step assumes you already have vim-gitgutter
(https://github.com/airblade/vim-gitgutter) installed.
Then edit a file which triggers syntax highlighting and make some changes. At
this point I always see a number of highlighting glitches. They can be cleared
with a redraw.
As far as I can tell, the specific filetype doesn't matter. When I edit a
plain text file, it's only when I specify a filetype which causes some
highlighting that the glitches start.
I used the HiLinkTrace plugin to investigate whether the characters with
glitches have different highlights from their neighbours. It didn't report any
differences, which leads me to think that the highlight settings haven't been
changed; instead there's a bug in the rendering.
I'm using Vim 7.4.258, specifically MacVim. I get the glitches in the terminal
version (mvim -v) but not the gui version. Other people on different OS's have
reported the same problem, always in terminal vim.
At this point I've investigated as far as I can. Any help would be much
appreciated!
Thanks in advance,
Andrew Stewart
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.320
Patch 7.4.320
Problem:Possible crash when an BufLeave autocommand deletes the buffer.
Solution: Check for the window pointer being valid. Postpone freeing the
window until autocommands are done. (Yasuhiro Matsumoto)
Files: src/buffer.c, src/fileio.c, src/globals.h, src/window.c
*** ../vim-7.4.319/src/buffer.c 2014-05-07 16:35:05.029152844 +0200
--- src/buffer.c2014-06-12 13:47:17.799737639 +0200
***
*** 371,377
unload_buf = TRUE;
#endif
! if (win != NULL)
{
/* Set b_last_cursor when closing the last window for the buffer.
* Remember the last cursor position and window options of the buffer.
--- 371,381
unload_buf = TRUE;
#endif
! if (win != NULL
! #ifdef FEAT_WINDOWS
!win_valid(win) /* in case autocommands closed the window */
! #endif
! )
{
/* Set b_last_cursor when closing the last window for the buffer.
* Remember the last cursor position and window options of the buffer.
*** ../vim-7.4.319/src/fileio.c 2014-05-02 15:46:10.731268318 +0200
--- src/fileio.c2014-06-12 13:53:33.207751842 +0200
***
*** 9549,9555
/*
* When stopping to execute autocommands, restore the search patterns and
! * the redo buffer. Free buffers in the au_pending_free_buf list.
*/
if (!autocmd_busy)
{
--- 9549,9556
/*
* When stopping to execute autocommands, restore the search patterns and
! * the redo buffer. Free any buffers in the au_pending_free_buf list and
! * free any windows in the au_pending_free_win list.
*/
if (!autocmd_busy)
{
***
*** 9562,9567
--- 9563,9574
vim_free(au_pending_free_buf);
au_pending_free_buf = b;
}
+ while (au_pending_free_win != NULL)
+ {
+ win_T *w = au_pending_free_win-w_next;
+ vim_free(au_pending_free_win);
+ au_pending_free_win = w;
+ }
}
/*
*** ../vim-7.4.319/src/globals.h2014-05-28 18:22:37.876225054 +0200
--- src/globals.h 2014-06-12 13:54:29.163753959 +0200
***
*** 387,396
* which one is preferred, au_new_curbuf is set to it */
EXTERN buf_T *au_new_curbuf INIT(= NULL);
! /* When deleting the buffer and autocmd_busy is TRUE, do not free the buffer
! * but link it in the list starting with au_pending_free_buf, using b_next.
! * Free the buffer when autocmd_busy is set to FALSE. */
EXTERN buf_T *au_pending_free_buf INIT(= NULL);
#endif
#ifdef FEAT_MOUSE
--- 387,398
* which one is preferred, au_new_curbuf is set to it */
EXTERN buf_T *au_new_curbuf INIT(= NULL);
! /* When deleting a buffer/window and autocmd_busy is TRUE, do not free the
! * buffer/window. but link it in the list starting with
! * au_pending_free_buf/ap_pending_free_win, using b_next/w_next.
! * Free the buffer/window when autocmd_busy is being set to FALSE. */
EXTERN buf_T *au_pending_free_buf INIT(= NULL);
+ EXTERN win_T *au_pending_free_win INIT(= NULL);
#endif
#ifdef FEAT_MOUSE
*** ../vim-7.4.319/src/window.c 2014-06-12 11:49:42.219470717 +0200
--- src/window.c2014-06-12 13:51:54.939748124 +0200
***
*** 4597,4603
if (wp != aucmd_win)
#endif
win_remove(wp, tp);
! vim_free(wp);
#ifdef FEAT_AUTOCMD
unblock_autocmds();
--- 4597,4609
if (wp != aucmd_win)
#endif
win_remove(wp, tp);
! if (autocmd_busy)
! {
! wp-w_next = au_pending_free_win;
! au_pending_free_win = wp;
! }
! else
! vim_free(wp);
#ifdef FEAT_AUTOCMD
unblock_autocmds();
*** ../vim-7.4.319/src/version.c2014-06-12 13:28:26.771694851 +0200
--- src/version.c 2014-06-12 13:40:23.507721966 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 320,
/**/
--
Life would be so much easier if we could just look at the source code.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.321
Patch 7.4.321
Problem:Can't build with strawberry perl 5.20 + mingw-w64-4.9.0.
Solution: Define save_strlen. (Ken Takata)
Files: src/if_perl.xs
*** ../vim-7.4.320/src/if_perl.xs 2014-03-12 17:08:01.508807656 +0100
--- src/if_perl.xs 2014-06-12 16:02:25.584044368 +0200
***
*** 191,196
--- 191,199
# define Perl_pop_scope dll_Perl_pop_scope
# define Perl_push_scope dll_Perl_push_scope
# define Perl_save_int dll_Perl_save_int
+ # if (PERL_REVISION == 5) (PERL_VERSION = 20)
+ # define Perl_save_strlen dll_Perl_save_strlen
+ # endif
# define Perl_stack_grow dll_Perl_stack_grow
# define Perl_set_context dll_Perl_set_context
# if (PERL_REVISION == 5) (PERL_VERSION = 14)
***
*** 311,316
--- 314,322
static void (*Perl_pop_scope)(pTHX);
static void (*Perl_push_scope)(pTHX);
static void (*Perl_save_int)(pTHX_ int*);
+ #if (PERL_REVISION == 5) (PERL_VERSION = 20)
+ static void (*Perl_save_strlen)(pTHX_ STRLEN* ptr);
+ #endif
static SV** (*Perl_stack_grow)(pTHX_ SV**, SV**p, int);
static SV** (*Perl_set_context)(void*);
#if (PERL_REVISION == 5) (PERL_VERSION = 14)
***
*** 440,445
--- 446,454
{Perl_pop_scope, (PERL_PROC*)Perl_pop_scope},
{Perl_push_scope, (PERL_PROC*)Perl_push_scope},
{Perl_save_int, (PERL_PROC*)Perl_save_int},
+ #if (PERL_REVISION == 5) (PERL_VERSION = 20)
+ {Perl_save_strlen, (PERL_PROC*)Perl_save_strlen},
+ #endif
{Perl_stack_grow, (PERL_PROC*)Perl_stack_grow},
{Perl_set_context, (PERL_PROC*)Perl_set_context},
#if (PERL_REVISION == 5) (PERL_VERSION = 14)
*** ../vim-7.4.320/src/version.c2014-06-12 14:01:27.583769788 +0200
--- src/version.c 2014-06-12 16:02:37.156044806 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 321,
/**/
--
Microsoft's definition of a boolean: TRUE, FALSE, MAYBE
Embrace and extend...?
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: Vim: Caught deadly signal SEGV http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where junk.vim has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim separates from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches now... Chip -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
Charles Campbell wrote: v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: Vim: Caught deadly signal SEGV http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where junk.vim has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim separates from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches now... Hmm, apparently I was using an oddball version of vim that wasn't completely patched. So I've now rebuilt vim 7.4.320; using valgrind --log-file=gvim.out gvim -u junk.vim -U NONE macos The attached file contains the log. Vim crashed eventually, but it took a lot of j and k motions, sprinkled with the occasional L and G to get it. Would one of you tell me how best to apply gdb to gvim? I suppose I could run gvim and then attach gdb to it after its started. Regards, Chip -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ==26227== Memcheck, a memory error detector ==26227== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==26227== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==26227== Command: gvim -u junk.vim -U NONE macos ==26227== Parent PID: 25480 ==26227== ==26227== ==26227== HEAP SUMMARY: ==26227== in use at exit: 437,694 bytes in 8,929 blocks ==26227== total heap usage: 50,594 allocs, 41,665 frees, 10,562,563 bytes allocated ==26227== ==26227== LEAK SUMMARY: ==26227==definitely lost: 0 bytes in 0 blocks ==26227==indirectly lost: 0 bytes in 0 blocks ==26227== possibly lost: 111,439 bytes in 2,431 blocks ==26227==still reachable: 326,255 bytes in 6,498 blocks ==26227== suppressed: 0 bytes in 0 blocks ==26227== Rerun with --leak-check=full to see details of leaked memory ==26227== ==26227== For counts of detected and suppressed errors, rerun with: -v ==26227== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) ==26229== Invalid read of size 4 ==26229==at 0x5914AE: screen_del_lines (screen.c:9526) ==26229==by 0x590A42: win_do_lines (screen.c:9082) ==26229==by 0x59079D: win_del_lines (screen.c:8984) ==26229==by 0x5817B3: win_update (screen.c:1417) ==26229==by 0x5803AB: update_screen (screen.c:676) ==26229==by 0x62AA86: main_loop (main.c:1229) ==26229==by 0x62A621: main (main.c:1026) ==26229== Address 0x505aa1c is 0 bytes after a block of size 108 alloc'd ==26229==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==26229==by 0x50A953: lalloc (misc2.c:921) ==26229==by 0x58EFD2: screenalloc (screen.c:8190) ==26229==by 0x58ECCF: screen_valid (screen.c:8070) ==26229==by 0x51140E: update_topline (move.c:183) ==26229==by 0x51297C: curs_columns (move.c:971) ==26229==by 0x511F62: validate_cursor (move.c:653) ==26229==by 0x5F47EB: win_new_height (window.c:5663) ==26229==by 0x5F51F0: last_status_rec (window.c:5978) ==26229==by 0x5F5074: last_status (window.c:5930) ==26229==by 0x5421D1: set_num_option (option.c:8264) ==26229==by 0x53B710: do_set (option.c:4530) ==26229== ==26229== Invalid read of size 1 ==26229==at 0x5914DA: screen_del_lines (screen.c:9527) ==26229==by 0x590A42: win_do_lines (screen.c:9082) ==26229==by 0x59079D: win_del_lines (screen.c:8984) ==26229==by 0x5817B3: win_update (screen.c:1417) ==26229==by 0x5803AB: update_screen (screen.c:676) ==26229==by 0x62AA86: main_loop (main.c:1229) ==26229==by 0x62A621: main (main.c:1026) ==26229== Address 0x505aa7b is 0 bytes after a block of size 27 alloc'd ==26229==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==26229==by 0x50A953: lalloc (misc2.c:921) ==26229==by 0x58EFEA: screenalloc (screen.c:8192) ==26229==by 0x58ECCF: screen_valid (screen.c:8070) ==26229==by 0x51140E: update_topline (move.c:183) ==26229==by 0x51297C: curs_columns (move.c:971) ==26229==by 0x511F62: validate_cursor (move.c:653) ==26229==
Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
Charles Campbell wrote: v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: Vim: Caught deadly signal SEGV http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where junk.vim has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim separates from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches now... Chip OK, I attached to the gvim, moved the cursor about a bit, and got... (some of my comments are interlaced) Program received signal SIGSEGV, Segmentation fault. 0x0058a2c1 in char_needs_redraw (off_from=2241, off_to=5439488, cols=14) at screen.c:5487 5487 ((ScreenLines[off_from] != ScreenLines[off_to] - That off_to looks suspicious, as there are only 4245 characters in the file I'm using... - (gdb) up #1 0x0058a699 in screen_line (row=26, coloff=0, endcol=14, clear_width=83, rlflag=0) at screen.c:5605 5605redraw_next = char_needs_redraw(off_from, off_to, endcol - col); - Its 27 rows by 83 columns; nothing obvious yet. I note that screen_line() computes off_to with off_to = LineOffset[row] + coloff; - (gdb) p row $8 = 26 (gdb) p LineOffset[row] $9 = 5439488 (gdb) p coloff $10 = 0 - Looks like LineOffset[] has a problem. I don't see where LineOffset is set up - (gdb) p LineOffset $11 = (unsigned int *) 0xf435e0 - Looks like a reasonable pointer. - (gdb) p LineOffset[0] $13 = 747 (gdb) p LineOffset[1] $14 = 830 (gdb) p LineOffset[2] $15 = 913 (gdb) p LineOffset[3] $16 = 996 (gdb) p LineOffset[row-1] $17 = 0 (gdb) p LineOffset[row-2] I'm going to pass on figuring out what LineOffset is all about. I've attached the file I've been using for testing. Regards, Chip Campbell -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. Runtime Environments Mac OS X has two primary runtime environments: one based on the dynamic link editor, dyld, and the other based on Code Fragment Manager (CFM). OS X does not support ELF, and there's no dlopen, although the dlcompat library provides a limited compatibility layer (using native OS X functions) so that common Unix source can be compiled easily. CFM determines addresses for referenced symbols in executables at build time (a static approach). The executable format used is called PEF (Preferred Executable Format). dyld resolves undefined symbols at execution time. The executable format is Mach-O (Mach object-file-format). Mac OS X is natively a dyld/Mach-O platform - all system frameworks are built using dyld. In fact, the CFM/PEF environment is itself built on top of dyld/Mach-O. However, there exist provisions to call dyld code from CFM code. Moreover, if you wish to debug or trace a CFM application using GDB, you would need to use a Mach-O program called LaunchCFMApp: /System/Library/Frameworks/Carbon.framework/Versions/\ A/Support/LaunchCFMApp dyld/Mach-O is similar in many respects to ld.so/ELF, although they differ both conventionally and fundamentally. Some of these are: * Dynamic shared libraries on Mac OS X have the .dylib extension. The functionality of several traditional libraries (such as libc, libdl, libinfo, libkvm, libm, libpthread, librpcsvc, etc.) is provided by a single dynamically loadable framework, libSystem. libc.dylib etc. are simply symbolic links to libSystem.dylib. * Mac OS X builds libraries and
Re: [patch] fixing display of signs in GTK builds
Christian wrote: Bram, I noticed, when displaying icon signs in the gui version of Vim there might be a small line not overdrawn by the sign, caused by the 'linespace' setting set to be one. That does look rather ugly, if you display several signs side by side (see attached screenshot). Do you mean that the dark line below the + sign should not be there? And if 'linespace' is set to zero that black line is indeed gone? Here is a patch. A couple of comments: 1) I am not sure, why a call to gdk_draw_rectangle() is done in the existing code. I have left it out as it seems to be unnecessary I believe this is needed to first clear the area with the background color, in case the icon drawn is smaller than the available space. Perhaps you can try it with a rectangular icon, vertically and horizontally. E.g. something like a red exclamation mark. There would need to be some other sign at first to see any effect. 2) not sure, why a height of 127 was hard coded when drawing the size area. I have used the actual sign size for that The 127 is the value for alpha_threshold. At least according to the documentation I found. 3) when the sign hight differs from the char_height, it will always be rescaled. This of course has the additional disadvantage of causing a performance issue. Not sure, if this is noticeable, though. I don't think we should worry about performance. It appears that after your change the aspect ratio of the sign is not kept. Although that would be OK for filling the gap, if the sign was really a different shape it would look weird. In your specific case you would want the sign to fill the available space and probably don't care about keeping the aspect ratio. Adding a setting for this woule make it complicated... How about this: if we can fill the available space with a slightly different ascpect ratio, e.g., 10% different, filling the gap is nicer than the slightly different aspect ratio. If we change the aspect ratio more than 10% or so the icon will start looking weird and we stick to the aspect ratio and as a result there will be a gap (either vertically or horizontally). The names are a bit confusing, SIGN_ASPECT actually means the aspect ratio of the space availeble, with aspect is the aspect ratio of the sign being drawn. This also very much depends on the font size, since the space used for the icon is two character cells wide and one character cell plus 'linespace' high. -- FIRST HEAD: All right! All right! We'll kill him first and then have tea and biscuits. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.322
Patch 7.4.322
Problem:Using msgfmt is hard coded, cannot use gmsgfmt.
Solution: Use the msgfmt command found by configure. (Danek Duvall)
Files: src/config.mk.in, src/po/Makefile
*** ../vim-7.4.321/src/config.mk.in 2010-11-03 22:26:24.0 +0100
--- src/config.mk.in2014-06-12 17:41:12.892268607 +0200
***
*** 164,169
--- 164,171
### If the *.po files are to be translated to *.mo files.
MAKEMO= @MAKEMO@
+ MSGFMT= @MSGFMT@
+
# Make sure that make first will run make all once configure has done its
# work. This is needed when using the Makefile in the top directory.
first: all
*** ../vim-7.4.321/src/po/Makefile 2013-06-23 13:26:12.0 +0200
--- src/po/Makefile 2014-06-12 17:45:19.116277922 +0200
***
*** 1,5
--- 1,8
# Makefile for the Vim message translations.
+ # Include stuff found by configure.
+ include ../auto/config.mk
+
# TODO make this configurable
# Note: ja.sjis, *.cp1250 and zh_CN.cp936 are only for MS-Windows, they are
# not installed on Unix
***
*** 133,139
# tools 0.10.37, which use a slightly different .po file format that is not
# compatible with Solaris (and old gettext implementations) unless these are
# set. gettext 0.10.36 will not work!
! MSGFMT = OLD_PO_FILE_INPUT=yes msgfmt -v
XGETTEXT = OLD_PO_FILE_INPUT=yes OLD_PO_FILE_OUTPUT=yes xgettext
MSGMERGE = OLD_PO_FILE_INPUT=yes OLD_PO_FILE_OUTPUT=yes msgmerge
--- 136,142
# tools 0.10.37, which use a slightly different .po file format that is not
# compatible with Solaris (and old gettext implementations) unless these are
# set. gettext 0.10.36 will not work!
! MSGFMTCMD = OLD_PO_FILE_INPUT=yes $(MSGFMT) -v
XGETTEXT = OLD_PO_FILE_INPUT=yes OLD_PO_FILE_OUTPUT=yes xgettext
MSGMERGE = OLD_PO_FILE_INPUT=yes OLD_PO_FILE_OUTPUT=yes msgmerge
***
*** 142,148
.PHONY: all install uninstall prefixcheck converted check clean checkclean
distclean update-po $(LANGUAGES) $(CONVERTED)
.po.mo:
! $(MSGFMT) -o $@ $
.po.ck:
$(VIM) -u NONE -e -X -S check.vim -c if error == 0 | q | endif -c cq
$
--- 145,151
.PHONY: all install uninstall prefixcheck converted check clean checkclean
distclean update-po $(LANGUAGES) $(CONVERTED)
.po.mo:
! $(MSGFMTCMD) -o $@ $
.po.ck:
$(VIM) -u NONE -e -X -S check.vim -c if error == 0 | q | endif -c cq
$
*** ../vim-7.4.321/src/version.c2014-06-12 16:03:24.268046589 +0200
--- src/version.c 2014-06-12 17:42:27.584271433 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 322,
/**/
--
If I tell you you have a beautiful body, would you hold it against me?
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.323
Patch 7.4.323
Problem:Substitute() with zero width pattern breaks multi-byte character.
Solution: Take multi-byte character size into account. (Yukihiro Nakadaira)
Files: src/eval.c src/testdir/test69.in, src/testdir/test69.ok
*** ../vim-7.4.322/src/eval.c 2014-05-28 20:31:37.496292805 +0200
--- src/eval.c 2014-06-12 18:34:22.928389291 +0200
***
*** 24848,24855
if (zero_width == regmatch.startp[0])
{
/* avoid getting stuck on a match with an empty string */
! *((char_u *)ga.ga_data + ga.ga_len) = *tail++;
! ++ga.ga_len;
continue;
}
zero_width = regmatch.startp[0];
--- 24848,24858
if (zero_width == regmatch.startp[0])
{
/* avoid getting stuck on a match with an empty string */
! i = MB_PTR2LEN(tail);
! mch_memmove((char_u *)ga.ga_data + ga.ga_len, tail,
! (size_t)i);
! ga.ga_len += i;
! tail += i;
continue;
}
zero_width = regmatch.startp[0];
*** ../vim-7.4.322/src/testdir/test69.in2014-02-22 23:49:30.268896843
+0100
--- src/testdir/test69.in 2014-06-12 18:32:43.108385514 +0200
***
*** 180,185
--- 180,192
byteidxcomp
STARTTEST
+ /^substitute
+ :let y = substitute('１２３', '\zs', 'a', 'g')| put =y
+ ENDTEST
+
+ substitute
+
+ STARTTEST
:g/^STARTTEST/.,/^ENDTEST/d
:1;/^Results/,$wq! test.out
ENDTEST
*** ../vim-7.4.322/src/testdir/test69.ok2014-02-22 23:49:30.268896843
+0100
--- src/testdir/test69.ok 2014-06-12 18:32:43.108385514 +0200
***
*** 160,162
--- 160,166
[0, 1, 3, 4, -1]
[0, 1, 2, 4, 5, -1]
+
+ substitute
+ a１a２a３a
+
*** ../vim-7.4.322/src/version.c2014-06-12 18:03:24.940319000 +0200
--- src/version.c 2014-06-12 18:32:08.356384200 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 323,
/**/
--
When danger reared its ugly head,
He bravely turned his tail and fled
Yes, Brave Sir Robin turned about
And gallantly he chickened out
Bravely taking to his feet
He beat a very brave retreat
Bravest of the brave Sir Robin
Petrified of being dead
Soiled his pants then brave Sir Robin
Turned away and fled.
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Can't input 0xCE on windows console
Currently, last patch still has below's problems. * :imap a ﾎﾞ deson't work. replacing all ﾎﾞ into 1. * :call feedkeys(iﾎ\C-C) doesn't work because K_NUL 3 escape duplicatedly. So I suggest to modify termcap for windows. - Yasuhiro Matsumoto -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
Charles Campbell wrote: Charles Campbell wrote: v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: Vim: Caught deadly signal SEGV http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where junk.vim has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim separates from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches now... Hmm, apparently I was using an oddball version of vim that wasn't completely patched. So I've now rebuilt vim 7.4.320; using valgrind --log-file=gvim.out gvim -u junk.vim -U NONE macos The attached file contains the log. Vim crashed eventually, but it took a lot of j and k motions, sprinkled with the occasional L and G to get it. Would one of you tell me how best to apply gdb to gvim? I suppose I could run gvim and then attach gdb to it after its started. You have to run the GUI in the foreground. In gdb use run -f. Looks like somehow the data structures allocated for the screen don't match with the screen size. That's weird. It probably matters what the terminal size is you start with. Was that 24 x 80? -- GALAHAD turns back. We see from his POV the lovely ZOOT standing by him smiling enchantingly and a number of equally delectable GIRLIES draped around in the seductively poulticed room. They look at him smilingly and wave. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.324
Patch 7.4.324
Problem:In Ex mode, cyrillic characters are not handled. (Stas Malavin)
Solution: Support multi-byte characters in Ex mode. (Yukihiro Nakadaira)
Files: src/ex_getln.c
*** ../vim-7.4.323/src/ex_getln.c 2014-05-29 14:36:26.156862577 +0200
--- src/ex_getln.c 2014-06-12 19:33:10.440522741 +0200
***
*** 2188,2193
--- 2188,2194
int vcol = 0;
char_u*p;
int prev_char;
+ int len;
/* Switch cursor on now. This avoids that it happens after the \n,
which
* confuses the system function that computes tabstops. */
***
*** 2264,2270
{
if (line_ga.ga_len 0)
{
! --line_ga.ga_len;
goto redraw;
}
continue;
--- 2265,2281
{
if (line_ga.ga_len 0)
{
! #ifdef FEAT_MBYTE
! if (has_mbyte)
! {
! p = (char_u *)line_ga.ga_data;
! p[line_ga.ga_len] = NUL;
! len = (*mb_head_off)(p, p + line_ga.ga_len - 1) + 1;
! line_ga.ga_len -= len;
! }
! else
! #endif
! --line_ga.ga_len;
goto redraw;
}
continue;
***
*** 2280,2286
if (c1 == Ctrl_T)
{
! longsw = get_sw_value(curbuf);
p = (char_u *)line_ga.ga_data;
p[line_ga.ga_len] = NUL;
--- 2291,2297
if (c1 == Ctrl_T)
{
! longsw = get_sw_value(curbuf);
p = (char_u *)line_ga.ga_data;
p[line_ga.ga_len] = NUL;
***
*** 2300,2307
/* redraw the line */
msg_col = startcol;
vcol = 0;
! for (p = (char_u *)line_ga.ga_data;
! p (char_u *)line_ga.ga_data + line_ga.ga_len; ++p)
{
if (*p == TAB)
{
--- 2311,2319
/* redraw the line */
msg_col = startcol;
vcol = 0;
! p = (char_u *)line_ga.ga_data;
! p[line_ga.ga_len] = NUL;
! while (p (char_u *)line_ga.ga_data + line_ga.ga_len)
{
if (*p == TAB)
{
***
*** 2309,2319
{
msg_putchar(' ');
} while (++vcol % 8);
}
else
{
! msg_outtrans_len(p, 1);
! vcol += char2cells(*p);
}
}
msg_clr_eos();
--- 2321,2334
{
msg_putchar(' ');
} while (++vcol % 8);
+ ++p;
}
else
{
! len = MB_PTR2LEN(p);
! msg_outtrans_len(p, len);
! vcol += ptr2cells(p);
! p += len;
}
}
msg_clr_eos();
***
*** 2362,2368
if (IS_SPECIAL(c1))
c1 = '?';
! ((char_u *)line_ga.ga_data)[line_ga.ga_len] = c1;
if (c1 == '\n')
msg_putchar('\n');
else if (c1 == TAB)
--- 2377,2392
if (IS_SPECIAL(c1))
c1 = '?';
! #ifdef FEAT_MBYTE
! if (has_mbyte)
! len = (*mb_char2bytes)(c1,
! (char_u *)line_ga.ga_data + line_ga.ga_len);
! else
! #endif
! {
! len = 1;
! ((char_u *)line_ga.ga_data)[line_ga.ga_len] = c1;
! }
if (c1 == '\n')
msg_putchar('\n');
else if (c1 == TAB)
***
*** 2376,2385
else
{
msg_outtrans_len(
!((char_u *)line_ga.ga_data) + line_ga.ga_len, 1);
vcol += char2cells(c1);
}
! ++line_ga.ga_len;
escaped = FALSE;
windgoto(msg_row, msg_col);
--- 2400,2409
else
{
msg_outtrans_len(
!((char_u *)line_ga.ga_data) + line_ga.ga_len, len);
vcol += char2cells(c1);
}
! line_ga.ga_len += len;
escaped = FALSE;
windgoto(msg_row, msg_col);
*** ../vim-7.4.323/src/version.c2014-06-12 18:39:16.828400409 +0200
--- src/version.c 2014-06-12 19:37:40.296532950 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 324,
/**/
--
ZOOT: I'm afraid our life must seem
Re: Highlighting artefacts / glitches prompted by low updatetime
On Thursday, June 12, 2014 12:54:14 PM UTC+2, bo...@airbladesoftware.com wrote:
Hello!
I have a plugin which updates signs when a CursorHold auto-command fires
(among other auto-commands). When `updatetime` is set to a low value, say
anything under 100, and highlighting is in effect, I see highlighting
glitches on many individual characters: specifically the foreground and
background colours differ from the characters around them.
Here's how I (and hopefully you) can reproduce the problem:
$ cd
$ mv .vimrc vimrc
$ cat .vimrc EOF
set updatetime=50
syntax enable
EOF
$ mv .vim vim
$ mkdir .vim
$ cp -r vim/bundle/vim-gitgutter/{autoload,plugin} .vim
The last step assumes you already have vim-gitgutter
(https://github.com/airblade/vim-gitgutter) installed.
Then edit a file which triggers syntax highlighting and make some changes.
At this point I always see a number of highlighting glitches. They can be
cleared with a redraw.
As far as I can tell, the specific filetype doesn't matter. When I edit a
plain text file, it's only when I specify a filetype which causes some
highlighting that the glitches start.
I used the HiLinkTrace plugin to investigate whether the characters with
glitches have different highlights from their neighbours. It didn't report
any differences, which leads me to think that the highlight settings haven't
been changed; instead there's a bug in the rendering.
I'm using Vim 7.4.258, specifically MacVim. I get the glitches in the
terminal version (mvim -v) but not the gui version. Other people on
different OS's have reported the same problem, always in terminal vim.
At this point I've investigated as far as I can. Any help would be much
appreciated!
Thanks in advance,
Andrew Stewart
I'm using vim-gitgutter and can confirm that these glitches are annoying.
Here is a simpler Vim invocation without the need to change your .vimrc or .vim
folder to reproduce:
vim -Nu (echo 'syntax enable | set updatetime=50
rtp+=~/.vim/bundle/vim-gitgutter/')
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Can't input 0xCE on windows console
Yasuhiro Matsumoto wrote: Currently, last patch still has below's problems. * :imap a ﾎﾞ deson't work. replacing all ﾎﾞ into 1. * :call feedkeys(iﾎ\C-C) doesn't work because K_NUL 3 escape duplicatedly. So I suggest to modify termcap for windows. What exactly are those characters in hex? And what encoding is Vim set to when the problem happens? The patch which was sent previously had another problem, thus I haven't included it. -- Linux is just like a wigwam: no Windows, no Gates and an Apache inside. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Issue 231 in vim: netrw silently closing buffers on its own
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 231 by johnston...@gmail.com: netrw silently closing buffers on its own http://code.google.com/p/vim/issues/detail?id=231 After upgrading macvim from 7.3 to 7.4, netrw is closing buffers on its own. What steps will reproduce the problem? 1. :Explore, navigate directories, open a file 2. :Explore, open another file 3. Buffer opened in step 1 will be closed. What is the expected output? What do you see instead? I expect both buffers to exist, but only the last one does. What version of the product are you using? On what operating system? Macvim 7.4 snapshot 73 for Moutain Lion. netrw v153i (noticed the same behavior with v151 so I upgraded to latest netrw) Please provide any additional information below. Not a problem with macvim 7.3. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 231 in vim: netrw silently closing buffers on its own
On Thu, Jun 12, 2014 at 06:21:06PM +, v...@googlecode.com wrote: Status: New Owner: Labels: Type-Defect Priority-Medium New issue 231 by johnston...@gmail.com: netrw silently closing buffers on its own http://code.google.com/p/vim/issues/detail?id=231 After upgrading macvim from 7.3 to 7.4, netrw is closing buffers on its own. What steps will reproduce the problem? 1. :Explore, navigate directories, open a file 2. :Explore, open another file 3. Buffer opened in step 1 will be closed. What is the expected output? What do you see instead? I expect both buffers to exist, but only the last one does. What version of the product are you using? On what operating system? Macvim 7.4 snapshot 73 for Moutain Lion. netrw v153i (noticed the same behavior with v151 so I upgraded to latest netrw) Please provide any additional information below. Not a problem with macvim 7.3. not a problem with linux vim 7.4.324, netrw v151 -- _|_ _ __|_|_ ._ o| |_(_)(_)|_| ||_)|| | -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
Bram Moolenaar wrote: Charles Campbell wrote: Charles Campbell wrote: v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: Vim: Caught deadly signal SEGV http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where junk.vim has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim separates from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches now... Hmm, apparently I was using an oddball version of vim that wasn't completely patched. So I've now rebuilt vim 7.4.320; using valgrind --log-file=gvim.out gvim -u junk.vim -U NONE macos The attached file contains the log. Vim crashed eventually, but it took a lot of j and k motions, sprinkled with the occasional L and G to get it. Would one of you tell me how best to apply gdb to gvim? I suppose I could run gvim and then attach gdb to it after its started. You have to run the GUI in the foreground. In gdb use run -f. Looks like somehow the data structures allocated for the screen don't match with the screen size. That's weird. It probably matters what the terminal size is you start with. Was that 24 x 80? The terminal I used to kick off gvim was 253x37. I'm using vim 7.4.320 on a Scientific Linux 6.5 system. My configure command is: ./configure --with-features=huge --enable-gui=gtk2--enable-perlinterp --enable-pythoninterp --enable-cscope Regards, Chip Campbell -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 231 in vim: netrw silently closing buffers on its own
Comment #1 on issue 231 by drc...@campbellfamily.biz: netrw silently closing buffers on its own http://code.google.com/p/vim/issues/detail?id=231 I tried this with vim 7.4.320 and netrw v153i and was unable to duplicate the problem. I used the following command: vim -u netrw.vimrc . along with the file netrw.vimrc, which has two lines: set nocp so $HOME/.vim/plugin/netrwPlugin.vim Please try this on your mac using the vimrc file as shown. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
On Do, 12 Jun 2014, Bram Moolenaar wrote:
Looks like somehow the data structures allocated for the screen don't
match with the screen size. That's weird.
It's not the screen size, that seems to be correct.
The problem is, set ls=2. This causes a recursive call to win_new_height() and
therefore does not adjust the window height correctly.
This patch fixes it for me:
diff --git a/src/window.c b/src/window.c
--- a/src/window.c
+++ b/src/window.c
@@ -5650,7 +5650,10 @@ win_new_height(wp, height)
if (wp-w_height 0)
{
if (wp == curwin)
- validate_cursor(); /* w_wrow needs to be valid */
+ /* w_wrow needs to be valid, might call win_new_height recursively... */
+ validate_cursor();
+ if (wp-w_height != prev_height)
+ return; /* recursive call already changed window size */
if (wp-w_wrow != wp-w_prev_fraction_row)
set_fraction(wp);
}
Best,
Christian
--
Es ist nicht halb so ungesund, Philosophie zu lehren, als zu lernen,
e(ine) Philos(ophie) zu machen als zu lesen.
-- Jean Paul
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: Vim: Caught deadly signal SEGV
Charles E Campbell wrote: Bram Moolenaar wrote: Charles Campbell wrote: Charles Campbell wrote: v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: Vim: Caught deadly signal SEGV http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where junk.vim has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim separates from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches now... Hmm, apparently I was using an oddball version of vim that wasn't completely patched. So I've now rebuilt vim 7.4.320; using valgrind --log-file=gvim.out gvim -u junk.vim -U NONE macos The attached file contains the log. Vim crashed eventually, but it took a lot of j and k motions, sprinkled with the occasional L and G to get it. Would one of you tell me how best to apply gdb to gvim? I suppose I could run gvim and then attach gdb to it after its started. You have to run the GUI in the foreground. In gdb use run -f. Looks like somehow the data structures allocated for the screen don't match with the screen size. That's weird. It probably matters what the terminal size is you start with. Was that 24 x 80? The terminal I used to kick off gvim was 253x37. I'm using vim 7.4.320 on a Scientific Linux 6.5 system. My configure command is: ./configure --with-features=huge --enable-gui=gtk2--enable-perlinterp --enable-pythoninterp --enable-cscope I tried this operation again with different initial terminal sizes. * terminal: 125x37 -- I get no status line and eventually I get a SIGSEGV * terminal: 50 x 20 -- I get a status line and haven't seen a SIGSEGV * I restored the terminal to 125x37, but this time I used the mouse to grab the corner and expand the gvim screen. I pull it down just one line and the status line appears, and I haven't been able to get it to core dump based on cursor movement. Regards, Chip -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] fixing display of signs in GTK builds
Hi Bram!
On Do, 12 Jun 2014, Bram Moolenaar wrote:
Christian wrote:
Bram,
I noticed, when displaying icon signs in the gui version of Vim there
might be a small line not overdrawn by the sign, caused by the
'linespace' setting set to be one. That does look rather ugly, if you
display several signs side by side (see attached screenshot).
Do you mean that the dark line below the + sign should not be there?
And if 'linespace' is set to zero that black line is indeed gone?
It goes away, if I set linespace to -1. But that has other screen
problems.
Here is a patch. A couple of comments:
1) I am not sure, why a call to gdk_draw_rectangle() is done in the
existing code. I have left it out as it seems to be unnecessary
I believe this is needed to first clear the area with the background
color, in case the icon drawn is smaller than the available space.
Perhaps you can try it with a rectangular icon, vertically and
horizontally. E.g. something like a red exclamation mark. There would
need to be some other sign at first to see any effect.
I used an rectangular icon. But you are right, this was probably done
for making sure, transparent icons are drawn correctly. I thought about
using transparent signs, but I don not want to use different icons for
different builts (e.g. png for GTK and bmp for Windows), so I usually
use the same icon everywhere.
2) not sure, why a height of 127 was hard coded when drawing the size
area. I have used the actual sign size for that
The 127 is the value for alpha_threshold. At least according to the
documentation I found.
Ah my bad, I got confused by the non_alpha function.
3) when the sign hight differs from the char_height, it will always be
rescaled. This of course has the additional disadvantage of causing a
performance issue. Not sure, if this is noticeable, though.
I don't think we should worry about performance.
It appears that after your change the aspect ratio of the sign is not
kept. Although that would be OK for filling the gap, if the sign was
really a different shape it would look weird. In your specific case you
would want the sign to fill the available space and probably don't care
about keeping the aspect ratio. Adding a setting for this woule make it
complicated...
How about this: if we can fill the available space with a slightly
different ascpect ratio, e.g., 10% different, filling the gap is nicer
than the slightly different aspect ratio. If we change the aspect ratio
more than 10% or so the icon will start looking weird and we stick to
the aspect ratio and as a result there will be a gap (either vertically
or horizontally).
The names are a bit confusing, SIGN_ASPECT actually means the aspect
ratio of the space availeble, with aspect is the aspect ratio of the
sign being drawn.
This also very much depends on the font size, since the space used for
the icon is two character cells wide and one character cell plus
'linespace' high.
Okay, how about the attached patch (it allows 15% deviation to the
aspect ratio (so one can change linespace value by at most 2 for a sign
of 16x16 pixel and the sign will be completely filled)
Best,
Christian
--
Kennst Du den Unterschied zwischen einem Arbeitslosen und einem Beamten?
Arbeitslose haben schon einmal gearbeitet.
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/gui_gtk_x11.c b/src/gui_gtk_x11.c
--- a/src/gui_gtk_x11.c
+++ b/src/gui_gtk_x11.c
@@ -5967,25 +5967,42 @@ gui_mch_drawsign(int row, int col, int t
* tiny differences in font size.
*/
need_scale = (width SIGN_WIDTH + 2
- || height SIGN_HEIGHT + 2
+ || height != SIGN_HEIGHT /* might differ because of linespaceing */
|| (width 3 * SIGN_WIDTH / 4
height 3 * SIGN_HEIGHT / 4));
if (need_scale)
{
double aspect;
+ int w = width;
+ int h = height;
/* Keep the original aspect ratio */
aspect = (double)height / (double)width;
width = (double)SIGN_WIDTH * SIGN_ASPECT / aspect;
width = MIN(width, SIGN_WIDTH);
- height = (double)width * aspect;
-
- /* This doesn't seem to be worth caching, and doing so
- * would complicate the code quite a bit. */
- sign = gdk_pixbuf_scale_simple(sign, width, height,
- GDK_INTERP_BILINEAR);
- if (sign == NULL)
- return; /* out of memory */
+ if (((double)(MAX(height, SIGN_HEIGHT)) /
+ (double)(MIN(height, SIGN_HEIGHT))) 1.15)
+ {
+ /* allow to change the aspect ratio by at most 15%
[PATCH] Make i( and i[ text objects behave like i{
There's an exception to the i{ text object that ignores ignores leading
whitespace before the final } character. I think it would be useful if this
extended to the i( and i[ text objects as well. In particular, as a PHP
developer, I run into code like this a lot:
$foo = array(
'one' = 'some value',
'two' = 'some other value',
'three' = 'yet another value',
);
With the current implementation, the i( object is not very useful when there is
indentation before the closing ) character. Typing ci( would leave me here
(cursor marked by a | character):
$foo = array(
|);
This is never useful to me, and requires a great deal more effort to accomplish
what I was hoping for.
My patch extends the exception used in i{ to i( and i[ as well. While I
personally don't have a use case for this behaviour in i[, I think it's easy to
agree that it should behave the same way as its brackety companions.
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff -r bed71c37618c src/search.c
--- a/src/search.c Thu May 29 14:36:29 2014 +0200
+++ b/src/search.c Thu Jun 12 13:24:42 2014 -0400
@@ -3608,7 +3608,8 @@
/*
* Try to exclude the '(', '{', ')', '}', etc. when include is FALSE.
- * If the ending '}' is only preceded by indent, skip that indent.
+ * If the ending '}', ')', or ']' is only preceded by indent, skip that
+ * indent.
* But only if the resulting area is not smaller than what we started with.
*/
while (!include)
@@ -3616,7 +3617,7 @@
incl(start_pos);
sol = (curwin-w_cursor.col == 0);
decl(curwin-w_cursor);
- if (what == '{')
+ if (what == '{' || what == '(' || what == '[')
while (inindent(1))
{
sol = TRUE;
Issue 232 in vim: AWK syntax highliting slash operator turns into regexp
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 232 by pletiplo...@gmail.com: AWK syntax highliting slash
operator turns into regexp
http://code.google.com/p/vim/issues/detail?id=232
{
printf(%f %f, a+(1/b), c/3)
}
/b), c/ highligts as a regexp, but it is a normal division. Then braces get
broken in whole file (because one brace gets stuck in the regexp).
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
