Re: ZWNJ (Zero Width Non-Joiner) in Persian
در سهشنبه 24 اکتبر 2017، ساعت 21:38:41 (UTC+3:30)، Hamidreza Jafari نوشته: > در دوشنبه 23 اکتبر 2017، ساعت 22:48:10 (UTC+3:30)، Bram Moolenaar نوشته: > > Hamidreza Jafari wrote: > > > > > Vim with mlterm is able to process Farsi input except with (some) > > > special characters such as zero width non-joiner which is becoming a > > > concern. I observe: > > > > > > - if I set keymap to persian-iranian then text entry in Farsi and > > > driving Vim with commands are seamless because there is no need to > > > change keyboard language at OS level for commands. Keyboard language > > > is fix in English. Whenever I start to type for text it automatically > > > changes to Persian. Problem is I don't find a way to insert the famous > > > ZWNJ, coincidentally a much used character in Persian and Arabic. > > > > > > - if I do not change keymap to Persian, I can achieve similar text > > > entry capability with the benefit that ZWNJ input is as easy as the > > > usual: shift + space. It actually shows the codepoint in blue () > > > but viewing from other editor-aware (such as mlterm's cat) it shows > > > all well done. Now the problem is I should change keyboard language to > > > English at OS level every time I escape to drive, that is use Vim's > > > commands for text manipulation, navigation etc. It breaks (or brakes!) > > > Vim's major usability. > > > > > > I checked mlterm's font options (in configuration) but didn't notice a > > > difference when changing font name etc. > > > > > > How do I introduce ZWNJ to the first scenario? > > > > > > ZWNJ reference: https://codepoints.net/U+200C > > > > There hasn't been much work on Farsi support lately. The Farsi mapping > > is outdated, doesn't work with utf-8. What I heard was that it's > > probably best to do something similar to what Arabic support is doing. > > > > Anyway, can you type this character with CTRL-V u 200c? > > If not, maybe we can make CTRL-V switch the input to English, since > > that makes most sense. > > > > > > -- > > ARTHUR: Shut up! Will you shut up! > > DENNIS: Ah, now we see the violence inherent in the system. > > ARTHUR: Shut up! > > DENNIS: Oh! Come and see the violence inherent in the system! > > HELP! HELP! I'm being repressed! > > 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/// > > The signal is reject. It seems not the right tool for now. It will perfect > with time when there are more people turning to Linux in Persian for the > prime (and sub-prime) computing. Is there a way to have an overview of Vim's > development, e.g. subscribe to specific topics? Subscribed to vim_announce. By vim_use. -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim startup profiling
Hi Ken,
I briefly looked at your patch and have some feedback.
On Mi, 25 Okt 2017, Ken Takata wrote:
> Changes are:
> * Merge the two patches into one.
> * Update the document.
> * Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
> I'm still wondering what is the best name for this variable.
> * Remove `has('win16')`. Not needed anymore.
> * Add to the "Show File Types in Menu" item. Showing the command
> of this item is not so useful.
+If you want to have all these items already present at startup, add: >
+:let do_lazyload_menus = 1
I think this variable should either be called `do_no_lazyload_menus` or
the value should be 0, since by default the menus will be lazy loaded.
+ let n = globpath(&runtimepath, "colors/*.vim")
I think that should be
+ let n = globpath(&runtimepath, "colors/*.vim", 1, 1)
So you have a list available already and don't need to split later on
manually and you probably do want to ignore the suffixes and wildignore
options, if only the user having set them to bad values.
The same holds for the keymap and compiler runtime files.
+ augroup SetupLazyloadMenus
+au!
+au CursorHold,CursorHoldI * call SetupLazyloadMenus() | au!
SetupLazyloadMenus
+ augroup END
Is this actually a good idea to delete the augroup from within itself?
BTW: there are many runtime file variables. Perhaps we should start to
document internal runtime file variables in a help file at a central
place.
Also I am starting to wonder, whether it would make sense to start using
a common prefix, so that the names are more consistent and less likely
to clash with user variables, e.g. something like
vim_ftplugin_undo
vim_indent_undo
vim_menu_init_immediate
Christian
--
Neuer MS-Slogan:
Speicherst Du noch oder fluchst Du schon?
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim startup profiling
Hi,
2017/10/25 Wed 6:20:09 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > > > 2017/5/26 Fri 22:36:40 UTC+9 Ken Takata wrote:
> > > > > > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > > > > > 096.000 072.000 025.000: sourcing
> > > > > > D:\Logiciels\Vim\vim80\filetype.vim
> > > > >
> > > > > menu.vim uses `globpath()` to search some kind of files under the
> > > > runtimepath.
> > > > > If you search `globpath` in menu.vim, you may find the following
> > > > > lines:
> > > > >
> > > > > let s:n = globpath(&runtimepath, "colors/*.vim")
> > > > > let s:n = globpath(&runtimepath, "keymap/*.vim")
> > > > > let s = globpath(&rtp, "spell/*." . enc . ".spl")
> > > > > let s:n = globpath(&runtimepath, "compiler/*.vim")
> > > > >
> > > > > Color schemes, keymaps, spell files and compiler plugins are searched
> > > > > when
> > > > > menu.vim is loaded.
> > > > > This is why it takes long time to be loaded.
> > > > >
> > > > > Unlike those items, file types are not listed automatically. If a
> > > > > user
> > > > > selects "Syntax" -> "Show File Types in Menu", they will be listed.
> > > > > If we use a similar way for color schemes etc., the startup time
> > > > > would be
> > > > > reduced.
> > > >
> > > > I wrote a patch for reduce the loading the of menu.vim by skip using
> > > > globpath().
> > > >
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/bf92d701bca2ef46f6caa64aae89438e039370bb/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
> > > >
> > > > Instead of searching colors/*.vim and other files, the following
> > > > menuitems are
> > > > added in the menu:
> > > >
> > > > Edit > Show Color Schemes in Menu
> > > > Edit > Show Keymaps in Menu
> > > > Tools > Show Compiler Settings in Menu
> > > >
> > > > If these menuitems are selected, all available colorschemes etc. are
> > > > shown
> > > > in the menu. If a user want to load them at startup, the following line
> > > > can be added in .vimrc:
> > > > :let do_globpath_menus = 1
> > > > (This is similar to `:let do_syntax_sel_menu = 1`.)
> > > >
> > > >
> > > > In my environment, the loading time of menu.vim is:
> > > > Without this patch: 30 - 50 ms
> > > > Skip using globpath: 15 - 20 ms
> > >
> > > Not a very big difference. But still worth it if you never use those
> > > menus.
> > >
> > > I wonder if we can do this lazily. Thus fill in the missing entries
> > > when we start waiting for the user to type. Should be around the same
> > > place where timers may be triggered. Not sure if we can do it with an
> > > actual timer from the menu.vim script though. Might need a special kind
> > > of timer. Perhaps an "idle timer"?
> >
> > How about this additional patch, then?
> > https://bitbucket.org/k_takata/vim-ktakata-mq/src/938cf6a5e03ef2ccbc131ca2a3eb5bae364beb7b/improve-loading-menu.vim-cursorhold.patch?at=default&fileviewer=file-view-default
> >
> > This uses CursorHold to load the menuitems when idle.
>
> I like the idea. I'll wait for a few people to try it out.
I have updated the patches:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/c58b17bb22261436910d77dcda76409edd962ad5/improve-loading-menu.vim.patch?at=default&fileviewer=file-view-default
Changes are:
* Merge the two patches into one.
* Update the document.
* Rename the global variable `do_globpath_menus` to `do_lazyload_menus`.
I'm still wondering what is the best name for this variable.
* Remove `has('win16')`. Not needed anymore.
* Add to the "Show File Types in Menu" item. Showing the command
of this item is not so useful.
Regards,
Ken Takata
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
