Re: [patch] Regression: East Asian Ambiguous Width Character is no longer displayed correctly from patch 8.0.0543
Hi R0b0t1, 2017-4-19(Wed) 14:00:21 UTC+9 R0b0t1: > On Tue, Apr 18, 2017 at 7:26 AM, h_east wrote: > > - Paste the following character (U+25BC) in insert mode. > > ▼ > > > > Expected behavior: > > - The above characters are correctly displayed. > > > > Actual behavior: > > - Does not displayed properly. > > How does it fail to display? On rxvt-unicode the character is cut off > as it seems to be wider than the set of commonly displayed glyphs. Nothing displayed. Probably, it is displayed with halfwidth. And I think that the Japanese font I am using does not have halfwidth data of the above characters. -- Best regards, Hirohito Higashi (h_east) -- -- 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] Regression: East Asian Ambiguous Width Character is no longer displayed correctly from patch 8.0.0543
On Tue, Apr 18, 2017 at 7:26 AM, h_east wrote: > - Paste the following character (U+25BC) in insert mode. > ▼ > > Expected behavior: > - The above characters are correctly displayed. > > Actual behavior: > - Does not displayed properly. How does it fail to display? On rxvt-unicode the character is cut off as it seems to be wider than the set of commonly displayed glyphs. -- -- 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: Anybody using the Farsi feature?
On Wed, Apr 19, 2017 at 12:01 AM, Behdad Esfahbod wrote: > Humm. I don't like it that :set arabic activates a vim-side Arabic > keyboard. I run vim in gnome-terminal and want to use my X11 keyboards... > :set arabic, like :set nocompatible, :behave mswin, :vimdiff, :source vimrc_example.vim, and some others, sets a well-defined set of options. Any of them can be overridden by adding the appropriate counteracting instructions immediately afterwards. For instance, I have an owncoded Arabic keymap which I prefer to the one set by the 'arabic' option so I set it immediately after setting 'arabic'. If you prefer to use your own native X11 keyboard (and possibly set 'langmap' to define ASCII characters as a function of Arabic-Farsi ones) you can set 'keymap' to the empty string, and possibly also 'langmap' as desired, as follows: • maybe, in the vimrc :set langmap=someting • when starting to edit in Farsi :new ~/path/to/some/filename.ext :setlocal arabic :setlocal keymap= Best regards, Tony. -- -- 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: [bug] use of free memory with with 'indentexpr'
Dominique Pellé wrote:
> afl-fuzz found this case which causes access
> to freed memory in vim-8.0.566 and older:
>
> $ cat bug.vim
> func Indent()
> set indentexpr=
> endfunc
> set indentexpr=Indent()
> call feedkeys("i\", 'x')
> q
>
> $ valgrind --num-callers=50 vim -uNONE -S bug.vim 2>vg.log
>
> And vg.log contains:
>
> ==12968== Memcheck, a memory error detector
> ==12968== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==12968== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==12968== Command: vim -uNONE -S bug.vim
> ==12968==
> ==12968== Invalid read of size 1
> ==12968==at 0x643A16: skipwhite (charset.c:1533)
> ==12968==by 0x618459: get_func_tv (userfunc.c:471)
> ==12968==by 0x4463F3: eval7 (eval.c:4332)
> ==12968==by 0x445AFE: eval6 (eval.c:3969)
> ==12968==by 0x4456C4: eval5 (eval.c:3785)
> ==12968==by 0x444A1A: eval4 (eval.c:3484)
> ==12968==by 0x444829: eval3 (eval.c:3401)
> ==12968==by 0x439E89: eval2 (eval.c:)
> ==12968==by 0x435B52: eval1 (eval.c:3261)
> ==12968==by 0x435F9B: eval_to_number (eval.c:827)
> ==12968==by 0x4FA338: get_expr_indent (misc1.c:9271)
> ==12968==by 0x42F3FE: fixthisline (edit.c:7920)
> ==12968==by 0x4F454D: do_c_expr_indent (misc1.c:5401)
> ==12968==by 0x4207B6: edit (edit.c:1590)
> ==12968==by 0x52B197: invoke_edit (normal.c:9173)
> ==12968==by 0x52490E: nv_edit (normal.c:9143)
> ==12968==by 0x51AB71: normal_cmd (normal.c:1150)
> ==12968==by 0x4859CE: exec_normal (ex_docmd.c:10475)
> ==12968==by 0x44BA7B: f_feedkeys (evalfunc.c:3206)
> ==12968==by 0x4474C0: call_internal_func (evalfunc.c:991)
> ==12968==by 0x618B01: call_func (userfunc.c:1446)
> ==12968==by 0x6183A3: get_func_tv (userfunc.c:455)
> ==12968==by 0x61E268: ex_call (userfunc.c:3062)
> ==12968==by 0x47E9F2: do_one_cmd (ex_docmd.c:3021)
> ==12968==by 0x47AD35: do_cmdline (ex_docmd.c:1160)
> ==12968==by 0x4786F8: do_source (ex_cmds2.c:4313)
> ==12968==by 0x477D76: cmd_source (ex_cmds2.c:3926)
> ==12968==by 0x477DCB: ex_source (ex_cmds2.c:3901)
> ==12968==by 0x47E9F2: do_one_cmd (ex_docmd.c:3021)
> ==12968==by 0x47AD35: do_cmdline (ex_docmd.c:1160)
> ==12968==by 0x47BAB5: do_cmdline_cmd (ex_docmd.c:760)
> ==12968==by 0x64AA61: exe_commands (main.c:2923)
> ==12968==by 0x649718: vim_main2 (main.c:790)
> ==12968==by 0x6473F3: main (main.c:419)
> ==12968== Address 0x769b518 is 8 bytes inside a block of size 9 free'd
> ==12968==at 0x4C2BCEF: free (vg_replace_malloc.c:530)
> ==12968==by 0x50733D: vim_free (misc2.c:1793)
> ==12968==by 0x53F7C6: free_string_option (option.c:5713)
> ==12968==by 0x54A383: did_set_string_option (option.c:7499)
> ==12968==by 0x541B74: do_set (option.c:5124)
> ==12968==by 0x48D0CB: ex_set (ex_docmd.c:12280)
> ==12968==by 0x47E9F2: do_one_cmd (ex_docmd.c:3021)
> ==12968==by 0x47AD35: do_cmdline (ex_docmd.c:1160)
> ==12968==by 0x619DA2: call_user_func (userfunc.c:942)
> ==12968==by 0x618A68: call_func (userfunc.c:1427)
> ==12968==by 0x6183A3: get_func_tv (userfunc.c:455)
> ==12968==by 0x4463F3: eval7 (eval.c:4332)
> ==12968==by 0x445AFE: eval6 (eval.c:3969)
> ==12968==by 0x4456C4: eval5 (eval.c:3785)
> ==12968==by 0x444A1A: eval4 (eval.c:3484)
> ==12968==by 0x444829: eval3 (eval.c:3401)
> ==12968==by 0x439E89: eval2 (eval.c:)
> ==12968==by 0x435B52: eval1 (eval.c:3261)
> ==12968==by 0x435F9B: eval_to_number (eval.c:827)
> ==12968==by 0x4FA338: get_expr_indent (misc1.c:9271)
> ==12968==by 0x42F3FE: fixthisline (edit.c:7920)
> ==12968==by 0x4F454D: do_c_expr_indent (misc1.c:5401)
> ==12968==by 0x4207B6: edit (edit.c:1590)
> ==12968==by 0x52B197: invoke_edit (normal.c:9173)
> ==12968==by 0x52490E: nv_edit (normal.c:9143)
> ==12968==by 0x51AB71: normal_cmd (normal.c:1150)
> ==12968==by 0x4859CE: exec_normal (ex_docmd.c:10475)
> ==12968==by 0x44BA7B: f_feedkeys (evalfunc.c:3206)
> ==12968==by 0x4474C0: call_internal_func (evalfunc.c:991)
> ==12968==by 0x618B01: call_func (userfunc.c:1446)
> ==12968==by 0x6183A3: get_func_tv (userfunc.c:455)
> ==12968==by 0x61E268: ex_call (userfunc.c:3062)
> ==12968==by 0x47E9F2: do_one_cmd (ex_docmd.c:3021)
> ==12968==by 0x47AD35: do_cmdline (ex_docmd.c:1160)
> ==12968==by 0x4786F8: do_source (ex_cmds2.c:4313)
> ==12968==by 0x477D76: cmd_source (ex_cmds2.c:3926)
> ==12968==by 0x477DCB: ex_source (ex_cmds2.c:3901)
> ==12968==by 0x47E9F2: do_one_cmd (ex_docmd.c:3021)
> ==12968==by 0x47AD35: do_cmdline (ex_docmd.c:1160)
> ==12968==by 0x47BAB5: do_cmdline_cmd (ex_docmd.c:760)
> ==12968==by 0x64AA61: exe_commands (main.c:2923)
> ==12968==by 0x649718: vim_main2 (main.c:790)
> ==12968==by 0x6473F3: main (main.c:419)
> ==12968== Block was alloc'd at
> ==12968==at 0x4C2ABF5: malloc (vg_replace_malloc.
Patch 8.0.0567
Patch 8.0.0567
Problem:Call for requesting color and ambiwidth is too early. (Hirohito
Higashi)
Solution: Move the call down to below resetting "starting".
Files: src/main.c
*** ../vim-8.0.0566/src/main.c 2017-04-02 18:19:48.376143576 +0200
--- src/main.c 2017-04-18 18:47:16.909399297 +0200
***
*** 666,677
starttermcap(); /* start termcap if not done by wait_return() */
TIME_MSG("start termcap");
- #if defined(FEAT_TERMRESPONSE)
- # if defined(FEAT_MBYTE)
- may_req_ambiguous_char_width();
- # endif
- may_req_bg_color();
- #endif
#ifdef FEAT_MOUSE
setmouse(); /* may start using the mouse */
--- 666,671
***
*** 801,806
--- 795,805
/* Requesting the termresponse is postponed until here, so that a "-c q"
* argument doesn't make it appear in the shell Vim was started from. */
may_req_termresponse();
+
+ # if defined(FEAT_MBYTE)
+ may_req_ambiguous_char_width();
+ # endif
+ may_req_bg_color();
#endif
/* start in insert mode */
*** ../vim-8.0.0566/src/version.c 2017-04-15 15:37:09.646798989 +0200
--- src/version.c 2017-04-18 18:49:24.664614475 +0200
***
*** 766,767
--- 766,769
{ /* Add new patch number below this line */
+ /**/
+ 567,
/**/
--
DEAD PERSON: I'm getting better!
CUSTOMER: No, you're not -- you'll be stone dead in a moment.
MORTICIAN:Oh, I can't take him like that -- it's against regulations.
The Quest for the Holy Grail (Monty Python)
/// 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] neovim patches
Christian Brabandt wrote: > On Di, 14 Mär 2017, Bram Moolenaar wrote: > > > On 14 March 2017 at 22:24, Christian Brabandt wrote: > > > > On Di, 14 Mär 2017, Christian Brabandt wrote: > > > > > Updated patch attached. > > > > I see that patch was already included, also I did not receive an email > > yet. Please also add this part, which effectively reverts 7.4.700 and > > isn't needed anymore. (Sorry forget to squash this into the neovim > > patch. > > > > > > Thanks. I can't send email from my local machine currently, using Gmail for > > now. > > > > The patch appeared to work, thus I included it. I was wondering about > > whether > > some > > cleanup would be possible. Thanks for doing that now, I'll make another > > patch > > for that. > > It looks like this introduced a regression: > > https://github.com/neovim/neovim/pull/6534/commits/a2f0d80d27f73694155a0ad56ee7ce59ff6f347c Thanks, I'll look into it. -- MORTICIAN:What? CUSTOMER: Nothing -- here's your nine pence. DEAD PERSON: I'm not dead! MORTICIAN:Here -- he says he's not dead! CUSTOMER: Yes, he is. DEAD PERSON: I'm not! The Quest for the Holy Grail (Monty Python) /// 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] Regression: East Asian Ambiguous Width Character is no longer displayed correctly from patch 8.0.0543
Hirohito Higashi wrote: > At this point, it's only on the Terminal App and iTerm2 of macOS that I can > confirm this phenomenon. > > Preparation for repro.: > - Terminal settings: > - encoding: utf-8 > - Unicode East Asian Ambiguous Character width: Wide > > How to reproduce: > Run vanilla Vim with some options in Terminal App on macOS. > - vim -Nu NONE --cmd "set enc=utf-8" -c "set ambw=double" > Note: This Vim build configure is "Huge and without GUI". > > - Paste the following character (U+25BC) in insert mode. > ▼ > > Expected behavior: > - The above characters are correctly displayed. > > Actual behavior: > - Does not displayed properly. > > > NOTE: > - Vim 8.0.0542 displayed this correctly. > - Vim 8.0.0543 does not. (Also 8.0.0566) > > > In 8.0.0542, function may_req_ambiguous_char_width() is not included judgment > of `starting == 0`. > But, 8.0.0543 is included. > So I remove this judgement. > > Check attached patch. > I don't know this is the best solution. Removing the check for "starting" is tricky, it may send control sequences at the wrong moment. The call to the function is too early, when "starting" is still non-zero. Let's move the calls down. Please check it works for you after that patch. -- Shit makes the flowers grow and that's beautiful /// 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] Regression: East Asian Ambiguous Width Character is no longer displayed correctly from patch 8.0.0543
Hi Bram and list,
At this point, it's only on the Terminal App and iTerm2 of macOS that I can
confirm this phenomenon.
Preparation for repro.:
- Terminal settings:
- encoding: utf-8
- Unicode East Asian Ambiguous Character width: Wide
How to reproduce:
Run vanilla Vim with some options in Terminal App on macOS.
- vim -Nu NONE --cmd "set enc=utf-8" -c "set ambw=double"
Note: This Vim build configure is "Huge and without GUI".
- Paste the following character (U+25BC) in insert mode.
▼
Expected behavior:
- The above characters are correctly displayed.
Actual behavior:
- Does not displayed properly.
NOTE:
- Vim 8.0.0542 displayed this correctly.
- Vim 8.0.0543 does not. (Also 8.0.0566)
In 8.0.0542, function may_req_ambiguous_char_width() is not included judgment
of `starting == 0`.
But, 8.0.0543 is included.
So I remove this judgement.
Check attached patch.
I don't know this is the best solution.
--
Best regards,
Hirohito Higashi (h_east)
--
--
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/term.c b/src/term.c
index 85b1ff5..334038a 100644
--- a/src/term.c
+++ b/src/term.c
@@ -3314,7 +3314,6 @@ may_req_ambiguous_char_width(void)
{
if (u7_status == U7_GET
&& can_get_termresponse()
- && starting == 0
&& *T_U7 != NUL
&& !option_was_set((char_u *)"ambiwidth"))
{
Re: [patch] Clean up Mac code
* Kazunobu Kuriyama [170418 00:15]:
> The proposed changes are rather fixes to address a certain issue than those
> that possibly break existing scripts.
>
> The issue is this: Currently, 'mac' does not cover all versions of vim
> running on Mac. To be more specific, vim configured with --disable-darwin
> gives 0 to has('mac').
>
> To address the issue, a new feature list item called 'osx' was introduced
> about a year ago. With that, the following condition covers all possible
> vim instances running on Mac:
>
> has('mac') || has('osx')
>
> Although this is logically correct, it looks clumsy and is turned out to be
> error-prone.
>
> Naturally, people does not expect that there's a case where has('mac')
> returns 0 for a vim actually running on Mac. The proposed patch would
> eliminate this counter-intuitive case.
Okay, SGTM.
> Also, we are now in the process of improving the test coverage. Through
> the process, we sometimes came across the cases where a newly written test
> failed inadvertently for darwin-disabled vim due to missing has('osx').
>
> If all test writers were familiar with Mac, it would be quite reasonable to
> ask them not to forget that. In reality, however, they are not. We need
> to provide a feature list item easier to use for test writers to write
> tests which are expected to work well on Mac even if they are not on Mac to
> write them. The proposed patch would help those people.
>
> The --disable-darwin configuration is highly unlikely to be used by package
> managers and non-dev users, because that configuration is meant to kill the
> clipboard service from the system. So I think dropping 'osx' won't make
> much trouble because those who know both --disable-darwin and has('osx')
> and understand their implications have already had a working knowledge as
> to how to handle trouble caused by them.
I think this is a reasonable justification for your proposed change.
> 2017-04-18 2:49 GMT+09:00 Marvin Renich :
> > I think for this to work, the existing names should
> > be left as is and marked as deprecated, and then add new names, such as
> > mac_any, mac_unix, and mac_osx with the new meanings.
>
> Now we come to know adding new names does not necessarily address an issue
> satisfactorily and would cause trouble later, as we've seen a case with
> 'osx'. That's another reason why the patch is of 10k SLOC instead of usual
> 0.1k for this sort of changes. We need to neutralize the root cause of
> name proliferation, too :)
I definitely agree that name proliferation should be avoided when
possible, but it is less important than preventing breakage of existing
scripts. Documenting the old names as deprecated with an explanation of
why using them is bad would be preferable to breaking changes, but your
justification above is sufficient to assuage my concerns in this
particular case.
Thanks for working on this and also for taking the time to explain your
reasoning for the design.
...Marvin
--
--
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.
