Re: Vim syntax file should not require interpreter support to highlight :{interp}<
On Thursday, August 15, 2013 10:02:36 PM UTC-5, DrChip wrote:
> ZyX wrote:
>
> > I see that all g:vimsyn_embed flags say things like �embed � **(but
> > only if vim supports it)**�. This is ridiculous:
>
> Ah, I disagree -- not ridiculous at all. What's ridiculous is to assume
>
> that one will be writing code for an interpreter embedded in vimscript
>
> without being able to test it. Thus, one needs to have the interpreter
>
> supported for it to make sense. The syntax/vim.vim script is quite long
>
> already; making all interpreters' embedded highlighting work all the
>
> time means everyone would have to put up with additional delays -- and
>
> frankly, I don't think that most folks use all the interpreters.
>
> That's not a problem for those with fast machines; not all have fast
>
> machines.
>
> > ou don�t have to have vim lua support to code in lua and have syntax
> > highlighting; you specifically don�t have to have vim lua support to
> > write or watch lua< > to want to review {interp}< > whether he needs to obtain Vim with {interp} support or (my case) to watch
> > correct highlighting of his own vimrc on machine without specific
> > interpreter support.
>
>
>
> You can look at the embedded code already -- it just won't have the
>
> embedded interpreter's highlighting if your vim won't support it. Sort
>
> of a visual flag that it won't work with your vim.
I like the idea of at least being able to force looking at it, without having
it distract me with error highlighting.
ZyX's request seems reasonable to me.
A lot of the time I'm just looking at a plugin, I haven't written a line of it.
Sometimes I'll do this on a different machine than I'm installing on.
--
--
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/groups/opt_out.
Re: new syntax file(systemverilog)
Hi, All, it is very convinence if vim-dev team includes system verilog syntax file as default. Best Regards, Tomo -- -- 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/groups/opt_out.
Re: Vim syntax file should not require interpreter support to highlight :{interp}<
ZyX wrote: I see that all g:vimsyn_embed flags say things like “embed … **(but only if vim supports it)**”. This is ridiculous: Ah, I disagree -- not ridiculous at all. What's ridiculous is to assume that one will be writing code for an interpreter embedded in vimscript without being able to test it. Thus, one needs to have the interpreter supported for it to make sense. The syntax/vim.vim script is quite long already; making all interpreters' embedded highlighting work all the time means everyone would have to put up with additional delays -- and frankly, I don't think that most folks use all the interpreters. That's not a problem for those with fast machines; not all have fast machines. ou don’t have to have vim lua support to code in lua and have syntax highlighting; you specifically don’t have to have vim lua support to write or watch lua< You can look at the embedded code already -- it just won't have the embedded interpreter's highlighting if your vim won't support it. Sort of a visual flag that it won't work with your vim. -- -- 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
Christian Brabandt wrote: > On Di, 13 Aug 2013, Christian Brabandt wrote: > > > On Tue, August 13, 2013 01:00, Einar Lielmanis wrote: > > > Encrypted file contents are destroyed, if something (e.g autocmd) > > > triggers write event, while user is being asked for password. > > > > > > To repro: > > > 1. have an encrypted.txt ready (:X) > > > 2. gvim, :au focuslost * w > > > 3. :e encrypted.txt, don't type in the password yet, > > > 4. lose window focus, e.g via switching to another window, to trigger > > >the focuslost event, > > > > > > Expected: > > > The file hasn't changed, so it should stay unmodified, > > > > > > Actual behavior: > > > encrypted.txt is truncated to a zero size. > > > > > > I don't see this. Using Vim 7.4 on Windows I get > > vim -u NONE -N -i NONE > > :au FocusLost * w > > :e encrypted.txt > > (change Focus) > > Error detected while processing FocusLost Auto commands for "*": > > E505: "c:\temp\encrypted.txt" is read-only (add ! to override) > > "c:\temp\encrypted.txt" [crypted] 2L, 13C > > > > > > In any case, the file is *not* written. > > > > If you used au FocusLost * :w! the file is indeed truncated > > but even then after entering the correct password Vim can read > > the encrypted file (but you would need to make sure > > you have written the file or else you would be left with an empty > > file). > > Hm, on Linux, it indeed truncates the encrypted file. > Anybody else sees this difference? > > Wouldn't it be a good idea, to have the file set readonly for as long it > hasn't been encrypted (e.g. the current windows behaviour)? You mean, until it has been decrypted. That makes sense. Actually, when a file is encrypted and the user just hits enter and the prompt for the key, it should also be marked as readonly. -- >From "know your smileys": =):-) Uncle Sam /// 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/groups/opt_out.
Re: Segfault on 7.4 caused by syntax :on with Ruby file
On Do, 15 Aug 2013, Matt Yoder wrote: > FWIW I too have segfaults with ruby syntax on, 7.4, os x 10.6.8. > Updating my vim syntax file resolved the problem. Well, 7.4.003 should have fixed that. Can you confirm? regards, Christian -- Durch die Leidenschaften lebt der Mensch, durch die Vernunft existiert er bloß. -- Nicolas Sébastien de Chamfort -- -- 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/groups/opt_out.
Re: Segfault on 7.4 caused by syntax :on with Ruby file
FWIW I too have segfaults with ruby syntax on, 7.4, os x 10.6.8. Updating my vim syntax file resolved the problem. M -- -- 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
On Wednesday, August 14, 2013 4:34:12 PM UTC-5, Christian Brabandt wrote: > On Di, 13 Aug 2013, Christian Brabandt wrote: > > > > > On Tue, August 13, 2013 01:00, Einar Lielmanis wrote: > > > > Encrypted file contents are destroyed, if something (e.g autocmd) > > > > triggers write event, while user is being asked for password. > > > > > > > > To repro: > > > > 1. have an encrypted.txt ready (:X) > > > > 2. gvim, :au focuslost * w > > > > 3. :e encrypted.txt, don't type in the password yet, > > > > 4. lose window focus, e.g via switching to another window, to trigger > > > >the focuslost event, > > > > > > > > Expected: > > > > The file hasn't changed, so it should stay unmodified, > > > > > > > > Actual behavior: > > > > encrypted.txt is truncated to a zero size. > > > > > > > > > I don't see this. Using Vim 7.4 on Windows I get > > > vim -u NONE -N -i NONE > > > :au FocusLost * w > > > :e encrypted.txt > > > (change Focus) > > > Error detected while processing FocusLost Auto commands for "*": > > > E505: "c:\temp\encrypted.txt" is read-only (add ! to override) > > > "c:\temp\encrypted.txt" [crypted] 2L, 13C > > > > > > > > > In any case, the file is *not* written. > > > > > > If you used au FocusLost * :w! the file is indeed truncated > > > but even then after entering the correct password Vim can read > > > the encrypted file (but you would need to make sure > > > you have written the file or else you would be left with an empty > > > file). > > > > Hm, on Linux, it indeed truncates the encrypted file. > > Anybody else sees this difference? > > > > Wouldn't it be a good idea, to have the file set readonly for as long it > > hasn't been encrypted (e.g. the current windows behaviour)? > I agree that's a good idea. Would it even make sense to temporarily set 'nomodifiable' too? -- -- 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/groups/opt_out.
Re: omap puzzle
On Thu, August 15, 2013 15:53, Dimitar DIMITROV wrote:
>>> Hi all,
>>>
>>> I've noted this behaviour with omaps: in my omap I jump to a place in
>>> the
>>> buffer, then after an if test I select visually something. So all is
>>> good
>>> when
>>> the test succeds and only the visual area gets modified. Now if the
>>> test
>>> fails, no visual selection is created and the omap acts on my motion in
>>> the buffer
>>> instead of being cancelled. Is there a way to tell in the test, if it
>>> fails to cancel the omap?
>>
>>I think this question belongs on the vim_use list.
>>
>>Try returning Esc.
>>
>>BTW: Have you tried the patch yet?
>
> Hi Christian,
>
> Sorry for not doing the test earlier, just tried and yes your patch fixes
> the issue (gUgn) thanks!
> Could you explain how to return esc and ok, I will ask next time in the
> right list.
>
> I tried: return '', execute ':normal! ', feedkeys("\") and
> none worked
Either try returning a literal Esc, e.g.
return "^[" where ^[ is *one* char, which can typed by pressing Ctrl-V
followed by Esc
or alternatively, return "\" should also work.
regards,
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/groups/opt_out.
Re: omap puzzle
>> Hi all,
>>
>> I've noted this behaviour with omaps: in my omap I jump to a place in the
>> buffer, then after an if test I select visually something. So all is good
>> when
>> the test succeds and only the visual area gets modified. Now if the test
>> fails, no visual selection is created and the omap acts on my motion in
>> the buffer
>> instead of being cancelled. Is there a way to tell in the test, if it
>> fails to cancel the omap?
>
>I think this question belongs on the vim_use list.
>
>Try returning Esc.
>
>BTW: Have you tried the patch yet?
Hi Christian,
Sorry for not doing the test earlier, just tried and yes your patch fixes the
issue (gUgn) thanks!
Could you explain how to return esc and ok, I will ask next time in the right
list.
I tried: return '', execute ':normal! ', feedkeys("\") and none
worked
>regards,
>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/groups/opt_out.
Re: omap puzzle
On Thu, August 15, 2013 14:57, Dimitar DIMITROV wrote: > Hi all, > > I've noted this behaviour with omaps: in my omap I jump to a place in the > buffer, then after an if test I select visually something. So all is good > when > the test succeds and only the visual area gets modified. Now if the test > fails, no visual selection is created and the omap acts on my motion in > the buffer > instead of being cancelled. Is there a way to tell in the test, if it > fails to cancel the omap? I think this question belongs on the vim_use list. Try returning Esc. BTW: Have you tried the patch yet? regards, 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/groups/opt_out.
Re: Completion popup window flicker while typeing keys
On Thursday, August 15, 2013 9:58:18 PM UTC+9, mattn wrote: > How about this? > > https://gist.github.com/6240621 > > Removing duplicate forcely update_screen. > > This seems working good for me. > > - Yasuhiro Matsumoto Ah, Sorry It seems statusline must be redrawn. https://gist.github.com/6240679 -- -- 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/groups/opt_out.
Re: Completion popup window flicker while typeing keys
On Thursday, August 15, 2013 9:02:51 PM UTC+9, mattn wrote: > On Thursday, August 15, 2013 8:57:42 PM UTC+9, mattn wrote: > > https://gist.github.com/6240255 > > > > When redrawing popup menu, it don't need to redraw FORCELY. > > This patch seems to be working by leaps and bound. Most of flicker was > > removed. > > But become crash. How about this? https://gist.github.com/6240621 Removing duplicate forcely update_screen. This seems working good for me. - 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/groups/opt_out.
omap puzzle
Hi all, I've noted this behaviour with omaps: in my omap I jump to a place in the buffer, then after an if test I select visually something. So all is good when the test succeds and only the visual area gets modified. Now if the test fails, no visual selection is created and the omap acts on my motion in the buffer instead of being cancelled. Is there a way to tell in the test, if it fails to cancel the omap? Dimitar --- GPG Key: 2048R/160C6FA8 2012-10-11 Dimitar Dimitrov (kurkale6ka) -- -- 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/groups/opt_out.
Calling win_redr_custom recursibely
Hi bram.
When redrawing statusline in redraw_custom_statusline(), it block recursible
call with 'entered' flag.
But win_redr_custom that called in some part is not blocked with flag.
win_redr_custom is called in following cases.
* redrawing statusline
* redrawing tabline
* redrawing ruler
And win_redr_custom is calling build_stl_str_hl. i.e. %{expr}.
expr is possible to make trigger of redrawing of statusline.
So I'm thinking calling win_redr_custom should block recursiblely.
How do you think?
https://gist.github.com/6240365
- 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/groups/opt_out.
Re: Completion popup window flicker while typeing keys
On Thursday, August 15, 2013 8:57:42 PM UTC+9, mattn wrote: > https://gist.github.com/6240255 > > When redrawing popup menu, it don't need to redraw FORCELY. > This patch seems to be working by leaps and bound. Most of flicker was > removed. But become crash. -- -- 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/groups/opt_out.
Re: Completion popup window flicker while typeing keys
On Tuesday, June 11, 2013 12:54:35 AM UTC+9, Ben Fritz wrote: > On Monday, June 10, 2013 3:00:45 AM UTC-5, mattn wrote: > I haven't tried the patch. I'm slightly concerned about removing a redraw > during completion, because of this discussion which resulted in patch 807 > *adding* a redraw of the popup menu: > http://vim.1045645.n5.nabble.com/Omnicomplete-shows-strange-behavior-when-preview-window-is-enabled-td5713611.html > > The patch at least modifies different code, but I cannot tell at a glance > whether it might cause a regression. I'll see if I can try it out at home > later this week if nobody beats me to it. I re-write patch. https://gist.github.com/6240255 When redrawing popup menu, it don't need to redraw FORCELY. This patch seems to be working by leaps and bound. Most of flicker was removed. Thanks. - 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/groups/opt_out.
Re: [PATCH] make adding new letters to arabic.c easier
On Wed, 14 Aug 2013 21:59:11 +0430
Ali Gholami Rudi wrote:
> As Tony pointed out, arabic.c replaces Arabic characters with their
> Unicode presentation forms; Arabic and Farsi letters have different
> shapes based on their positions inside words. My patch simplifies
> arabic.c and adds Farsi letters. The patch I use, ported to Vim-7.4,
> can be obtained from: http://litcave.rudi.ir/farsi_vim.diff
>
> Ali
>
Thanks Ali.
It worked good. Just failed for Tatweel. I suppose, it's due to this
fact your algorithm considers surrounding characters abilities for
reshaping -having [sfim] members in structure- but it's not sufficient,
at least for your table. Old code works because it's somewhat agnostic
about character abilities and it calls half-shape anyway.
I think one solution is change Tatweel structure to something like
{0x0640, 0, 0x0640, 0x0640, 0x0640}
or change can_join(), though I've not tested it yet.
--
--
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/groups/opt_out.
