Re: Patch 7.4.829
Hi,
Bram Moolenaar schrieb am 25.08.2015 um 12:27:
>
> Patch 7.4.829
> Problem:Crash when clicking in beval balloon. (Travis Lebsock)
> Solution: Use PostMessage() instead of DestroyWindow(). (Raymond Ko, PR 298)
> Files: src/gui_w32.c
>
>
> *** ../vim-7.4.828/src/gui_w32.c 2015-08-11 19:13:55.138175689 +0200
> --- src/gui_w32.c 2015-08-25 12:20:08.668726500 +0200
> ***
> *** 4836,4842
> delete_tooltip(beval)
> BalloonEval *beval;
> {
> ! DestroyWindow(beval->balloon);
> }
>
> /*ARGSUSED*/
> --- 4836,4843
> delete_tooltip(beval)
> BalloonEval *beval;
> {
> ! PostMessage(beval->balloon, WM_DESTROY, 0, 0);
> ! PostMessage(beval->balloon, WM_NCDESTROY, 0, 0);
> }
>
> /*ARGSUSED*/
> *** ../vim-7.4.828/src/version.c 2015-08-25 11:57:45.026505650 +0200
> --- src/version.c 2015-08-25 12:18:39.021646821 +0200
> ***
> *** 743,744
> --- 743,746
> { /* Add new patch number below this line */
> + /**/
> + 829,
> /**/
>
this fixes the crash, but now the hints are not removed anymore and stay
visible. An additional
PostMessage(beval->balloon, WM_CLOSE, 0, 0);
at the start of delete_tooltip() seems to make it work correctly.
Regards,
Jürgen
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
--
--
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: Question regarding :normal
On Wednesday, 26 August 2015 01:31:34 UTC-4, Justin M. Keyes wrote: > On Tue, Aug 25, 2015 at 10:00 PM, Quinn Strahl wrote: > > A difference in behaviour between :g and :normal recently frustrated > > me, and I wonder if it's up for debate: > > > > :g does a pass on matching lines and marks them before performing the > > operation; this allows it to be generally undeterred by operations that > > include addition/deletion of lines. > > > > :normal does not do this, and as a result, it can get "thrown off" > > by such operations. For (a trivial) example, on the hypothetical file: > > > > foo > > bar > > baz > > > > Performing :1,3normal yyp would produce the following result: > > > > foo > > foo > > foo > > foo > > bar > > baz > > > > Whereas the more intuitive result would be: > > > > foo > > foo > > bar > > bar > > baz > > baz > > > > There does exist a workaround, in the form of :g/^/normal yyp -- > > simply using :g in a way guaranteed to match every line in the desired > > range -- but this is a bit of a compositional kludge. > > > > Would it be feasible to add the marking behaviour of :g to :normal, or is > > that not worth implementing / a feature? > > Why do you want them to behave the same? They serve different > purposes. Or rather, :g serves a purpose, and :normal is behaving in > the typical way for a range command that performs edits/changes. > > > Justin M. Keyes I have on many occasions run into situations where it would be very handy if :normal worked the way :g does with respect to how it handles changes in number of lines during operation, and I have not run into any case (nor can I imagine one) where the current behaviour is favourable. It seems less intuitive and less useful for it to behave this way. -- -- 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: Question regarding :normal
Quinn Strahl wrote: > On Wednesday, 26 August 2015 01:31:34 UTC-4, Justin M. Keyes wrote: >> On Tue, Aug 25, 2015 at 10:00 PM, Quinn Strahl wrote: >>> A difference in behaviour between :g and :normal recently frustrated >>> me, and I wonder if it's up for debate: >>> >>> :g does a pass on matching lines and marks them before performing the >>> operation; this allows it to be generally undeterred by operations that >>> include addition/deletion of lines. >>> >>> :normal does not do this, and as a result, it can get "thrown off" >>> by such operations. For (a trivial) example, on the hypothetical file: >>> >>> foo >>> bar >>> baz >>> >>> Performing :1,3normal yyp would produce the following result: >>> >>> foo >>> foo >>> foo >>> foo >>> bar >>> baz >>> >>> Whereas the more intuitive result would be: >>> >>> foo >>> foo >>> bar >>> bar >>> baz >>> baz >>> >>> There does exist a workaround, in the form of :g/^/normal yyp -- >>> simply using :g in a way guaranteed to match every line in the desired >>> range -- but this is a bit of a compositional kludge. >>> >>> Would it be feasible to add the marking behaviour of :g to :normal, or is >>> that not worth implementing / a feature? >> Why do you want them to behave the same? They serve different >> purposes. Or rather, :g serves a purpose, and :normal is behaving in >> the typical way for a range command that performs edits/changes. >> >> >> Justin M. Keyes > I have on many occasions run into situations where it would be very handy if > :normal worked the way :g does with respect to how it handles changes in > number of lines during operation, and I have not run into any case (nor can I > imagine one) where the current behaviour is favourable. It seems less > intuitive and less useful for it to behave this way. > Why not use :[range]g/pattern/norm whatever 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: Mail from Vim Github Repository
On Mo, 24 Aug 2015, Alejandro Exojo wrote: > El Monday 24 August 2015, Christian Brabandt escribió: > > I am not going to start rewriting mails, that are sent from github. It's > > just a simple forwarding, since the original github notification mail is > > rejected by the google groups page. > > Note that the sender name is lost as well. It's difficult to read who said > what, so one would want to click on the link and read it on the web anyway. That should be fixed now. The authors name should be still in the from along with '(Vim Github Repository). Also I added an Mail-Followup-To header, so depending on the reply method you use, a reply might end up at github as well (which needs to be tested). Best, Christian -- Wo ich aufhören muss, sittlich zu sein, habe ich keine Gewalt mehr. -- Goethe, Maximen und Reflektionen, Nr. 141 -- -- 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: Question regarding :normal
On Wednesday, 26 August 2015 12:15:44 UTC-4, Charles Campbell wrote: > Quinn Strahl wrote: > > On Wednesday, 26 August 2015 01:31:34 UTC-4, Justin M. Keyes wrote: > >> On Tue, Aug 25, 2015 at 10:00 PM, Quinn Strahl wrote: > >>> A difference in behaviour between :g and :normal recently > >>> frustrated me, and I wonder if it's up for debate: > >>> > >>> :g does a pass on matching lines and marks them before performing the > >>> operation; this allows it to be generally undeterred by operations that > >>> include addition/deletion of lines. > >>> > >>> :normal does not do this, and as a result, it can get "thrown off" > >>> by such operations. For (a trivial) example, on the hypothetical file: > >>> > >>> foo > >>> bar > >>> baz > >>> > >>> Performing :1,3normal yyp would produce the following result: > >>> > >>> foo > >>> foo > >>> foo > >>> foo > >>> bar > >>> baz > >>> > >>> Whereas the more intuitive result would be: > >>> > >>> foo > >>> foo > >>> bar > >>> bar > >>> baz > >>> baz > >>> > >>> There does exist a workaround, in the form of :g/^/normal yyp -- > >>> simply using :g in a way guaranteed to match every line in the desired > >>> range -- but this is a bit of a compositional kludge. > >>> > >>> Would it be feasible to add the marking behaviour of :g to :normal, or is > >>> that not worth implementing / a feature? > >> Why do you want them to behave the same? They serve different > >> purposes. Or rather, :g serves a purpose, and :normal is behaving in > >> the typical way for a range command that performs edits/changes. > >> > >> > >> Justin M. Keyes > > I have on many occasions run into situations where it would be very handy > > if :normal worked the way :g does with respect to how it handles changes in > > number of lines during operation, and I have not run into any case (nor can > > I imagine one) where the current behaviour is favourable. It seems less > > intuitive and less useful for it to behave this way. > > > Why not use > > :[range]g/pattern/norm whatever > > Regards, > Chip Campbell That's the workaround I'm using right now, but there are many cases where I want to operate on every line in the range, forcing me to use something like my previous example: :g/^/norm whatever It feels hacky; I'm essentially trying to avoid what is arguably the primary function of :g (matching a subset of lines) just to get that line-marking behaviour for the :normal operation. It makes me wonder, is there any reason for :normal to lack that behaviour? It seems like an objective improvement. -- -- 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 7.4.833
On 26-Aug-2015 5:27 AM, Bram Moolenaar wrote: John Marriott wrote: On 25-Aug-2015 11:40 PM, Bram Moolenaar wrote: > > Patch 7.4.833 > Problem:More side effects of ":set all&" are missing. (Björn Linse) > Solution: Call didset_options() and add didset_options2() to collect more > side effects to take care of. Still not everything... > Files: src/option.c > > This patch fails to compile on Win64 (both gui and not) with FEAT_CRYPT undefined, like so: gcc -c -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 -DHAVE_PATHDEF -DFEAT_BIG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD - DFEAT_MBYTE -pipe -w -march=native -Wall -O3 -fomit-frame-pointer -freg-struct-return -s gui_w32.c -o gobjnative/gui_w32 .o option.c: In function 'set_options_default': option.c:3657:36: error: 'p_cm' undeclared (first use in this function) && options[i].var != (char_u *)&p_cm ^ option.c:3657:36: note: each undeclared identifier is reported only once for each function it appears in option.c:3658:36: error: 'p_key' undeclared (first use in this function) && options[i].var != (char_u *)&p_key))) ^ Make_cyg_ming.mak:781: recipe for target 'gobjnative/option.o' failed make: *** [gobjnative/option.o] Error 1 make: *** Waiting for unfinished jobs Sorry, I'll add an #ifdef Hey Bram, After 7.4.838, I can compile without crypt. Thanks. But after 7.4.830, 7.4.833 and 7.4.838, the compile fails if FEAT_MBYTE is undefined, like so (non-gui under HP-UX): Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src && make first cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/buffer.o buffer.c cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/eval.o eval.c cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/ex_cmds.o ex_cmds.c cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/ex_cmds2.o ex_cmds2.c cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/hardcopy.o hardcopy.c cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/if_xcmdsrv.o if_xcmdsrv.c cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/misc1.o misc1.c cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/misc2.o misc2.c cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/option.o option.c cc: "option.c", line 3656: error 1588: "p_enc" undefined. cc: "option.c", line 3656: error 1527: Incompatible types in cast: Must cast from scalar to scalar or to void type. *** Error exit code 1 Stop. *** Error exit code 1 Stop. -- -- 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.839
Patch 7.4.839
Problem:Compiler warning on 64-bit system.
Solution: Add cast to int. (Mike Williams)
Files: src/search.c
*** ../vim-7.4.838/src/search.c 2015-08-13 23:28:38.246878308 +0200
--- src/search.c2015-08-26 22:58:31.183512457 +0200
***
*** 1801,1807
for (p = linep + startpos->col + 1; *p && *p != '('; ++p)
;
delim_len = (p - linep) - startpos->col - 1;
! delim_copy = vim_strnsave(linep + startpos->col + 1, delim_len);
if (delim_copy == NULL)
return FALSE;
for (lnum = startpos->lnum; lnum <= endpos->lnum; ++lnum)
--- 1801,1807
for (p = linep + startpos->col + 1; *p && *p != '('; ++p)
;
delim_len = (p - linep) - startpos->col - 1;
! delim_copy = vim_strnsave(linep + startpos->col + 1, (int)delim_len);
if (delim_copy == NULL)
return FALSE;
for (lnum = startpos->lnum; lnum <= endpos->lnum; ++lnum)
*** ../vim-7.4.838/src/version.c2015-08-25 21:27:31.312156958 +0200
--- src/version.c 2015-08-26 22:59:14.719028665 +0200
***
*** 743,744
--- 743,746
{ /* Add new patch number below this line */
+ /**/
+ 839,
/**/
--
Close your shells, or I'll kill -9 you
Tomorrow I'll quota you
Remember the disks'll always be full
And then while I'm away
I'll write ~ everyday
And I'll send-pr all my buggings to you.
[ CVS log "Beatles style" for FreeBSD ports/INDEX, Satoshi Asami ]
/// 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: Patch 7.4.829
Jürgen Krämer wrote:
> Bram Moolenaar schrieb am 25.08.2015 um 12:27:
> >
> > Patch 7.4.829
> > Problem:Crash when clicking in beval balloon. (Travis Lebsock)
> > Solution: Use PostMessage() instead of DestroyWindow(). (Raymond Ko, PR
> > 298)
> > Files: src/gui_w32.c
> >
> >
> > *** ../vim-7.4.828/src/gui_w32.c2015-08-11 19:13:55.138175689 +0200
> > --- src/gui_w32.c 2015-08-25 12:20:08.668726500 +0200
> > ***
> > *** 4836,4842
> > delete_tooltip(beval)
> > BalloonEval *beval;
> > {
> > ! DestroyWindow(beval->balloon);
> > }
> >
> > /*ARGSUSED*/
> > --- 4836,4843
> > delete_tooltip(beval)
> > BalloonEval *beval;
> > {
> > ! PostMessage(beval->balloon, WM_DESTROY, 0, 0);
> > ! PostMessage(beval->balloon, WM_NCDESTROY, 0, 0);
> > }
> >
> > /*ARGSUSED*/
> > *** ../vim-7.4.828/src/version.c2015-08-25 11:57:45.026505650 +0200
> > --- src/version.c 2015-08-25 12:18:39.021646821 +0200
> > ***
> > *** 743,744
> > --- 743,746
> > { /* Add new patch number below this line */
> > + /**/
> > + 829,
> > /**/
> >
>
> this fixes the crash, but now the hints are not removed anymore and stay
> visible. An additional
>
> PostMessage(beval->balloon, WM_CLOSE, 0, 0);
>
> at the start of delete_tooltip() seems to make it work correctly.
OK, I'll add that then.
--
There are only two hard things in programming: Cache invalidation,
naming things and off-by-one errors.
/// 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.840
Patch 7.4.840 (after 7.4.829)
Problem:Tooltip window stays open.
Solution: Send a WM_CLOSE message. (Jurgen Kramer)
Files: src/gui_w32.c
*** ../vim-7.4.839/src/gui_w32.c2015-08-25 12:21:23.583957205 +0200
--- src/gui_w32.c 2015-08-26 23:10:03.847838259 +0200
***
*** 4836,4841
--- 4836,4842
delete_tooltip(beval)
BalloonEval *beval;
{
+ PostMessage(beval->balloon, WM_CLOSE, 0, 0);
PostMessage(beval->balloon, WM_DESTROY, 0, 0);
PostMessage(beval->balloon, WM_NCDESTROY, 0, 0);
}
*** ../vim-7.4.839/src/version.c2015-08-26 23:01:16.453676957 +0200
--- src/version.c 2015-08-26 23:11:28.262906177 +0200
***
*** 743,744
--- 743,746
{ /* Add new patch number below this line */
+ /**/
+ 840,
/**/
--
A programmer's wife asks him: "Please run to the store and pick up a loaf of
bread. If they have eggs, get a dozen". The programmer comes home with 12
loafs of bread.
/// 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: Patch 7.4.833
John Marriott wrote: > On 26-Aug-2015 5:27 AM, Bram Moolenaar wrote: > > John Marriott wrote: > > > >> On 25-Aug-2015 11:40 PM, Bram Moolenaar wrote: > >> > > >> > Patch 7.4.833 > >> > Problem:More side effects of ":set all&" are missing. (Björn > >> Linse) > >> > Solution: Call didset_options() and add didset_options2() to collect > >> more > >> > side effects to take care of. Still not everything... > >> > Files: src/option.c > >> > > >> > > >> This patch fails to compile on Win64 (both gui and not) with FEAT_CRYPT > >> undefined, like so: > >> gcc -c -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 > >> -DHAVE_PATHDEF -DFEAT_BIG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD - > >> DFEAT_MBYTE -pipe -w -march=native -Wall -O3 -fomit-frame-pointer > >> -freg-struct-return -s gui_w32.c -o gobjnative/gui_w32 > >> .o > >> option.c: In function 'set_options_default': > >> option.c:3657:36: error: 'p_cm' undeclared (first use in this function) > >> && options[i].var != (char_u *)&p_cm > >> ^ > >> option.c:3657:36: note: each undeclared identifier is reported only once > >> for each function it appears in > >> option.c:3658:36: error: 'p_key' undeclared (first use in this function) > >> && options[i].var != (char_u *)&p_key))) > >> ^ > >> Make_cyg_ming.mak:781: recipe for target 'gobjnative/option.o' failed > >> make: *** [gobjnative/option.o] Error 1 > >> make: *** Waiting for unfinished jobs > > Sorry, I'll add an #ifdef > > > Hey Bram, > > After 7.4.838, I can compile without crypt. Thanks. > > But after 7.4.830, 7.4.833 and 7.4.838, the compile fails if FEAT_MBYTE > is undefined, like so (non-gui under HP-UX): > Starting make in the src directory. > If there are problems, cd to the src directory and run make there >cd src && make first >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/buffer.o buffer.c >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/eval.o eval.c >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/ex_cmds.o ex_cmds.c >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/ex_cmds2.o ex_cmds2.c >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/hardcopy.o hardcopy.c >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/if_xcmdsrv.o > if_xcmdsrv.c >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/misc1.o misc1.c >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/misc2.o misc2.c >cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/option.o option.c > cc: "option.c", line 3656: error 1588: "p_enc" undefined. > cc: "option.c", line 3656: error 1527: Incompatible types in cast: Must > cast from scalar to scalar or to void type. > *** Error exit code 1 Ah yes, p_enc is also an optional feature. I'll make a patch. -- A parent can be arrested if his child cannot hold back a burp during a church service. [real standing law in Nebraska, United States of America] /// 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.841
Patch 7.4.841
Problem:Can't compile without the multi-byte feature. (John Marriott)
Solution: Add more #ifdef's.
Files: src/option.c
*** ../vim-7.4.840/src/option.c 2015-08-25 21:27:31.312156958 +0200
--- src/option.c2015-08-26 23:18:39.122134709 +0200
***
*** 3652,3664
for (i = 0; !istermoption(&options[i]); i++)
if (!(options[i].flags & P_NODEFAULT)
&& (opt_flags == 0
! || (options[i].var != (char_u *)&p_enc
! #if defined(FEAT_CRYPT)
&& options[i].var != (char_u *)&p_cm
&& options[i].var != (char_u *)&p_key
#endif
! )))
set_option_default(i, opt_flags, p_cp);
#ifdef FEAT_WINDOWS
--- 3652,3670
for (i = 0; !istermoption(&options[i]); i++)
if (!(options[i].flags & P_NODEFAULT)
+ #if defined(FEAT_MBYTE) || defined(FEAT_CRYPT)
&& (opt_flags == 0
! || (TRUE
! # if defined(FEAT_MBYTE)
! && options[i].var != (char_u *)&p_enc
! # endif
! # if defined(FEAT_CRYPT)
&& options[i].var != (char_u *)&p_cm
&& options[i].var != (char_u *)&p_key
+ # endif
+ ))
#endif
! )
set_option_default(i, opt_flags, p_cp);
#ifdef FEAT_WINDOWS
*** ../vim-7.4.840/src/version.c2015-08-26 23:12:32.730194785 +0200
--- src/version.c 2015-08-26 23:22:20.295676696 +0200
***
*** 743,744
--- 743,746
{ /* Add new patch number below this line */
+ /**/
+ 841,
/**/
--
So when I saw the post to comp.editors, I rushed over to the FTP site to
grab it. So I yank apart the tarball, light x candles, where x= the
vim version multiplied by the md5sum of the source divided by the MAC of
my NIC (8A3FA78155A8A1D346C3C4A), put on black robes, dim the lights,
wave a dead chicken over the hard drive, and summon the power of GNU GCC
with the magic words "make config ; make!".
[Jason Spence, compiling Vim 5.0]
/// 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: Patch 7.4.840
Hi,
Based on the following posts:
http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/07/27/443824.aspx
sending a WM_CLOSE and WM_NCDESTROY message to a window is not
the same as calling DestroyWindow(). So I think the original fix (patch 829)
for the crash is not correct.
- Yegappan
On Wed, Aug 26, 2015 at 2:12 PM, Bram Moolenaar wrote:
>
> Patch 7.4.840 (after 7.4.829)
> Problem:Tooltip window stays open.
> Solution: Send a WM_CLOSE message. (Jurgen Kramer)
> Files: src/gui_w32.c
>
>
> *** ../vim-7.4.839/src/gui_w32.c2015-08-25 12:21:23.583957205 +0200
> --- src/gui_w32.c 2015-08-26 23:10:03.847838259 +0200
> ***
> *** 4836,4841
> --- 4836,4842
> delete_tooltip(beval)
> BalloonEval *beval;
> {
> + PostMessage(beval->balloon, WM_CLOSE, 0, 0);
> PostMessage(beval->balloon, WM_DESTROY, 0, 0);
> PostMessage(beval->balloon, WM_NCDESTROY, 0, 0);
> }
> *** ../vim-7.4.839/src/version.c2015-08-26 23:01:16.453676957 +0200
> --- src/version.c 2015-08-26 23:11:28.262906177 +0200
> ***
> *** 743,744
> --- 743,746
> { /* Add new patch number below this line */
> + /**/
> + 840,
> /**/
>
> --
--
--
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 7.4.840
On Wednesday, August 26, 2015 at 5:33:47 PM UTC-4, yega...@gmail.com wrote:
> Hi,
>
> Based on the following posts:
>
> http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx
> http://blogs.msdn.com/b/oldnewthing/archive/2005/07/27/443824.aspx
>
> sending a WM_CLOSE and WM_NCDESTROY message to a window is not
> the same as calling DestroyWindow(). So I think the original fix (patch 829)
> for the crash is not correct.
>
> - Yegappan
>
> On Wed, Aug 26, 2015 at 2:12 PM, Bram Moolenaar wrote:
> >
> > Patch 7.4.840 (after 7.4.829)
> > Problem:Tooltip window stays open.
> > Solution: Send a WM_CLOSE message. (Jurgen Kramer)
> > Files: src/gui_w32.c
> >
> >
> > *** ../vim-7.4.839/src/gui_w32.c2015-08-25 12:21:23.583957205 +0200
> > --- src/gui_w32.c 2015-08-26 23:10:03.847838259 +0200
> > ***
> > *** 4836,4841
> > --- 4836,4842
> > delete_tooltip(beval)
> > BalloonEval *beval;
> > {
> > + PostMessage(beval->balloon, WM_CLOSE, 0, 0);
> > PostMessage(beval->balloon, WM_DESTROY, 0, 0);
> > PostMessage(beval->balloon, WM_NCDESTROY, 0, 0);
> > }
> > *** ../vim-7.4.839/src/version.c2015-08-26 23:01:16.453676957 +0200
> > --- src/version.c 2015-08-26 23:11:28.262906177 +0200
> > ***
> > *** 743,744
> > --- 743,746
> > { /* Add new patch number below this line */
> > + /**/
> > + 840,
> > /**/
> >
> > --
You might be right. If WM_CLOSE does eventually does internally call
DestroyWindow() then the WM_DESTROY and WM_NCDESTROY might not be necessary. I
wonder if there is a way to verify that this is the case? The main issue is
that the code is crashing inside Microsoft's Common Controls DLL and I don't
think the source code for this is accessible.
--
--
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: Repository cleanup (Was: Preparations for moving to github)
On Tuesday, August 25, 2015 at 12:55:29 PM UTC-5, Markus Heidelberg wrote: > Am Dienstag, 25. August 2015, 17:42:26 schrieb Christian Brabandt: > > > > Did the .gitignore file change between the old googlecode repository and > > the new github repository? I get a modification here: > > > > diff --git a/.gitignore b/.gitignore > > --- a/.gitignore > > +++ b/.gitignore > > @@ -1,5 +1,3 @@ > > -# This is .gitignore > > - > > # Unixen: object and executable files. > > *.o > > src/vim > > While rewriting history during Git repo cleanup I took the opportunity > to replace the .hgignore with .gitignore, so that even if you go back in > time you benefit from the ignore list. > > I removed the HG specific "syntax: glob" and subsequent blank line > without adding this comment, which originates from the .gitignore in the > HG repo. > > > I can commit it in the mirror or you can fix it in the original ;) > > This wouldn't be a fix :) Since we have an hg mirror, how about keeping both files? -- -- 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: Mail from Vim Github Repository
On 26 August 2015, Christian Brabandt wrote: [...] > Also I added an Mail-Followup-To header, so depending on the reply > method you use, a reply might end up at github as well (which needs to > be tested). [...] Does Outlook pay attention to Mail-Followup-To these days? Does any recent mail client other than Mutt (and the now defunct Thunderbird) do it? /lcd -- -- 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 7.4.840
Hi,
On Wed, Aug 26, 2015 at 5:15 PM, Raymond Ko wrote:
> On Wednesday, August 26, 2015 at 5:33:47 PM UTC-4, yega...@gmail.com wrote:
>> Hi,
>>
>> Based on the following posts:
>>
>> http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx
>> http://blogs.msdn.com/b/oldnewthing/archive/2005/07/27/443824.aspx
>>
>> sending a WM_CLOSE and WM_NCDESTROY message to a window is not
>> the same as calling DestroyWindow(). So I think the original fix (patch 829)
>> for the crash is not correct.
>>
>> - Yegappan
>>
>> On Wed, Aug 26, 2015 at 2:12 PM, Bram Moolenaar wrote:
>> >
>> > Patch 7.4.840 (after 7.4.829)
>> > Problem:Tooltip window stays open.
>> > Solution: Send a WM_CLOSE message. (Jurgen Kramer)
>> > Files: src/gui_w32.c
>> >
>> >
>> > *** ../vim-7.4.839/src/gui_w32.c2015-08-25 12:21:23.583957205 +0200
>> > --- src/gui_w32.c 2015-08-26 23:10:03.847838259 +0200
>> > ***
>> > *** 4836,4841
>> > --- 4836,4842
>> > delete_tooltip(beval)
>> > BalloonEval *beval;
>> > {
>> > + PostMessage(beval->balloon, WM_CLOSE, 0, 0);
>> > PostMessage(beval->balloon, WM_DESTROY, 0, 0);
>> > PostMessage(beval->balloon, WM_NCDESTROY, 0, 0);
>> > }
>> > *** ../vim-7.4.839/src/version.c2015-08-26 23:01:16.453676957 +0200
>> > --- src/version.c 2015-08-26 23:11:28.262906177 +0200
>> > ***
>> > *** 743,744
>> > --- 743,746
>> > { /* Add new patch number below this line */
>> > + /**/
>> > + 840,
>> > /**/
>> >
>
> You might be right. If WM_CLOSE does eventually does internally call
> DestroyWindow() then the WM_DESTROY and WM_NCDESTROY might not be necessary.
>
A WM_CLOSE message should be posted to a top level window to close
the window. In response to this message, the window event handler is supposed
to call the DestroyWindow() function. This function performs the following (as
described in the Microsoft documentation):
Destroys the specified window. The function sends WM_DESTROY and WM_NCDESTROY
messages to the window to deactivate it and remove the keyboard focus from it.
The function also destroys the window's menu, flushes the thread message queue,
destroys timers, removes clipboard ownership, and breaks the clipboard viewer
chain (if the window is at the top of the viewer chain).
The resources associated with the window are freed by the DestroyWindow()
function.
>
> I wonder if there is a way to verify that this is the case? The main issue is
> that the code is crashing inside Microsoft's Common Controls DLL and I don't
> think the source code for this is accessible.
>
Most probably it is crashing in the common controls DLL because Vim is
trying to use/access a window resource after it is freed/destroyed.
- Yegappan
--
--
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 7.4.840
Hi,
Yegappan Lakshmanan schrieb am 26.08.2015 um 23:33:
>
> Based on the following posts:
>
> http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx
> http://blogs.msdn.com/b/oldnewthing/archive/2005/07/27/443824.aspx
>
> sending a WM_CLOSE and WM_NCDESTROY message to a window is not
> the same as calling DestroyWindow(). So I think the original fix (patch 829)
> for the crash is not correct.
if I understand the first post correctly it would be sufficient to only
send a WM_CLOSE message. For a test I removed the second and third calls
of PostMessage() and re-compiled. All balloon hints were cleanly removed
from the screen, but I could not check if there is a memory or resource
leak.
Patch attached.
Regards,
Jürgen
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
--
--
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_w32.c b/src/gui_w32.c
index 30fd04c..624393e 100644
--- a/src/gui_w32.c
+++ b/src/gui_w32.c
@@ -4851,8 +4851,6 @@ delete_tooltip(beval)
BalloonEval*beval;
{
PostMessage(beval->balloon, WM_CLOSE, 0, 0);
-PostMessage(beval->balloon, WM_DESTROY, 0, 0);
-PostMessage(beval->balloon, WM_NCDESTROY, 0, 0);
}
/*ARGSUSED*/
Re: Mail from Vim Github Repository
Am 2015-08-27 06:35, schrieb LCD 47: On 26 August 2015, Christian Brabandt wrote: [...] Also I added an Mail-Followup-To header, so depending on the reply method you use, a reply might end up at github as well (which needs to be tested). [...] Does Outlook pay attention to Mail-Followup-To these days? Does any recent mail client other than Mutt (and the now defunct Thunderbird) do it? I don't think Outlook is used in such a technical list a lot, but I honestly do not know. And while thinking about it, I suppose it does not matter, because I expect github to drop those mails, at least if they come from an address that has no github account associated with it. Also currently there is another issue, that the vim-ml account does not seem to get all notifications, although watching the repository. Best, Christian -- -- 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.
