Re: Google Code shuts down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On March 13, 2015 10:56:56 AM EAT, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Mar 12, 2015 at 02:38:23PM -0700, Ben Fritz wrote: And, Mercurial is a tool that makes it very hard to shoot yourself in the foot. Git makes it very easy to lose data permanently, even when you're doing something like a *push* which should *never* lose data in my opinion. Mercurial also is a lot easier to pick up with fewer concepts that need understanding. So I think people who occasionally need to dabble in Mercurial are probably better off than people who occasionally need to dabble in git. I don't care about if vim uses mercurial or git, but please don't use FUD as an argument. It's _very hard_ to loose data with git, and you can't loose data with a push. ... as long as you control the server. What you probably mean is that a push -f would move your branch pointer, possible to a branch that does not contain all commits. Now this is stupid to do if it's a public branch, so hopefully this will be denied by the server (if the server is setup correctly). Github servers are not by default. Second, if a commit become unrefered by any branch or tag, it will be garbage collected, but first after 2 weeks. Which is of no use if don't control the server and don't have the commits locally. Third, you have a list of all commits you've been on, so a it's not hard to look up the previous branch position. Absolutely pointless. You can make unreachable those commits that *never* were in your repository locally. Here is the story: Background: most of the projects I develop on GH are developed in my fork and I run PRs to the upstream whether or not I have push access. Since I may develop more then one branch at once I aliased 'git p' to 'git push --all' (origin is my clone). This works well since nobody, but me pushes to my fork. One project (VAM) was different: it was the first project on GH I actively participated and after gaining push access I stopped using my fork. Once I was developing my branch, rebased it on master and squashed some commits, then force-pushed. I guess you now understand the issue: of course I was using usual shortcut. And I forgot to pull prior to this. So I happened to force-push my branch *and* master, *and* I did not have commits locally that became now unreachable. This story resolved by using commits from @MarcWeber local clone and I adjusted my development process to avoid this in the future. But there are two morals here: 1. When developing using git you need to be aware that you *can* destroy other people's work on remote repository and adjust your development process accordingly. (AFAIK GH allows you to deny non-ff pulls to certain branches. But this is not the default.) 2. You *can't* do this with mercurial. Also note that remote history rewriting using mercurial changeset evolution looks more promising if you can tell the server that you need to pull removed changesets (they are *always* there, just not send by the server by default). Unfortunately, mercurial authors for some reason think changeset evolution replaces mq... PS: Based on how many changes were made to git to the core concepts in past few years (== none AFAIR) I think that git architecture simply does not *allow* developers to do such changes like adding branches (git has bookmarks, mercurial also does, but they were *added* not too long ago) or changeset evolution, or phases. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJVAwKDGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRB2r/1b STKPjvr7D/411ojY4KMVq7bsdb9D282Rdl4YYstG8O7bCUlSWPUzlc3DcBxnz9m0 FGuBVlaijb7LBS3/n3bMqCTz7+TliHlORharaPhprddpc9mTsZRlFf1ZoC+uwIiE wVVS8acmNyCS7cKv5548KqT7sJ1nwxrbuPyRHter784ZAFXMtHV99RffQYeg6wMM T8akkprA7V3hqNGyN75b8+9JICHWBjV1l1O6IQulIhYbqO/Rj4hfbO1SObPrhW66 PS4vm4+Ky2Fc4DgvEAWw4O1tsS0LdWkZoAxh2KVzU1/8AksMRrwjqmr9OAYnSSvy DNZ4kMlcm+cWEtshiWtLKm9QRxbhng6/7tiKTY515Flwk4VwzMD0KvJ4G759Rcde 1m9sy0FOB4752gDOPMbIcT3zszrhKT9Dtec5Nk0I6VTHm6/EbsOnWrumnDuR0z+I O4PZO9jz6XWAzKOg1Jgpp1H3KEUK8plMp2ujTLJIHvOihshH5x1MRSIzrrC01s+N XZ5lTU0Mn+smk0G+MSJnMBkfLCvm+aMZEbjuGwxSxV8dYx/WK8RsDxjY7PFe7ydP Eh0QLdUPa2OTcXKEkX6yF9pmD8NyEEV8MVQbXRgCvp8FKD7+W05BhLCzCBMspUws x0uzqX11HsuRnI6MKSBEm1M+H4ltDLIkcoKAS5wSXK+PYJd0UsiOzA== =UfGO -END PGP SIGNATURE- -- -- 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] -S does not accept a file name
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On March 5, 2015 3:36:26 PM EAT, Bram Moolenaar b...@moolenaar.net wrote:
ZyX wrote:
Try the following code:
echo echomsg 42 '$HOME'
vim -u NONE -i NONE -S '$HOME'
. It will show “E484: Can't open file /home/zyx”, while it should
just
echo 42. Worse things will happen if file happens to contain pipe: as
`-S …` is translated to `so …` without escaping anything this will
run
some commands.
I think that instead `do_source` needs to be called directly on `-S`,
with another boolean value to disable expansion of anything.
The order of execution is important, calling do_source() directly
probably changes it.
Depends on implementation. If you add yet another list of arguments and process
this separately then it will change. If you transform array of char* into array
of structs (initial intention) which contain the kind of the argument and the
argument itself then it will not.
We could escape special characters in the argument, but that's easy to
get wrong. Perhaps it's time we add a command modifier that disables
any wildcard expansion? So it would be :nowild so $HOME.
There is still a problem with ends_excmd and space characters. I suggested
calling do_source directly because it is easier:
1. No code for escaping.
2. No code for allocating string.
3. No code for putting so and escaped string together.
4. No code for freeing allocated string.
Note that on MS-Windows we do have to expand wildcards, since the shell
doesn't do that for us.
I thought this is done on another layer. I also sometimes use tricks like
vim -S foo.vim{,}
, expanding them in do_source breaks such tricks.
By the way, where %VARNAME% is being expanded on Windows? Expanding $HOME does
not seem right, Windows convention is %HOME%. Current code will do expansions
of $HOME because it uses Vim conventions.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJU+G77GBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSviQQD/4mk13jdVclBySz5dATwE43vEZJCDgjpcYq9sK9rjXa6iDFBs2ziSDB
TKOEnGtnu3th+UwoOWmy9VvT0d7e11XW/hFZR3pB7A0hhZLZoyRmPPKou/lZvNGT
qdrgQmp3pgLywVapvd8cE61n8TelW3/IZQHgqUFF+5/yy/x/mIyGeACHebYVs6ck
U0opOzSSgll+9vscQSt+kI9Gg54o3bOXUftttWZnqKQkvrE3kHnXoiqV5BO9wJOv
QH+zlpVBcX3FmesZ8y70LIVf24Neae/zxPBH02Gsv89X3gPxMlOAEhU54aguArmH
Sy6K/42uh0FpLP7FirPnN+S8sZAcK3x8NyIaV+Bdn44pMzeCUROSgw9KctJh7RP9
p+lWQtExGHUXY9Yu2mbL5YVRdFj98HP47SBEM9Hjc5wpVZaTFfR6cGHn1nwVFT8Z
Py2nRENnrq7IMKygM+1VLsgVtwz0vSuaMaYxmVs1X2mby1ZoyeRASbcvwAr1WxD3
5rh+wix6nkdfwLnEqTWZq0kUOxWkhtgvr1uZGQ+fBtGaohn2bdPxo8booY0v1X9c
yKdn2hZfsEXSXjrdF7hXk174+uq6XiadZALsYCezMSoYwcdw9rpdpcZDCSzzsK/G
yd2J3zu33JCtjhnBhxpHopFcvIIR8TsB8pKfUbmck86e258T4Jc7QA==
=I0Ss
-END PGP SIGNATURE-
--
--
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: How to determine the x and y position of the Vim text window on screen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On December 18, 2014 11:01:49 PM EAT, Lubos Pintes lubos.pin...@gmail.com
wrote:
Hi,
I tried to be as clear as possible, but I am realizing that I was not
clear enough, sorry about that.
I talked about text window, not GUI window.
For example, if I issue the :split file command, the window area is
split, this doesn't affect the GUI window. At least I think so.
I am using gvim. I am trying to make it accessible, or better said,
usable with screen reader, NVDA in my case.
I am communicating with gvim through its OLE interface. I can use
information which eval can provide, but it is not enough for proper
usability.
I had some success, but I need to handle a situation when several
windows are on the screen. Again, when text area is split to several
windows.
I don't care about GUI window, it is simulating the console. I am only
interested in text area. I need to identify text window dimensions. So
for example, if only one window is displayed, it starts on (1, 1) and
has a width of 80 and height of 25. Also it has a number 1.
But what if I split the text area say to 4 windows? How can I
algorithmically determine window positions?
Hopefully I explained what I need. And if I am stupid and I overlooked
something obvious, then sorry again.
Dňa 18. 12. 2014 o 17:19 toothpik napísal(a):
On Thu, Dec 18, 2014 at 11:18:28AM +0100, Lubos Pintes wrote:
Hello,
We have functions winwidth(winnr) and winheight(winnr).
I thing that winleft(winnr) and wintop(winnr), are missing. Perhaps
I greatly overlooked something, I don't know how to determine where
the window with concrete winnr starts.
Any help how to determine window coordinates greatly appreciated.
Thanks
if you know all those win_ functions I'm surprised you don't also
know
about the winpos command -- without arguments it tells you the
current
(gui) window position -- with x and y arguments it will position the
window for you
see
:h winpos
for the gory details
--
--
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.
You may use pyeval('vim.current.window.col') and
pyeval('vim.current.window.row'), same with py3eval. Requires +python (+python3
for py3eval) and running :python import vim (:python3 import vim) prior to
using function.
You may check out the code used for implementing __getattribute__ slot function
for vim.Window object to create a patch for wincol() and winrow(). At the time
I was writing patch that added col and row vim.Window attributes nothing like
this existed in VimL.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJUk8MyGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvs5REACmUHqhxHCG1YNjxiyf4o8W/16rlGfpHxSzR80hHwVz4KhwcCZ96zSV
CCXRdbH8VfKF7ttq/Io5nzakUDBuheIkRtSOshliQfG/1ESHMZZbq29ZBeU1ujUo
b8eQkEP57J0Hc4WkQ2aC2PEEkI6KUIYofQJiKxeUp+JHBu/Vxgvcm4Hm7JMzvDUW
cY5UiMPR3vRpTd/ML3z6sFwzmfpUJtYC1Qa+Zqe1q0cqceDTF2nh9rtBGqnw6Cj2
D7cjIysudQvEw2beTxzhzSpNi6pPMc15LAjlBeNXqJvopR/sZl18celw00EvuxaU
J2rW3nG0Muc0QLI6MZFis6jRlmUeMTYWLO5okI74hLzABAKMtAPz6BuPePF0B3VR
APa3dFE2FpgUgENETlRpK9Acn1aIx1mqHRLFM92CkkK5y0TPUxWmhfUkRktEzgOc
AT4oQVOVeSRX4gReT8IkOBjUM40XZhYqb7//C91Vt9lBC5qdjw0SZtyPi1A0e7dF
xsZ7v4rkogXRA5HnfpoxHxb6j6Ywu/paXLsXBVBk0elJcWPF+KhAht7Vjzg5fTGA
Y9gqyP2oi2IzuV1bOGb9oWsfDrGp6X6xbzWW9NwGMcVKZuSXY3gHYsrC35YGFwwr
iMXKC3DEqEug5K6IrHvxnUd5rYwjGkCDAOOVKcWYr5H982J/APr1UA==
=Ijii
-END PGP SIGNATURE-
--
--
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: Why vim recodes bytes in unknown (to it) encoding?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On November 16, 2014 10:45:03 PM EAT, Yuri Vic yuriv...@gmail.com wrote: I look at some html file which is really in cp-1251 encoding. Cyrillic characters are not shown properly, which is expected because vim can't know the encoding. However, when I copy-and-paste such text (Shift-Y p), it stores it in the destination file as different byte array. For example, bytes cf ee f1 eb e5 e4 ed e8 e5 20 f2 e5 ec fb are stored as c3 8f c3 ae c3 b1 c3 ab c3 a5 c3 a4 c3 ad c3 a8 c3 a5 It appears, it probably tries to make it into some kind of UTF-8 encoding (judging by 0xc3 bytes). But why does it do this? Since it doesn't know the real encoding, it shouldn't modify bytes. You are understanding it wrong. Check out :h 'filencodings': Vim *does* know the encoding using its own algorythm for guessing it, just it guesses it wrong because of its defaults. There is no such a thing as unknown encoding, any opened file is always read using some encoding and you cannot avoid that. ~/.vimrc is empty vim is built from FreeBSD port. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJUaRF6GBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvptaD/wNAfgpFERsBAx0GElP4XSBPBmhmEPO1TJCLBrvrJsbr5I81eVVc4F9 zN3xsDug/DIZRWZcVkslwZYKMEQJX6zU7K2+d635+6Mo2/NVuPooeDWX0W4vON9T jXZlwG4Lnafyys/qVK+yrcQAGR3NYwsbUhgWXp9lkj87I4V2ROHDCC1opLFJhCXT U5sLgWxUidYRUC3/goiuWGnlshChfvmGzNADHWpNFaS1OnSLwku5hhgIskzy2gmh HcacjcgkqZ2O0aWJtZ9ta0COiTCVsKEpofH0sCFdugJSROp566VMjHp1puszNZa6 KNyq75DNgZ4rcjYs8jcIZoszD3xtLeBEmRMlAOz7LVVvBdyzCtDKuo4mH2k2PkrI pzS14b8X8roX+pejrC47P218vrEm16bzi5zgawZ864OrB1TUMOnPVsWCxaBFwxTi aRP+DuqiJuofGuPBs5pD9vAWUNyw6OvXhROLIMsanjO8FdA8KLlMx05LUa4ckSB3 ES2uvTvE4awkgvSrUOU0UcHFQSJSNG8xN6NE1kb0albFNjHvJe29BLUWAlq+38pt RbH4E7DbEWq0pBxCbVc3l+18dr5miEpqx2oEs+rHDu9/pHYTC/uqypDeoXbhWYfR WLOLlGeXFOA7e6vsZHOKNMSo+F8+kyVMk+Lc+yefRF8s/hMu89D4Nw== =fbcs -END PGP SIGNATURE- -- -- 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: allow to vimgrep current buffer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On October 29, 2014 10:54:38 PM EAT, Bram Moolenaar b...@moolenaar.net wrote:
Christian wrote:
On Di, 28 Okt 2014, Ingo Karkat wrote:
Well, then perhaps a separate :bvimgrep[add] set of commands would
be
better than overloading the existing commands:
:bvimgrep[!] /{pattern}/[g][j] [bufname]
:N,Mbvimgrep[!] /{pattern}/[g][j]
:bvimgrep[!] /{pattern}/[g][j] N1 N2 ...
Sounds useful. Bram, would you consider including this feature, if I
write a patch for that?
I think it can be done with a bit of Vim script, but it might be
generally useful, thus nice to work without installing a plugin.
It could also be a solution for something that doesn't work yet: Search
within a Visual block. Since this is going to be a new command, we can
make :',' respect the Visual mode, including block. So you could
select a block and type :bvimgrep /pattern/, then move to matches
with
:cn.
I think we can actually call it :bgrep. It's very unlikely 'grepprg'
is useful to search in buffers and it's shorter to type.
No. It is useful if you use something like ag (aka the silver searcher),
because VimL regexes lack full Unicode support. Also naming command like
bgrep in place of bvimgrep is inconsistent.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJUUjhWGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvu8xEACJearFWQR3HYeAV2G12pvCgKCYUIGhSTetmzBw52vh6yBepjQoq4qG
FyplLlRAa0XXAe9jakjNphnB45GzASnUHjtm/I/bmfJrHAISrFPwO9evsGWBDd2U
t3nV4e6he/fb636H6ZdCsnK7dJyp4ZvIgAylgcTchNfcJ/zgrAQZdj1dU+0rpFLw
I8NMAjBG65GUvmKVDZVivt9v8ljwnlhvgwi7TibvzKxKZjiMOWTIN3LShI3bwzjH
qyul0dBlP0DR8FUzVjJGDJyDGLXS4AIMswXc9Zws6qkDr35nd+emUxoOQjTvkkkP
fl7omQi3f1MaR5M5vsihdzMOGaQ5Hkh3CJ5PFxGHKOkbwdugTqRBKYdSGeS5irou
iuSF9ZbNUsdn+bNs4TfeQ4VnS2gGz4Vm70guXVduMZU+e38Lf34cuoW0/94owxTf
ZHUXOSaKHcXw4PrpLHkeGaQTz915LIX/a3vySzDjM7yFzvpKrTPHLCJFWIF5+lPh
bB3u0EsIvYZHWhTvKu6C33ahUPbzidUEdPTfd0ef9pN/jJUJTCjuqyOjNHp4Ns/s
Kz+xuHQSmL3dX/Nc9gMlcHZzO2bJD27iepswAwmAr56dvGXiepoyRlrpoApSbPY3
BLlAQvSm/A3cVr8WJcq/2I+DVpabl4e5ziFC9vz22jsDkaBHu+jmrg==
=z0oD
-END PGP SIGNATURE-
--
--
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] allow to vimgrep current buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On October 28, 2014 3:22:58 PM EAT, Christian Brabandt cbli...@256bit.org wrote: Am 2014-10-28 12:04, schrieb James McCoy: On Oct 28, 2014 2:40 AM, Christian Brabandt cbli...@256bit.org wrote: Am 2014-10-27 23:08, schrieb Bee: Just curious... How is that different from simply using `/` ? Is this a `just in case` scenario? I find it convenient to have all search results in the quickfix buffer. It'd be even more convenient to allow searching more than just the current buffer (says someone that wrote a buffer grep plugin). Sure, but I am not sure how to specify it: Something like this (vimgrep buffers 1-4)? :vimgrep /foobar/ 1,2,3,4 which would not work, if there is a file 1,2,3,4 We don't have commands, that accept several buffer numbers, right? Wrong. :bw and similar commands accept more then one buffer. But perhaps an argdo/bufdo :vimgrep would suffice? No. This will result in either having a hack for catching the situation vimgrep called from :*do or having a quickfix list with the results for the last buffer only. There is :vimgrepadd, but this is not going to empty quickfix list before proceeding. And :bufdo is a) non-selective and b) switches current buffer. Best, Christian -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJUT65yGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvkV/EACSwam1XxTBhas7Av6x3rxbcknrCzQGJ36OO4Ts3fLMcjSspODAFCBD 29etiHnn8yx2k+FC3WEfXIAa2nUsCR71b6KC5LenBao6umVI30haKjAOdOmIliF2 7HvF29unDZb1CSg9ldVsyiboPfmgwvy2WcteasbaKSLj6ABG8/zNoGLWhQFrr520 nT8R2ZTzmuKl7+N23ujCA0kIGjtFOD4fnNIu09NLhWCrpQCv36HylvIcVEFtfkbE yWJFubdPaGF4e9c0OP2OBDj6W6KSYrnsbAfurvZQPZolMBqa1KPnANE4OYloI9A3 OzVzQW3gEa3IhMXe5KR0geMM86HO3X1H9eH5OL7W9SmhQGqPEl0VJtkq86Pf0HYv tOJRc0+RJRhrMdJI7bKbCNemEuj2nh1pHP5w1sVJu4aaIW48ii1l3zD+L8LyaXJr YgTUI9u4L106AKBeL22PltBfV4s1RnKi5XU5lMpYI2XvNbhPkQekvFySXzfYCjuV LpUvvQxg66BdZ5BNBX8h3PL7UJOeH2y8ZO/EqnzhA+BNZ2VgTWDJV/NX3I4xUf0a anFH338NFqZ4zifjkfeByUZtHfUK3I1yK7l87ZNDuuwiyoXjN6s/lOESJP9PNiPp Fj6xY1dnVQstCb69Ij4ofxMgetez8/C8+onCzwLYpXFVU4L/py9ybA== =DZS8 -END PGP SIGNATURE- -- -- 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: how does set lmap apply to mappings?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On October 15, 2014 7:22:16 PM GMT+03:00, Christian Brabandt
cbli...@256bit.org wrote:
Bram,
what is the reason, setting 'lmap' applies to when a mapping is
remapped?
Consider this:
~$ cat lmap.vim
imap tab PlugMyPluginEcho
imap PlugMyPluginEcho c-r=hellocr
cmap tab PlugMyPluginEcho
cmap PlugMyPluginEcho c-r=hellocr
set lmap=i;k
run vim -u lmap.vim -N
and type tab in insert mode, note, how hello is printed in either
insert mode or command line mode.
Now do
:set lmap=i;k
and do it again. Note that PlugMyPluginEcho will be output.
The problem is, setting lmap breaks plugins (see e.g. here:
http://stackoverflow.com/questions/12450803)
I would consider this is a bug and actually think, that setting 'lmap'
should
never be applied to when recursively resolving a mapping.
Also, I do not understand what this part of the help is trying to say:
,[ :h 'lmap' ]-
| This will allow you to activate vim actions without having to switch
| back and forth between the languages. Your language characters will
| be understood as normal vim English characters (according to the
| langmap mappings) in the following cases:
| o Normal/Visual mode (commands, buffer/register names, user
mappings)
| o Insert/Replace Mode: Register names after CTRL-R
| o Insert/Replace Mode: Mappings
| Characters entered in Command-line mode will NOT be affected by
| this option. Note that this option can be changed at any time
| allowing to switch between mappings for different
languages/encodings.
| Use a mapping to avoid having to type it each time!
`
What are the language characters? What is the relationship to lmap
mappings?
This patch could fix it, but I am not sure, this fixes it correctly.
diff --git a/src/getchar.c b/src/getchar.c
--- a/src/getchar.c
+++ b/src/getchar.c
@@ -2196,12 +2196,16 @@ vgetorpeek(advance)
{
#ifdef FEAT_LANGMAP
c2 = typebuf.tb_buf[typebuf.tb_off + mlen];
- if (nomap 0)
- --nomap;
- else if (c2 == K_SPECIAL)
- nomap = 2;
- else
- LANGMAP_ADJUST(c2, TRUE);
+ /* do not apply lmap setting when
resolving a mapping */
+ if (typebuf_maplen() !=
typebuf.tb_len)
+ {
+ if (nomap 0)
+ --nomap;
+ else if (c2 == K_SPECIAL)
+ nomap = 2;
+ else
+ LANGMAP_ADJUST(c2, TRUE);
+ }
if (mp-m_keys[mlen] != c2)
#else
if (mp-m_keys[mlen] !=
Mit freundlichen Grüßen
Christian
--
Letzte Worte eines Dachdeckers:
Mensch ist das heute ein Wind
--
--
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.
This problem was already reported at least once. Do not remember any patches
though.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJUPpinGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvu3cD/9xrJmNrYXD3E2N13YZNJRG8Xns92yJrV7WDN5i5lu9sRBsGGgClLwK
UojjCCJNPPvUwZnLzzt1GzLBBjzOfQ2+E9KoJ0s0LJzyD8nsHJJyGq8sDuvPznwQ
vhOkLfcPp5G2/BejwxSF1ibkYKT78bHPbCOGvstO/QT5JvJhorjde8iVMLkkKOSs
30oUv4FjFePH0PPWRtBoGk9gqYe1JGm0McJwrRx+yigVzMWvPeRv2T2VWUZcCvoP
ecvXRxyKEIKY/57TNFOsdHDjSWYm4+vOHSmLYu/koNlHWmf2gRRB5TElxdx5WZ0d
S0dnrC3NQwNYygK8oS6ch9k2le4SVsatcyasa1N4Cc/0LuAOi7+gtdHVm3E5V2tq
IJZauhiJfTr4GA4482WeYCmYXcDggIfZIuO/Tl7vYGqRNAKr89OmghWEL85+xr/V
p2JmVssvIxQ7gzEyaeSbWIDLnP8Iv9tlXtOYJKo5rBhbzhKZAJTo6yIjhV3ssrQH
/ifLX8rwrZTR2m0OOenwTtz9A1mIOponrLwMWUMy+zdCpCQm7XuGZu3Tkn44UqLX
dx3ggJEyx9QFvMNHwNJwkGFSBHSmGjrIouPNll8uU2nkk0Ad7ADBlvTsw8malG+d
h+AKcGOuXoZJtDq43hJbN75NnFnB71aPl6Q8mSyyMVScnmuqmufn4Q==
=FERe
-END PGP SIGNATURE-
--
--
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
Re: Patch 7.4.457
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On September 26, 2014 6:10:35 AM GMT+03:00, Tony Mechelynck antoine.mechely...@gmail.com wrote: On 25/09/14 10:24, mattn wrote: I don't see what you mean with breakable. Sorry, I was confused. Until Patch 7.4.457, getchar() doesn't return \CursorHold. (However 0x80 0xFD was returned) I meant getchar() return only when it used with expr. augroup hogehoge autocmd! autocmd CursorHold,CursorHoldI,WinEnter * setlocal cursorline augroup END function! s:foo() let c = 0 while c == \CursorHold let c = getchar() endwhile echomsg c return '' endfunction nnoremap exprf SIDfoo() This function will always echomsg 0 because at the start of the loop, c is equal to zero which is != \CursorHold; hence Bram's :let c = getchar() just before entering the loop. Wondering whether you actually tested this. Unless \CursorHold starts with a number (it does not because all such things start with 0x80) it will be coerced to zero when comparing with numbers. So this loop is OK. I have not actually tested this either though. Remember that while (condition) DoSomething endwhile is equivalent (in a modified vimscript language using goto's and labels) to start: if (condition) DoSomething goto start endif Best regards, Tony. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJUKiGUGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvlHwEACZBZdXbQ0664w3bN5vybUlYtBqQ2hjvDaWS7nlDZ+Vcw2p37qdmmWw yZThd6Le0B7dji2ycqqqTR8TRH3cviwJBLjaraeMx59iX3Ipb7ICZ6poryEVRVaX K1INnzqpqxxOizd+aCVPELtCfriOJ8E1uGgtzumcrdPRzG+uwSoKfrLeoM3LxIS4 OLsXkSxsMpKiLbQxLw0RK30ANXUvkoFYl3QoHZO1F5aeAh8Pw3ONksm7c97zdaRc C0p+fTbC8KISF6VrqkPQsf5/grtfOSiYjKzrIu00G+6qMyZcrfeDCUyiFhNV/4kl Xs81zZ50rZqBlpcwmIvACCuEGDwIbAG5mzUxpx/IKSorb8bTOp2B6rR63yRfJ7k0 ND18sYRQrQ/vB1FPxvvzN9Wl/HGajHR+AJNTwTilwUH4Ur6Fugcc9DT0Vy/Ap1TG YCDyUU24OxSZWK5AY2AdponZjCWxmA6B8D8MayF6KbpBfyhE0ADGV6LBoqKP1Ex1 v8y7793H38316CD2Sn6cE6TYLveDOwTrCXfIhGrWJj6ExAP435drGrPkZuZ1kcGr pCh4tgdZhfWcc4OYgc5qpbZ8BvoW+hhruH80r1CalTSwS28QDAp4y4kq3Pq/S3AS kah3Yu4KLsbyVLVvpEp0sjnYypDRjfIfhErW7itRbPODb4YKyXiZKg== =FqoR -END PGP SIGNATURE- -- -- 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] Cut fold and sign columns at end of buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On September 29, 2014 10:39:16 PM GMT+03:00, Marco Hinz mh.code...@gmail.com wrote: Well, I suppose there is something to say for both ways. What do the users prefer? I understand that such visual changes are almost always controversial, especially for such a long-lasting editor with its big community. I'd argue that this patch makes the fold and sign column work as the number column is working already -- stopping at the end of the buffer. The functionality of these columns is to signify information about certain lines, but since there can't be anything after the end of the buffer, why should there be a column in the first place? Moreover, the end is also indicated via ~ markers, so you could say that some redundancy is removed. On the other hand I think that some people won't like the change, since it's really just cosmetic and brings nothing new to the table, neither a fix nor a useful feature. I know of at least one person who would like to see the exact opposite; making the number column continue after the end of the buffer, so that the ~ markers are always aligned with the actual start of the lines in the file. So, yes, the users should decide. -- -- 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. I also think that *all* columns should continue past the end of buffer because this way it looks better. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJUKiZcGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvr3/D/wMYYYauau8eMf20Q5jUKT0KRu+zxlfbESZFPX+qc5iBk+7aJEvViX2 rBhkvp8pV5gfkhW8P6y6vrE40Gh+McXF/1ksPn6WrgyTcDZ6Y3mn10SHenno/v33 PrAwzrikXsyskhWF/uXs2eV7an/9OPM7u78vJQ0JYYR9iPqgRbf1TSMmfnG73sme gnWSeyW2N+2vSbkTXQZFmFTJHQCc8NRski+lGVeeQLGTXGIvLOv9uOcXLtmXK6Bk gvPuQ+3Zff/35fbLxRLw/CCmNXNBnFb3JnuArUMclN1L57fo3Qnf9mDRSkerdz2M DEnPGHtmL6bwedGGxox8RDZ9U5iIY92JHUhb3nFX6oL6+t6vnv/H55Nit5nBNWaW vuLh3Rg6EY9HlbUNEl4fGS8xDShA1IpPJpYXYk9n4Kw+4pBViPhxKIDdiHWS4tVM 9gX5ZnzhqroRmkU6XMwiniViwHrXUZ8rDdbsyPUvsg2r61mek1czJ39Ui5RqVO5h vJNEkmG1l4plhgpj/aKNP+YeA4jV6fvaIom5EqhD0k1Rgz6A0BtRHVlBi96b/Gfk hnKmb2HaSdiacIFks7OKv6fQPpeNai6JCcRoIODCB42R6akbm9PxEjzuNkYGHlqs rfSyGpbZHBIB/dGg3L8fuSPMFZPjybGt9Otlhd16G3Qvzwx+quZfZg== =zglK -END PGP SIGNATURE- -- -- 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: 'set rtp' output is truncated to 1023 bytes on Windows 7
On September 12, 2014 1:46:51 PM GMT+03:00, Bram Moolenaar b...@moolenaar.net wrote: Nazri Ramliy wrote: On Fri, Sep 12, 2014 at 5:04 AM, Bram Moolenaar b...@moolenaar.net wrote: Although removing arbitrary limits is good, making 'runtimepath' very long is a bad idea. Every time Vim searches for a runtime file it will visit those directories and request the contents. Hmmm it seems that ex_cmds2.c:do_in_runtimepath() could benefit from a litte memoization, perhaps expiring the cache whenever 'runtimepath' is modified. That will very quickly get complicated. Esp. whenever changing runtime files. A plugin manager better use another mechanism. A dictionary to lookup what file is located where is a LOT faster. Sorry for not researching this thoroughly, but isn't all what a plugin manager does is populate 'runtimepath' and then leave all the rest to vim? My startup time has drastically increased on a system where I started using a plugin manager. I have asked before how we can make this work better, probably by adding some code inside Vim. Currently most plugin managers work in one directory per plugin fashion. If they were more like other package managers (especially almost all system ones) in one directory per purpose fashion (merged plugin trees in $HOME/.vim) it would solve the issue, but this is harder to code properly. -- -- 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: Add BSDL as another filetype for VHDL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On August 26, 2014 9:56:17 PM GMT+03:00, Daniel Kho daniel@gmail.com wrote: Hi, I'm requesting to add *.bsd,*.bsdl as additional filetypes that use the VHDL syntax, since BSDL (boundary scan description language) is a subset of VHDL. VHDL au BufNewFile,BufRead *.hdl,*.vhd,*.vhdl,*.vbe,*.vst,*.bsd,*.bsdl setf vhdl What do you guys think? I think it's probably easier to have BSDL use VHDL's syntax file, rather than create a separate syntax file that is a subset of vhdl.vim. regards, daniel -- -- 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. In such cases it is possible to set some b: variable prior to loading syntax that will make some lines guarded by the appropriate :if not executed. Or move vhdl.vim to bsdl.vim and create vhdl.vim that will source vhdl.vim and then add more syntax definitions that are vhdl-specific. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJT/MuwGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvi7cD/0YDOWx2Ozh92jge58zwUbdyJTcDWxF92FwFbdJl8MxBM9V6V2t/aka ZWtZc1xlFvMl61qcFKKxevlPnLi25ddfqzzjvj84Ev25TjegmiZm9Xkd2saOgt5S anSOhTb5VH/UBmVrL8NOAs1UiMXuTrzFDDP5vN2jTCUTQsqcsct2IEKkGLMzyX6E RhX+ZCh5A4LSF7D0mjQZOpEl2u0PWfmchiZQHYjTQ9z5AmcEDp3qw9fYV9mi7E+Q +rEtUMOk3GO26tTuKb7TQDKcc+m7zTTbQWFg7sIZEWA1GopIjh0xInkCRv2blgw/ kzzxLc3qQXkpQwxEndKjHsKSqoZaRt3BbrVSgVGQkaG+mLp97WZTEV35KKyi7rXo 8Yq3e3jTRGp73y/bX8X/yMPQ/uk+Ocjo+Quh687OyaAw1CsIjyulJ0NSCf8l7clb pf04lHC43ULWzr6R7ItjnlS0GvZc9kXjA+MPotfqrZmh1CcHTIAAHQOc3MeShgCB d+GASAya8LDma+KM8Q+WMGGAkWlarN3aELK/lb62YyyR5RVuS2qtrF3Nl7qwrQgP wCfR43y6ONgjm7cWX9xoGFUocTjwUftVVwasPJ+j+4PjMTyElBJDWzhW04r4XG3N WCrUucRD1DMYzTWbLtgy9U3dymyUnXhzQZsouz/WqTh8OPVu3XrVdA== =6aPY -END PGP SIGNATURE- -- -- 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] Lockvar does not work well with slices
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On August 18, 2014 5:16:44 PM GMT+03:00, Bram Moolenaar b...@moolenaar.net
wrote:
ZyX wrote:
On Sunday, August 17, 2014 9:28:25 PM UTC+4, ZyX wrote:
And fourth: behave like map: do its job until lock occurs and fail
at the first lock.
* The above code was for :unlet, for :let slice assignment there
should be something similar (except that option 3. will no longer be
consistent with anything).
Full patch for fourth approach (with tests):
Thanks for providing so many alternatives. In my opinion what most
people expect is that it either works, removes all items, or fails,
does
not remove any items.
Running map is different, since it's clear the function is called for
one item at a time. While removing is expected to do the whole slice
at
once.
I would not say so for map(). In most languages it creates a new list, so it is
expected to exhibit do everything or fail having done nothing behavior. If it
is to be thought about as a :for cycle replacement then it is expected to
exhibit do everything what can be done (unless in :try). There are also
languages where map() returns an iterator in which case (depending on code) it
may be even do everything what can be done (though with iterator you normally
may have any behavior you want, but usual uses exhibit same stop at first
error as Vim... if usual use is foreach cycle: other usual use is creating a
list in which case it is the first variant). In any case I would not expect it
to stop at first error, still having done something: either do not stop or do
not do.
Of course this only applies to pure (without side effects) expressions in map()
second argument.
And Vim constantly exhibits this behavior: does what it can until error occurs,
sometimes even after error occurs. E.g. consider
let var = (system('some-cmd-with-side-effect')
: command will be run, but due to missing parenthesis var will not be assigned
anything. Since VimL is the only language I use that does not have a parsing
stage this behavior is highly unexpected: all other languages will at least not
execute anything here, not to mention the vast majority that will not execute
any code in the same file at all. So fourth variant may be not expected, but it
definitely is consistent, not only with map(). After working with VimL a few
years this will even be expected.
I understand that the second solution is more work to implement, but
user expectation is more important.
It is rather trivial as well: more work is only by comparison. Most of work
(finding a place to fix for :let slice assignment) was done anyway.
Can you make a test for the second solution? The test for the fourth
solution should already be close.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJT8hh6GBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvjY6EACH47yFwYOcDU/2+DFYajs+DekQgf5DC6RL+wt2PoFHGW73qfYDF2Aa
Ic/T7arGrJvrLneD1zfnZKJQS4w5WlWg2JG8eU6NUvqKfKH5/dtAAnXRRDcQ3oZY
RVkmxEh+MtgLv33xjzgLIO698WpG926SxpjNBWt9OxwDM/g4wZni+dZ8ORFsN8EK
HflXCSP8jDtu5TiWKqb+n4s2aY2p6fWHINpv9jEnHYEZNUDeG6IaDS7AjNI+/KBT
ctwW0hpSt6BUgaZXoegufWeGFFWV3IkEv6jKuDw3kgaYOrwqxeL1iZB+O/aUnbOn
yHYte2FXTBWCSUlpfQZDrOVGHY7XXxzZFA3XNEGlyH/n6m7aJzevIDXVhQ/deXyR
gApuhmL2od0XD2i0x6I2BRhyDT2mglUmB8TbCC6O8AzTbbgwKgCxa/8zKyq3BE2A
e7bQz5DjOtfgvLYEI+UpZaBD1JbK+LzrjHIfpFkRSiMYC+3ZWohss6d+Czw9h3Qv
plQLikpWfYvphoJfBOVBIFwOdjFfY2ryO/8Y/VlxOUwXFNQCoXFoEgwaPXQsfDxq
K2VOi7Rsc5yrF2GUuGpNtdLEwXzUDjmW6ZlSM2d4YJ+t7Ym+K4ihcUooR83eQfDS
FaJ7mRnCaSckNRFx7yqjhc41O+l7iz1bFNxNKw/PF0Q6QuCi7/iA5A==
=bMl9
-END PGP SIGNATURE-
--
--
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] getcmdwintype()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On July 26, 2014 4:07:01 AM GMT+03:00, James McCoy james...@jamessan.com wrote: On Fri, Jul 25, 2014 at 12:04:09PM -0700, Jacob Niehus wrote: I think this is a useful function to allow different mappings depending on the type of command window (ex, search, input, etc.). I can add documentation if people agree. This is just reimplementing getcmdtype(). Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@jamessan.com -- -- 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. No. This is for q/ and q:. getcmdtype() returns empty string in normal mode in these windows (checked with nmap expr e ':echomsg '.string(getcmdtype()).'cr' ). -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJT0vIGGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSviiKD/99zGYDUC57IQwTs7lH85NvMnNJxhIns0uiqrvJUjQME64YfvKAbByo 9SGAFhcJTQtKexydJXjGN0bo6jefOWuONmFay3mW0BlgCRZFK6qC9iUFajjhGc6o p3j6tkjEkna19a+dR/YNzTxwbnyNCu1LX0vqgR48E5aVneuoQ5GRVpHDpCJy+Ibx JhnAdFBloaFeLwf3b+c64cQmMIXkNk+vKb8V97bd5Dauw3FoVAS6/Gp0TlRIwhTm Zc6tQTDzdiPXIxexIjA4y2bH8iqyZc+Oj0aZ434Rs1OAVpre/gfOB73SGEuuFPfG 5LlwgL65a6wzFW5rk6YW4hm8kMadzyUu/l0huxm8hjTmtu4mh/DXd91hdANNyNKP DO3qS0bbpAunUK+WNtRC9kTk+grYShJlIDBSA/MEbJs5VhbQi8322cgMyF1bJzKQ tTtm+lotozY8Dqsi9O0lmAMMXA6ry0u1VNIWwqdDF35fg/AN3WIOrN2Hjy08J3nK wbzO5xFyj1QLmrfx3ZiAzvshOLU0UpKSo/xecHaoAt1VhaI/bYmlflZKCCtT7N3a fZ7//bnsHfWVJC5MBD0sKtMOtwHmOSBEaeMDbWfmhCrY+rs1Du/zuA45ZmqMe5Tf QvJw4iiXf9BNjd1MkEogVDNhCi/y7NxMqJZxNZ3kPvRRVmPhlVdFtw== =zMyM -END PGP SIGNATURE- -- -- 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] getcmdwintype()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On July 25, 2014 11:04:09 PM GMT+03:00, Jacob Niehus jacob.nie...@gmail.com
wrote:
I think this is a useful function to allow different mappings depending
on the type of command window (ex, search, input, etc.). I can add
documentation if people agree.
-Jake
diff --git a/src/eval.c b/src/eval.c
--- a/src/eval.c
+++ b/src/eval.c
@@ -554,6 +554,7 @@
static void f_getcmdline __ARGS((typval_T *argvars, typval_T *rettv));
static void f_getcmdpos __ARGS((typval_T *argvars, typval_T *rettv));
static void f_getcmdtype __ARGS((typval_T *argvars, typval_T *rettv));
+static void f_getcmdwintype __ARGS((typval_T *argvars, typval_T
*rettv));
static void f_getcwd __ARGS((typval_T *argvars, typval_T *rettv));
static void f_getfontname __ARGS((typval_T *argvars, typval_T *rettv));
static void f_getfperm __ARGS((typval_T *argvars, typval_T *rettv));
@@ -7984,6 +7985,7 @@
{getcmdline,0, 0, f_getcmdline},
{getcmdpos, 0, 0, f_getcmdpos},
{getcmdtype,0, 0, f_getcmdtype},
+{getcmdwintype, 0, 0, f_getcmdwintype},
{getcurpos, 0, 0, f_getcurpos},
{getcwd,0, 0, f_getcwd},
{getfontname, 0, 1, f_getfontname},
@@ -11503,6 +11505,26 @@
}
/*
+ * getcmdwintype() function
+ */
+static void
+f_getcmdwintype(argvars, rettv)
+typval_T *argvars UNUSED;
+typval_T *rettv;
+{
+rettv-v_type = VAR_STRING;
+rettv-vval.v_string = NULL;
+#ifdef FEAT_CMDWIN
+rettv-vval.v_string = alloc(2);
I think there is at least one compiler or static analyzer among used to compile
or check Vim which will complain here. You should move = NULL to #else.
+if (rettv-vval.v_string != NULL)
+{
+ rettv-vval.v_string[0] = cmdwin_type;
+ rettv-vval.v_string[1] = NUL;
+}
If I am not mistaking the whole alloc+if sequence may be replaced with
vim_strnsave(cmdwin_type, 1). Though this is kinda hack, you should probably
ignore the suggestion.
+#endif
+}
+
+/*
* getcwd() function
*/
static void
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJT0vPfGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvo5+D/93YSMDrtzhOiZBlKc+2FbHQBOSU0rvrOx5Vkex39f/mk+AmeLJH1tv
wAgQG9iHIVlTIV6FyhwhmP1Muq6NuejlVSUQMnIJEhEscw+1trRIasP8xq8/EyyW
TpiTVQkvzRR0glBM1kg3rh+KhUIKy7dqGTjtxFDSVd00BzLG5365q7roLeCrF0ep
j6pGbz0vP6obtU00++tVOJErb5Uzk5OkgixWDweqAzg7ri/Hu+piUGCTIILuBx2V
m05DQAmdTs9SySZQSXeuGhcbVlP8iZkMp/MPMSYQf/Wb9VvdMVimeBUeLMUyC3Bs
u1F5hgRrgV735ra6hzwdAlTP1EiaB/hD2dKqw+QQmwpD9u/xDlnGC25emlWpBGbx
BbN/pdSiAbBz7LTUDFoLX+mFEUYq8XbuxI/qqowzm7CcVUCVWx5l1Ykcfzca1P/w
fMeuP3IWfU4z7igCapd5r2PsMHCxWJOzdeTjvsh+y/EBKryV5H4QJMkrwb24VqfA
l6NSu11mWB10SKzoIZn/c8xEFkYlIUxiH6eQjaqqSCMCWwIgcHeKy9orkZ+JF4tl
nkh+ee+0vser/Dje8HPguG8N5L+v+3zA6IZtRHDzj5TROq6Z7Fnm04E4Ky4YXTK9
4HfLT7L4kzZlG/xW2wo5iQvjsMmol+smowa72Ck5ltA/b9lE2Lz2PA==
=oV3V
-END PGP SIGNATURE-
--
--
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: odd character drawing problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On July 18, 2014 5:56:26 PM GMT+03:00, Charles Campbell charles.e.campb...@nasa.gov wrote: Tony Mechelynck wrote: On 17/07/14 21:55, Bram Moolenaar wrote: Charles Campbell wrote: The following line, when in a buffer that vim is displaying: m=⎣ℜ(b-a)⎦=1~1026 has the script R displayed correctly when the cursor is swept over it from right to left, but the script R is displayed incorrectly when the cursor is swept over it from left to right. I'm using: Scientific Linux 6.5 (Carbon) vim 7.4.372 set guifont=Monospace\ Bold\ 12 configure --with-features=huge --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp --enable-cscope Looks like a problem with the font: the character is wider than the display cell. Thus when drawing the character to the right of the script R it erases the rightmost pixels of it. Reminds me of a problem I've had in the past with a totally different font, and without doublewidth. Once upon a time I used Lucida (Lucida Console on Windows, Lucida Typewriter on Linux: I still used both platforms then); then I noticed that in bold Cyrillic I had the problem described: sweeping the cursor over the text made it look wrong when swept in one direction, right when swept in the opposite direction. On closer look, the bold Cyrillic glyphs of the Lucida font were apparently constructed by superimposing the unbold glyphs with a copy of themselves shifted laterally by one pixel, and thus the bold glyphs were one pixel wider than the normal-weight glyphs (and than the declared glyph-width of the font), which gvim didn't like. So I found a different font (Bitstream Vera Sans Mono) which doesn't have this problem, and can AFAICT display Latin and Cyrillic with or without bold or italic (or, of course, underlined) with no problem. Dr. Chip, maybe you can find a different font, which has the glyph but not the problem? It may require some trial and error. I've been through all the fonts that have mono in their names on my system; each of them has the same problem that Luxi Mono has. Most of the rest look like they use double-spacing: i e . t h e y r e s e m b l e t h i s; although that does mean that the R shows up completely. I'll probably just make do with having that R look like an F most of the time. Are you sure they do have fullwidth characters? Last time I tried to say something like fullwidth characters from terminus work perfectly in defence of the position that monospace fonts do have characters with different width I was pointed out that there are *no* fullwidth characters there meaning that whatever library is responsible for displaying fonts is picking them from some other font. I.e. more experienced people have told me that there *cannot be* characters that occupy more then one display cell in monospace font. It may be a key to what you are seeing: 1. Most of the monospace fonts have the same problem do not actually have it because they simply have no glyphs. 2. Most of the rest have fullwidth characters fitted in one display cell effectively meaning that at least half of the two cells' space will be occupied by nothing. 3. You have not mentioned, but probably the rest that shows rectangle or whatever missing glyph symbol is there do not have fallbacks configured to take glyphs from (this point may be absent). 4. You also have not mentioned, but if some font have sane fullwidth characters then they probably have different font as fallback (this point may be absent). 5. Some fonts are broken as described by OP: they have glyph, but it is too wide for them to be able to have without breaking something (in first case problems are caused by fallbacks that are too wide as well). Am I right (especially about 3. and 4.)? To actually check present glyphs you need either things like fontforge or terminal (or other program capable of displaying fonts) that is not able to use fallbacks or can omit using them. One of such terminals is urxvt (rxvt-unicode): it has its own configuration for fallbacks. Some others use fontconfig. I am not using gVim, so had never seen such problem: konsole+vim/zsh seem to handle everything fine. I only used fullwidth characters for some tests though. Thanks! Chip Campbell -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTyUFQGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvm50EACZdaXgTNIVtVtr48Bg0HsGkrBdoNberj+tfGwy9TxVukrjw4wnda0F MUofSCGdGXbua+G/kIyQ0sj9VYODJxAOvPHz40chH5H0ACbpClAlvV1rL+bIdSoU NMB10EyqFuFkJ+7sB4n6dT/CqISt7gyF5kSzJ0OATh295n7fxdGZF7HqnLya3/Hx IOQpvNSF3PiPj1PYrLp7h0YrbO0aM5S+MOnPiGCycslNTx/TDZztQ9jj3bTmkadM rDzt/AOHsAfcy+eA9GtM1UHhOnyGac4FrZCkIz33yxupOPfRJM0w4aisK5la4/8v jRGGMOFtgVddN1xZfdVnB0FXLY2ivXGnwuDnkVRjlbpYIwLwUXOeM5T0TxO0px7l z4d1eOl6V5iMjp5gRdnjEZBcjxHYRbFasfaB85ZkdjupCkCI/PXwXNU0N//lrZhs e9kARSIFxLnvrw2jaAH0mBmrCn+640GSGqzWBsZP/wc+2T0ijwK/4s/n2Hu9Ya+0
Re: Issue 238 in vim: linebreak causes control characters to display incorrectly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On July 14, 2014 6:09:22 PM GMT+03:00, Christian Brabandt cbli...@256bit.org wrote: On Mo, 14 Jul 2014, v...@googlecode.com wrote: Status: New Owner: Labels: Type-Defect Priority-Medium New issue 238 by kimmy.li...@gmail.com: linebreak causes control characters to display incorrectly http://code.google.com/p/vim/issues/detail?id=238 What steps will reproduce the problem? 1. Open vim, enter some control characters (^A, ^B, ^C) 2. :set linebreak What is the expected output? What do you see instead? Expect to see ^A^B^C, instead it shows ^^^. What version of the product are you using? On what operating system? Vim 7.4.364 on Linux. Please provide any additional information below. An hg bisect gives v7-4-353 as the first bad revision. Sorry, this was my fault. This should fix the problem. (I'll update the test, once Bram has split up test_listlbr in utf8 and non-utf8 part). Best, Christian -- In der Welt der Frauen zählen nur die anderen Frauen. -- Esther Vilar -- -- 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. Replies here are not posted to the issue tracker. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTw/4LGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvnuND/sE5OvFZvw3EaQ5xBHChm04dKqBGtp9x5zHSEdNiwmJoyxVY0qTbXki nzx8TSlCjFjvBaeOKT+Yhvvo92f7Txp5xuE2WSNq1ndbZLBFb0LKUz/xX7r7XLwb +YQYoQ1rsvtJ1bnZyUMgTQ+SfBCMwQxAXnpdCIpDSiZFKp1nzUpBdsQh7JIRFr28 YZ6SgsFd5FeA6keHBPP96Hb8vFwwUzlzbcm31uPrsP6jO7kkFNcmJtfBp+UOw7qE /ulvZ71plVdAKRdRcVFIa3gb7oe5oIuWp9uSnp7FTYK/tvuWuIJgzWgBCpak6d0x c6Me9QyBOtbhQbZDUwUfSFRMAyLMLJBB0XdXIuNq98T65e/eMV9ynh+NKH1wHxIR QsO4fRqgwDuuBni43Nfq0MdVDZE8VIRAPq/8PNRQKtNG1HRvWnfiGLiuECy6wnKo UkaXlBYZEjIvd3ptjlE6/fjK4lI0MJbD83xga0276XaI2ZOvKDj4owASqOnl03Q/ oEaGjiOijT4Lk9qWixdm97k4M2OjDbqGrXI9EbudCwyCM8i8tLUbdu8trZERz692 wXe4ruCu6uJjbzO6ZK1YMRuSjVekL18/OdkQcMvHU7lOCDPOXRVrS1ANZNQjzoNs ZjdbJgJ/RlkzlDincEX2djrvV+lGWisabQwesur0zRo4sKLrWIjoZw== =VwxG -END PGP SIGNATURE- -- -- 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: LUA interface giving me trouble with garbage collection patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On July 10, 2014 7:49:02 PM GMT+03:00, Ben Fritz fritzophre...@gmail.com wrote: On Wednesday, July 9, 2014 11:24:50 PM UTC-5, Yukihiro Nakadaira wrote: Here is sample code. [edited] L = luaL_newstate(); lua_pushcclosure(L, add, 0); lua_pushinteger(L, 111); lua_pushinteger(L, 222); lua_call(L, 2 /* nargs */, 1 /* nresults */); r = lua_tointeger(L, -1); lua_pop(L, 1); lua_close(L); Thanks! I'll give this a try later. What's the -1 for in lua_tointeger()? Almost all lua_* functions operate with stack. -1 is stack index. Like indexes in lua itself 1 means first value in the stack, 2 means second, ..., -1 means last, -2 means last but one, ... In lua_pop you though specify how many values to pop, not which element to pop. Is there a good way to test this when I'm done? E.g. are there LUA tests in Vim's test suite that will exercise the garbage collector? Or maybe a toy script using the LUA interface I could run myself? -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTvrb/GBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvmnCD/9oKtyxddAIENOS3Yj+18oqxBAfgNFKjNiToD7tY87rx999YYFevnIc KhgHaoiqcyw4cmTLWnBduoA1VmtUGt8iwxT9VXoOpw6HfbWqiuaqAsoIKrLIoLZp H7zcLZIQX763eimUY/PsUgzDVShR73OsjHl8x0PcoYXsh80KcW42Fa5xNoV7O4lr eqnG5V3OsQ6zcOz+SjUN6J3yHITDOpLGe0YNBuSctPqRtHooNR191rzfylQAJna9 5Mx5r05rXAg++HKF6sb7btf0lWMaUmYNJvTweRaxd6mSywxgwh9M+jZ7yiGXE9r3 thD7Be3Tk7woQT0ZdgkoioH6/efZNovoVf2NB/eOU17w3Dxm0doHfyH/s4xH5Dqq 4m2wJMtwlV2R0SYVYjzSOUXBVRxunUlU9m0K4CV2FUUwabLGaEJvmfegUt25sUlL pcO1OFaJNLjGyHM96xbMwv1GpjRgUAfSjVbbDHxjeV/GeanemLlp8etYw1CTP9zs CNNlVMzoHMSvYC8dGO4lqv7fdXNSFzvfUT/lL6i4trxVupgCvZ3oxWX4VUBTHRd4 Zzjr20iVLe4TGJTlSyCScvpMSZGdNiEEBhYhUpZGE20J5On7w5y2XHryrsNn+dOP ZLNVywtzroQxKaLK79aOf4UDJhH2eKTGpuOiKQCnTk7/TxUXlPadTw== =UYLM -END PGP SIGNATURE- -- -- 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: matchaddpos(): a mini-review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On July 6, 2014 6:27:28 PM GMT+03:00, LCD 47 lcd...@gmail.com wrote: On 4 July 2014, ZyX zyx@gmail.com wrote: I agree 100% that it's broken. They still do it. For what it's worth, I had to look at the sources at many of said compilers to get syntastic to understand their output, and using virtual columns isn't *that* far fetched. Most of the time they just expand tabs while parsing and don't bother keeping track of the original offset. When they run into an error they just compute the column number by adding the lengths of the whitespace and the tokens parsed so far. Double width characters is a different story. Some compilers use Unicode codepoints, others byte length, which is, again, broken. Still, Vim's virtual columns is yet the best approximation of it. I think the best solution is proposed colnr() function: check out [that thread][1]. virtcol to byte offset transformation is useful not only for matchaddpos(). Yes, a colnr() function would be useful, both in this situation and by itself. I had to write it in [translit3][2] and that variant is rather slow. Your proposal will fix matchaddpos() for one given use-case and only matchaddpos() and only under very limited conditions. colnr() is not so limited. I'm afraid you lost me here. I just pointed out a number of (what I consider to be) problems with the design of matchaddpos(), which I found when I actually tried to use the function. I never attempetd to suggest any solutions. Your colnr() might be, IMO, a reasonable solution for one of the problems I noted. It doesn't address any of the others. Absence of some colnr() features is not only a matchaddpos() problem. It is helpful for one of matchaddpos() problems you pointed out, but it is not the only scope where this function is useful. Fix to matchaddpos() to accept dictionary with vcol, on the other side, is only useful for matchaddpos(). I say that you are seeking answer in a wrong direction. [1]: https://groups.google.com/forum/#!topic/vim_dev/2DYfyTuo7G0 [2]: https://sourceforge.net/p/translit3/code/ci/040e92e8021320740109067dbe2fb43e50fbba94/tree/autoload/translit3.vim#l2262 /lcd -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTuarNGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvh1LD/wN4veq+vWKGR/XlGFqy03o9HEee2Zw807fv8/zBuhvfHFdXoNHb+FV B4ZtaUEeEofrWorr2RxLQQ8Z8N7rHfLyz9zjUbXzCBqF/KPYACKW2sdXYXKi5nTI lNHku1O6ohe3/WzrcXD5/vjiXNNhqIbzU9+Xoq5Kr43MzHphsQAp38CUgcni78Rd qXaOllrN/ep2I6gBKCeQ4xCjvoNBLT8+ef1eci9yaDR7W4ry+DybRpzx2P1n2BNl PwsSS+tDH45hjgr6huCMftYsZJRONM5te7FQRW+GEIhL3fmbeKL3imhCtsZAP+2M 5TwrIzRGyg/9JzUawwDa0W1EJ6BUvL6h57tGb/hV605XU+z5/NdL2mEgpc1BNbtu 7kPSDMKPxJJPD5NcGl2x6Syg7GxUrdXDXUfwrrx9wzEYoz0NsoBgI2QsCVZz7061 qQRBpXkVEVcM1abEA7dMVuF5giN5U86IHW8w0Xd4mdOLY4yLisPgA1m0iFCDHatt ykOtm4sB6N9FTWP9QuFclvL0hyB/j9FyTl72fCduxfZPIR+PaJKrshcbNXslXE4e qgw5g7wH/yryEjidja3RAyWkVc7McUsEKjgz6Y+Gl1/Tenjibyo8LoP1nBhlhBDl cqcYvTOOtB5APUMMn4ZodsPxoT8qWGnGQGwZzfVHcb+mGeza82Vchw== =D961 -END PGP SIGNATURE- -- -- 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] matchaddpos(): fix for multibyte characters hl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On July 4, 2014 6:55:28 PM GMT+03:00, Alexey Radkov alexey.rad...@gmail.com wrote: 2014-07-04 18:22 GMT+04:00 Павлов Николай Александрович zyx@gmail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Are you sure you need exactly screen cells? There are the following possible ways to identify position inside a string: 1. Byte offset. 2. Unicode codepoints offset. 3. Composed characters offset (one composed character is one Unicode codepoint with attached composing characters (if any)). 4. Screen cells offset. Ok, i can imagine all the use cases but i cannot map all of them against their usage frequency in majority of the vim plugins. If I have known that 4 is very rare i would not have suggested this patch :) ... I just remember that LCD asked for 4 in Syntastic plugin. Most of vim functions return byte count. No external tools may return correct 4., inside vim 4. is only returned by virtcol() and strdisplaywidth() AFAIK. I doubt anybody will use 4. outside of a editor because it is hard to calculate. There are two settings that affect 4. and are only defined in a editor: tabstop and ambiwidth. *You must not use screen cells offset with editor settings if you received it from another source.* It is incorrect: you need settings from another source, not from this instance of editor. And ***do never use screen cells to count characters***. Code that assumes any fixed amount of Unicode codepoints per one cell is brain-damaged, broken and wrong. For this patch I heard the following use cases: 1. matchparen. Will happily live with byte offset. Not really. Apart of the fact that it gets matching parens in a wrong way like c = getline(c_lnum)[c_col - 1] which will always mean 1 byte symbol, it uses matchaddpos() (or 3match earlier) that rely on 1-byte symbol too. This code is not going to be fixed by matchaddpos() receiving screen cells. Regex engine does not rely on number of bytes in composed character. Cannot say the same for matchaddpos(), but I doubt it does. I made an experiment: :set matchpairs()+=в:д These symbols are not pairly highlighted with matchparen whereas '%' works just fine: the reason is simple: both result of getline() and matchaddpos()/3match must know that symbol under cursor is longer than 1 3match does not need to know this. Neither getline() does. Script author is who must know this, there are some more correct ways to get character at given byte offset (depending on what character means). And no, indexing must not know about length of characters. *Must not*. There are some valid use cases for byte indexing. Special functions for taking character (with different meanings) at given byte offset would be very handy, but so far nobody bothered to create them. byte, it means that script must calculate it itself. 2. Highlighting of errors from some source. May not use screen cells under any circumstances for the reasons explained above. 3. I think that things like Conque may also benefit from this, but they do not need screen cells as well. On July 4, 2014 6:00:06 PM GMT+03:00, Alexey Radkov alexey.rad...@gmail.com wrote: Ok, probably so. If script is able to calculate the end in bytes itself, then the current solution is good. But if it knows how many screen cells it must highlight it is getting almost not feasible to calculate the end col. if case 1 is more common than 2 then current solution is better :) 2014-07-04 14:05 GMT+04:00 Bram Moolenaar b...@moolenaar.net: Alexey Radkov wrote: Now it accepts len in screen cells. Hmm, that's confusing. Suppose a script isolates a word that it wants to highlight. Then it's easy to locate the start of the word and the length with various methods, e.g. using getline(), match() and matchend(). Then you have the position and size in bytes, not characters or screen characters. So let's stick to that. In the implementation it should be easy to round up, so as to include the screen cell that contains a highlighted byte. -- There are 10 kinds of people: Those who understand binary and those who don't. /// 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: matchaddpos(): a mini-review
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On July 1, 2014 9:54:00 PM GMT+03:00, LCD 47 lcd...@gmail.com wrote:
On 1 July 2014, Bram Moolenaar b...@moolenaar.net wrote:
lcd wrote:
[...]
First, the interface:
matchaddpos({group}, {pos}[, {priority}[, {id}]])
Here, {pos} is a list of lists. In principle this allows one to
set
a number of highlight patterns at once; in practice, it means:
* call matchaddpos(group, [a]) - highlights line a
* call matchaddpos(group, [[a]]) - also highlights line a
* call matchaddpos(group, [a, b])- highlights lines a and b
* call matchaddpos(group, [[a, b]]) - highlights one byte at
position (a, b)
* call matchaddpos(group, [[a, b, c]])- highlights c bytes at
position (a, b)
This is (1) ugly, (2) inconsistent with matchadd(), which
can only handle one pattern at a time, (3) it adds an artificial
limitation to 8 patterns per call, and (4) it doesn't offer any
simple replacement for matchadd(group, '\m\%5c') (that is
highlighting columns, top to bottom). Perhaps a better choice
would
have been to make {pos} a dictionary (or a list of such, if you
absolutely can't help it), with all elements optional, like this:
{ 'line': 3, 'col': 5, 'len': 2 }
The main thing was to highlight one or a few characters at a fixed
position in the text. Such as a parenthesis. Text is usually
located
by byte index, not character index, since it's quicker.
True -- unless the column number comes from somewhere else, such as
a compiler's error message. Sometimes you don't get to choose.
*Virtual* column number? Compiler author must be crazy to write this, and as
explained in the other thread (with a new patch for matchaddpos() to support
screen cells) it is incorrect to blindly use it without setting settings to
exactly those of the compiler.
Can you please read that thread and explain whether and why you needed screen
cells? I have a discussion there with an explanation why screen cells are
inappropriate for matchaddpos(). OP was saying that you requested it, but I do
not see why.
[...]
The limit of 8 makes the implementation simpler, and I can't think of
a reason why someone would want to highlight more than 2 or 3
matches,
thus 8 seems like it's sufficient.
So what? Once part of Vim, matchaddpos() is just another function,
two weeks from now nobody will remember why it was added. Sooner or
later somebody will find a creative way to abuse it, and will find
himself banging his head against the desk because of this limitation.
And in this particular case it's a limitation that could have been
avoided basically for free. *shrug*
Back to {pos}: the column number is a byte offset. Since there
are no standard functions to convert between screen columns and
byte offsets, this means one gets the pleasure to deal with tabs,
multi-byte strings, concealed characters, and the like. If {pos}
were a dictionary, as suggested above, handling virtual columns
could be added with a 'vcol' field (again, optional). Please note
that matchadd() handles things like '\%5v' just fine.
Is there a problem with using virtcol() before passing the position
to matchaddpos()? Passing the screen column makes things much more
complicatet, but it would be possible.
The problem with virtcol() (and most similar functions, for that
matter) is that it isn't independent of the surrounding context.
It requires either the cursor, or a mark to be set to the position
you care about. In a script this is horribly intrusive: I have to
save either the cursor or a mark, set things up for virtcol(), find
out the position, then restore the cursor or mark. I just want to
convert between screen columns and byte offsets, dammit! It's a length
calculation, why on Earth should I care where the cursor and / or the
marks are?
[...]
Last but not least: is there any reason why this is a separate
function, instead of an optimisation inside matchadd()? There are
a finite number of common fixed position patterns, so it should be
possible to just look at the patterns passed to matchadd(), and
treat them specially if they involve only fixed positions. It's
really, really much more of a pain to leave this to end the user.
Parsing the pattern is difficult, and for a script writer creating
the pattern is a hassle. Passing the position with numbers is much
simpler on both sides.
It's simpler in simple contexts. In more complicated contexts it's
less useful, because it plays by very different rules than matchadd().
/lcd
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJTtsgLGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvvDAD/4hDK2LgDnx9E+Cdju2R9XlcGP8mofbBq6boOcrnEy/PrEfsINP5LkT
qXnmCqwDDXMxf9/YduaGfZAbMyVUSILFqDntN0LoM2kH/k0pIpXyKmoA9NzWz0RU
ZIpAqd5cPC1pnW2PH8j73l1Lb7JXorAVBnzGa2By2fZZQ0rirS+jnFcn+OaTz9c/
Re: Regexp 'very (no) magic' flags do erratic behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On July 3, 2014 6:59:52 AM GMT+03:00, Ben Fritz fritzophre...@gmail.com wrote: On Wednesday, July 2, 2014 1:57:09 PM UTC-5, Ozaki Kiichi wrote: Hi. In regexp operation, \v and \V, in contrast with \c, \C, \m and \M, disable the preceding '$' (end-of-line) atom. This seems to be inconsequence. matching end-of-line echo 'hoge' =~# 'hoge$\m' | Expect 1, Result 1 echo 'hoge' =~# 'hoge$\M' | Expect 1, Result 1 echo 'hoge' =~# 'hoge$\v' | Expect 1, Result 0 - ? echo 'hoge' =~# 'hoge$\V' | Expect 1, Result 0 - ? Shouldn't you need to escape the $ with a \ when using \V? \V only *starts* the region. It does not affect the whole pattern. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTtODWGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvoe0EACj7eDSj+L2z+fwjssHRsapopQL5YZmhUqrY9Rym+RHEzrMsF07WmyA Zzl4zO7fBm1XCuIe1enA2pRI4Udy6Sq0XurfhOpHcqiePfwBcJqYG3QZqPWrX4nG A/hZefHGAN63LCH37RJubpzEkrJ6x4CIpEbNVsSvgmylTr99NV6IKcLwAX/1hM1R uGurE8R6BSSgps0g8TqdHMwwRw/dOP4NvOEu3OO5s33iTRNLv81JXm77gP5qe9Dl 17lkeCtHTCYrmJ95ULGnKapJ7FFx2OXW5U3VCSboKUXn9eBaw9DKbUOi6Atzvsnt hThHxJsBUu4fiDrnWnR09O9Aqh87Zfu1gPQqCeCfdNC1OUZNWQMVf2LKLj7Nt2IW sb9iSyPWBszQatz6MKDzT/iAfJhBWAolEAHHA26SjYuPbe4ErJzt48lApo2az6Li b8T+PSloHU/Z5CY+IlrPzoNUKFmBP7SYOKcLi3Hu1NCYLV09sHdfnRPf7So96sy8 AzshC84gXfFuGfk0mHW4Xoy+XsBte9mFTxPjlpBz5tFTqtnqIwG2q3WyD1cXlhKK 7rVy0vQyw+hwn+QPExpwDJeD81E3C7kJpD2lK0/gBr/VY1y2qGq8J5dJPoJgAtkc iQGkOpAmxnV8DAlhHr2KZy6gr9zv8wMfaa/PQWAzpK4mUYwHKYCNJQ== =fQA/ -END PGP SIGNATURE- -- -- 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: matchaddpos(): a mini-review
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On July 1, 2014 9:54:00 PM GMT+03:00, LCD 47 lcd...@gmail.com wrote:
On 1 July 2014, Bram Moolenaar b...@moolenaar.net wrote:
lcd wrote:
[...]
First, the interface:
matchaddpos({group}, {pos}[, {priority}[, {id}]])
Here, {pos} is a list of lists. In principle this allows one to
set
a number of highlight patterns at once; in practice, it means:
* call matchaddpos(group, [a]) - highlights line a
* call matchaddpos(group, [[a]]) - also highlights line a
* call matchaddpos(group, [a, b])- highlights lines a and b
* call matchaddpos(group, [[a, b]]) - highlights one byte at
position (a, b)
* call matchaddpos(group, [[a, b, c]])- highlights c bytes at
position (a, b)
This is (1) ugly, (2) inconsistent with matchadd(), which
can only handle one pattern at a time, (3) it adds an artificial
limitation to 8 patterns per call, and (4) it doesn't offer any
simple replacement for matchadd(group, '\m\%5c') (that is
highlighting columns, top to bottom). Perhaps a better choice
would
have been to make {pos} a dictionary (or a list of such, if you
absolutely can't help it), with all elements optional, like this:
{ 'line': 3, 'col': 5, 'len': 2 }
The main thing was to highlight one or a few characters at a fixed
position in the text. Such as a parenthesis. Text is usually
located
by byte index, not character index, since it's quicker.
True -- unless the column number comes from somewhere else, such as
a compiler's error message. Sometimes you don't get to choose.
[...]
The limit of 8 makes the implementation simpler, and I can't think of
a reason why someone would want to highlight more than 2 or 3
matches,
thus 8 seems like it's sufficient.
So what? Once part of Vim, matchaddpos() is just another function,
two weeks from now nobody will remember why it was added. Sooner or
later somebody will find a creative way to abuse it, and will find
himself banging his head against the desk because of this limitation.
And in this particular case it's a limitation that could have been
avoided basically for free. *shrug*
Back to {pos}: the column number is a byte offset. Since there
are no standard functions to convert between screen columns and
byte offsets, this means one gets the pleasure to deal with tabs,
multi-byte strings, concealed characters, and the like. If {pos}
were a dictionary, as suggested above, handling virtual columns
could be added with a 'vcol' field (again, optional). Please note
that matchadd() handles things like '\%5v' just fine.
Is there a problem with using virtcol() before passing the position
to matchaddpos()? Passing the screen column makes things much more
complicatet, but it would be possible.
The problem with virtcol() (and most similar functions, for that
matter) is that it isn't independent of the surrounding context.
It requires either the cursor, or a mark to be set to the position
virtcol() does accept lists (line and column pairs).
you care about. In a script this is horribly intrusive: I have to
save either the cursor or a mark, set things up for virtcol(), find
out the position, then restore the cursor or mark. I just want to
convert between screen columns and byte offsets, dammit! It's a length
virtcol([linenr, col]) will do. The opposite conversion (screen column to byte
index) is much more complicated.
calculation, why on Earth should I care where the cursor and / or the
marks are?
You should not care. You should read documentation.
[...]
Last but not least: is there any reason why this is a separate
function, instead of an optimisation inside matchadd()? There are
a finite number of common fixed position patterns, so it should be
possible to just look at the patterns passed to matchadd(), and
treat them specially if they involve only fixed positions. It's
really, really much more of a pain to leave this to end the user.
Parsing the pattern is difficult, and for a script writer creating
the pattern is a hassle. Passing the position with numbers is much
simpler on both sides.
It's simpler in simple contexts. In more complicated contexts it's
less useful, because it plays by very different rules than matchadd().
/lcd
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJTsvpiGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvsIxD/9epkAOLmd7uYuuZoFu72i9904UjwMdRhPRUzXh6M2UQlEKB1MWxVNZ
HlgELFYX70g8fFrVrxZgWm77UCq8ON7SzUyZf11z4hxygUFoOm3Fr2F1WBvrB0jn
292G0N4F1nIpcqWvdnLbcS0PHPL9Ykv00wuAGt/hLRIO1jDjCUExlaumIotOxzW5
x0TmGrD54coe+e1CEugnnu80W/yoFHOymlBlfXPm+373cO1BB2zYSZMts8ZJxo9p
R8c7TQHyQ7fGYGU8guUIwLsWkele0h5LGJ8+h8+u53hqlGqx5pQfrZpGoG4AMFZQ
+s96UE21w78L0dDjaFnYAo75Ehx0FL66z/eDxgVPhu8FUJMb/UmcpWUACv3xIR8J
pYsGNvobbP7Wx807TKzgsOVA0fdtjkTRasjnqfIKZc/6E6GVS56SrnsB02EEO+xv
//NczJdBNTcOzRv1HqKmpynVczGqsYX/FEAWQOxZ+X8NvqDQwM9phhHy6Q0DvCrv
Re: r in normal mode (= replace single character) does not respect insert mode mappings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 You should read documentation. I do not use this feature, only know that it exists. On June 30, 2014 5:26:06 PM GMT+03:00, Enno enno.na...@gmail.com wrote: Le lundi 30 juin 2014 05:06:27 UTC+2, ZyX a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 :lmap mappings apply to r if iminsert is set as documented. Documentation does not say about :imap mappings. I do not think it is a bug. On June 29, 2014 3:26:37 PM GMT+03:00, Enno enno.na...@gmail.com wrote: Is this a feature or a bug? This occurs under a Vanilla gVim 7.4.326 under Windows 7 x64, or a Vanilla Vim 7.4.326 under CygWin. To reproduce: Start vim. Type 'x', then type :inoremap ; /CR then type r; Expected: The buffer contains the single character '/'. What we got: The buffer contains the single character ';'. -- -- 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. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTsNQfGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvlRgD/0cVe8nUK6aqsrcJ6ca6rdmxbUNbtgSPHfT4MmprW4ktmKquB7UmRaW FBGzmbvoHxPT2lnATxwUwosTjevh2IVQjNsKL/RPKkr68Iqc9nRghQhsf1+al/SZ AF3A2K9ZXf+mFJYUTNQOViysQ6TtVqpNareVYnAoa9f1VRpfSx1Nvj8L87TrW7i5 PddRf6L1iF1L2UEmHLzi5Qqk+cPVVPqIjvWI8azILMYKb7HgIcSl1s3/KS7W8YXG pvunuqHPYFVF5GxtM4LIYUxUFTshM9n8ITXpq4idnIHU9W6r3rq5Ojj57YZNbOry eFZ//AabEihOj+zdkjEvsPO1Mdl8L1hDmeKAGx8hWO12W3L6Co6RuzE5CYLr4yHP wo/g3gLU4A/U694fR/M7TZuZsFlQtPw7gztkcz0gJlyBjFGG79fae0Rx+KfgoVN3 flqZNDnh8VmZFJ4DDRkYpAAj9ka/3I1Hyo4HU8KNuYdVrwzpt0bK4uhzsxXQK32D TzgWFWeXIM97O1W4o1TMPyH9SXXQrNcvA9mgYKsVYp7F4aBaUvrx/uEXkrTnScyw Ldp49DwYNM8sZx4ASjZD4EgoFSpdzZSCc7IGii/No5ONpzoJfao3Jyk6tdZGLro5 LqTXT2MrqJTZx7KC5krqTU7v+O+Jd9rCjnQPjYAAGupYi7nuS4MT/Q== =UVDx -END PGP SIGNATURE- Thank you for the hint to iminsert. This brought me to the Lang-Arg mode (comprising the command line and insert mode). Now I suspected that 'lnoremap ; \' instead of 'inoremap ; \' would achieve the desired behavior, but it does not change anything. Does iminsert need to be set to make lnoremap work, 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/d/optout. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTsY5YGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvlPtD/9sjEq1agRstFHJacjT+1uxUZjwbN2moszOA4EwOxAXLgTFXR+CMIHc Tk8H/C0FDu4gSLNYVorh43xrjslQHX9pSAgrQEYf9noYcfbfv0ZO0nmJ3MMke6oE DeLwaUnjyKCd1bHqXVJoDCoWapNinSnvZK0H4/XqfWevHYSE42g95QyR6KSMFgS7 BwWKS4bAF6SF6/TPcAOFTOiurgibGxZrRVRmlnKDMfCmvUV11A3RBAdvo1WwZtqS SXUQAGF9QihnuxNyu+btTIB5bYEGKghZrmNEf48dWl5QcQUCLJDoeNxsHu6FImZA dJEfKIVNiF+zmptr5wICdNeN6at83+li8NE3bNcXgSRSRIZFHKjTtcyO/46WQTJw SySDruj1Ud/gjjuu3qj+ZSq9m+YTYZ40bgLE69tDF/xMU1jB5lK+5hYuHlLK0Inl uzpdbH9cZO+iCITlEH3WeJ1TgaeHqJmMvGTh8U/BkLWJKNfudaU/9PK0nEWU97Y4 4+lcs+R8ntFgaexQiW44Cxwrjh3SoEz704vOHhv3beFkzplCXFJB5KCpPjmbJpLZ t7zHy7cs3rCbUZPR7rSOBzQJx4xkajtJIsVJ4DJas0CzGU/7igy/Q5tm29G6B+tK ump5bzeATWf8FjKziwrPJXkjuR9G4dmg26hSoZm3k2h6IrOise6Dfw== =L8kk -END PGP SIGNATURE- -- -- 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: r in normal mode (= replace single character) does not respect insert mode mappings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 :lmap mappings apply to r if iminsert is set as documented. Documentation does not say about :imap mappings. I do not think it is a bug. On June 29, 2014 3:26:37 PM GMT+03:00, Enno enno.na...@gmail.com wrote: Is this a feature or a bug? This occurs under a Vanilla gVim 7.4.326 under Windows 7 x64, or a Vanilla Vim 7.4.326 under CygWin. To reproduce: Start vim. Type 'x', then type :inoremap ; /CR then type r; Expected: The buffer contains the single character '/'. What we got: The buffer contains the single character ';'. -- -- 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. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTsNQfGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvlRgD/0cVe8nUK6aqsrcJ6ca6rdmxbUNbtgSPHfT4MmprW4ktmKquB7UmRaW FBGzmbvoHxPT2lnATxwUwosTjevh2IVQjNsKL/RPKkr68Iqc9nRghQhsf1+al/SZ AF3A2K9ZXf+mFJYUTNQOViysQ6TtVqpNareVYnAoa9f1VRpfSx1Nvj8L87TrW7i5 PddRf6L1iF1L2UEmHLzi5Qqk+cPVVPqIjvWI8azILMYKb7HgIcSl1s3/KS7W8YXG pvunuqHPYFVF5GxtM4LIYUxUFTshM9n8ITXpq4idnIHU9W6r3rq5Ojj57YZNbOry eFZ//AabEihOj+zdkjEvsPO1Mdl8L1hDmeKAGx8hWO12W3L6Co6RuzE5CYLr4yHP wo/g3gLU4A/U694fR/M7TZuZsFlQtPw7gztkcz0gJlyBjFGG79fae0Rx+KfgoVN3 flqZNDnh8VmZFJ4DDRkYpAAj9ka/3I1Hyo4HU8KNuYdVrwzpt0bK4uhzsxXQK32D TzgWFWeXIM97O1W4o1TMPyH9SXXQrNcvA9mgYKsVYp7F4aBaUvrx/uEXkrTnScyw Ldp49DwYNM8sZx4ASjZD4EgoFSpdzZSCc7IGii/No5ONpzoJfao3Jyk6tdZGLro5 LqTXT2MrqJTZx7KC5krqTU7v+O+Jd9rCjnQPjYAAGupYi7nuS4MT/Q== =UVDx -END PGP SIGNATURE- -- -- 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.336
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Why 10 000? I set it to 65 536 and it runs fine (except for slow startup due to
me keeping history not in viminfo (when keeping history and other things in
viminfo only you are limited to one vim instance: with two or more vim instance
that exited last wins and other instances' histories are thrown away)).
On June 25, 2014 1:49:14 PM GMT+03:00, Bram Moolenaar b...@moolenaar.net
wrote:
Patch 7.4.336
Problem:Setting 'history' to a big value causes out-of-memory
errors.
Solution: Limit the value to 1. (Hirohito Higashi)
Files: runtime/doc/options.txt, src/option.c
*** ../vim-7.4.335/runtime/doc/options.txt 2014-05-28
21:40:47.088329130 +0200
--- runtime/doc/options.txt2014-06-25 11:44:16.985950668 +0200
***
*** 3920,3931
NOTE: This option is reset when 'compatible' is set.
*'history'* *'hi'*
! 'history' 'hi' number (Vim default: 20, Vi default: 0)
global
{not in Vi}
A history of : commands, and a history of previous search patterns
! are remembered. This option decides how many entries may be stored
in
each of these histories (see |cmdline-editing|).
NOTE: This option is set to the Vi default value when 'compatible' is
set and to the Vim default value when 'compatible' is reset.
--- 3920,3932
NOTE: This option is reset when 'compatible' is set.
*'history'* *'hi'*
! 'history' 'hi' number (Vim default: 50, Vi default: 0)
global
{not in Vi}
A history of : commands, and a history of previous search patterns
! is remembered. This option decides how many entries may be stored
in
each of these histories (see |cmdline-editing|).
+ The maximum value is 1.
NOTE: This option is set to the Vi default value when 'compatible' is
set and to the Vim default value when 'compatible' is reset.
*** ../vim-7.4.335/src/option.c2014-05-13 12:16:44.037555110 +0200
--- src/option.c 2014-06-25 11:44:48.349951855 +0200
***
*** 1392,1398
SCRIPTID_INIT},
{history, hi, P_NUM|P_VIM,
(char_u *)p_hi, PV_NONE,
! {(char_u *)0L, (char_u *)20L} SCRIPTID_INIT},
{hkmap,hk, P_BOOL|P_VI_DEF|P_VIM,
#ifdef FEAT_RIGHTLEFT
(char_u *)p_hkmap, PV_NONE,
--- 1392,1398
SCRIPTID_INIT},
{history, hi, P_NUM|P_VIM,
(char_u *)p_hi, PV_NONE,
! {(char_u *)0L, (char_u *)50L} SCRIPTID_INIT},
{hkmap,hk, P_BOOL|P_VI_DEF|P_VIM,
#ifdef FEAT_RIGHTLEFT
(char_u *)p_hkmap, PV_NONE,
***
*** 8595,8600
--- 8595,8605
errmsg = e_positive;
p_hi = 0;
}
+ else if (p_hi 1)
+ {
+ errmsg = e_invarg;
+ p_hi = 1;
+ }
if (p_re 0 || p_re 2)
{
errmsg = e_invarg;
*** ../vim-7.4.335/src/version.c 2014-06-18 21:38:12.216418355 +0200
--- src/version.c 2014-06-25 11:45:08.141952604 +0200
***
*** 736,737
--- 736,739
{ /* Add new patch number below this line */
+ /**/
+ 336,
/**/
--
ARTHUR:Well, it doesn't matter. Will you go and tell your master
that
Arthur from the Court of Camelot is here.
GUARD #1: Listen, in order to maintain air-speed velocity, a swallow
needs to beat its wings 43 times every second, right?
ARTHUR:Please!
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.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQI1BAEBCgAfBQJTqrPOGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSviYGD/4vzxu40YuMR6DoNbfW2C2q6m/W3ZMWVb3mpUJt3av3RXNrQpUVzbDR
S63LfcgONnF3jKebOZ6evI5+9v/BazJcDrxZf1vapujhgil8U7NLzzp7WzOmy4X7
Nu6kGojhaHW4pX5G+FdqZyLZdT5YRrPj6wBpy5eDCdi25dlfigBArO44ZjpMLIcA
Re: Patch 7.4.336
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 100 means that useful commands will disappear rapidly (testing some complicated pattern or one-line scripts easily generates 10 variants). 65 536 is there because I periodically happen to remember lots of one-liner scripts I never intended to repeat (and thus did not add to vimrc) or which appeared as too trivial to save (I have it in history: good, saves some time; do not have: well I will retype it in a minute). Though due to macro feature, wipes during testing of parinfo and the fact that my long-running vims are more likely to crash then to exit I did not yet hit 10 000 limit in vim, but in zsh I am close to it. On June 27, 2014 12:33:09 AM GMT+03:00, Bram Moolenaar b...@moolenaar.net wrote: ZyX wrote: Why 10 000? I set it to 65 536 and it runs fine (except for slow startup due to me keeping history not in viminfo (when keeping history and other things in viminfo only you are limited to one vim instance: with two or more vim instance that exited last wins and other instances' histories are thrown away)). It's just an arbitrary limit. Large values are not useful and will blow up the viminfo file. Something like 100 is realistic, thus allowing 100 times that seems like a good limit. The fight over who exits last still needs to be fixed, that is an annoying problem. Should really take the last typed commands, that requires storing timestamps. -- The question is: What do you do with your life? The wrong answer is: Become the richest guy in the graveyard. (billionaire and Oracle founder Larry Ellison) /// 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 /// -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTrIeuGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvnysD/4qLytR7getpOshJdfyvHZ4A6VbNMeC1nH5vbP6Ts7/QaE1DvpykARg zv25PUQOP1b/evP7xgE2z2v+6Ed41XoQ+XzSm9d6eWnJoUMWS7AmYDKKj302n1e7 fq4UX27BqujmdkwHKDn+5XkA0neOY9EmO8XhnZUrYj91gL2yMj4FiM+/YJr4rzfE Aqasomf+FHm32fHrX5UW2kECW3MCTBxSCQi4tsaZNiT8GaxbNsOjgoiO4yTNCCqC spAuv0niBUh4gMdNRjfKbUGN2D6MfTqtKUeLJpjHGm0VCQct1GdLVMvV2TMm3jFq LXFlJ7NaFftNPbeLEEomykVTT25nDIZPlPBoSYX5+YG3g7RvYC2gbWtBBdspKwEQ BOFR0oRhU4r+8Y3PmofDfv3886Iuxe0qlYOm0X3g1yOIpoa/TGERdWaYV1YFuo1l G+uBjITMNaPjkA8gBvAwJomSQkZbZXwxxDKTKrlhbhfz9NncyXZ2ia63i5XS+3w1 NTvC4NfBsVZPrHxglsDaqY5jFYnLsQYX9sRjABTlNs4lWF6ZzhSICosM78AiW+cW LgHIYUBOiWdxCsbsA96QT1QKsmuWLM3OE6GEEorz3QFP0rv6lpr9eo64lxFwQ0/c Pjdyp4dgLyxViWZctjckfHQD8hkunzzGJd4LMSlD0HJ6o7UXJIZvzw== =V3hn -END PGP SIGNATURE- -- -- 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: virtcol() subject to showbreak (added: and linebreak)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On June 4, 2014 3:48:42 PM GMT+03:00, Ingo Karkat sw...@ingo-karkat.de wrote: On 04-Jun-2014 13:34 +0200, Axel Bender wrote: I'd already be happy if virtcol() would take into account the length of the showbreak string. I'm otherwise prepared to work with UTF-8 characters... Character widths are not directly related to this, but that little incorrectness in your otherwise precise and welcome bug report shouldn't have provoked such a rant. Sorry. I consider this a flaw (well maybe a bug?) that should be fixed. I can reproduce this issue with 7.4.264. Even worse, :set linebreak also affects the virtcol() value and makes it wrong (when such wrap occurs). So, one only gets correct values out of virtcol() with :set sbr= nolbr; which indeed should be fixed! I am not sure it is a bug. Most likely it is absolutely correct behavior: pretend you need to know on which virtual line of the current line cursor is located and on which virtual column on this virtual line. Please describe how you will solve this with current behavior of virtcol() and with proposed one. Discussing whether this behavior is a bug or not is pointless without showing the use-case. I know that the above task may only be solved with bugged virtcol(), otherwise you will have to do option parsing for yourself which is a waste of time. I though think that virtcol() behavior is not a bug, but documentation is incorrect (it says the last screen position occupied by the character at that position, when the screen would be of **unlimited width** which obviously contradicts with the current behavior: no wraps are possible on the screen with unlimited width hence these options may not apply). -- regards, ingo -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTjzDRGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvg4uEAClhxgkmHRrWOvApOa70j8Zzw560RRQA6xRspJWg9UiyOEEsc2e+7O1 3gMy2HBr3kdPz7dwtWpe3azoDPvvIQe2+cznn1HPuqxtsQfGy/bWntGbBknpNhff 3V3AAD2DfmjU+0mu9gUs5+9NG7ROZg0PfHSgRkbfa759cD7GUG1fsVBPsbPy+aYM jjEV27/X61pkKsF5JgyyFpNG7pYXYrAEl9JiH0/QSuXYYjt9ptwHoEdrdwF9CFVi Ums+bp74pGwyOCMlVoVUImJT3MrHk6yiUFAgGBZqZsFWUsRYTvFluxWMTD6pLeJz +wL6WCnVxqRIZxvKFtySmZeAgRF1aRWVbFOEFz0IUjv1yhCleNWNVSdCK7FAFmvO Z6aSfyxTcgaKw9SEOxBtwysl8+BrmERv26zGt4Mfo6zxHLgPEV6eGA6e7wdWmy0z 9Cb4VKl395aLvlH2BqTQdKCp5OPhYt9wiVTHtB8LVM6DIMkyGOsscbLFNRiLedfx SovSVnsl2jzszxeOzKtmHW5uKMrrutNS3dVilZCMs1j/qm45+b0O+KGpiMwNTNHP wxJYU5jpXGEjZePZ98F5nUmopRFKDmNNfiMJQCuxVCNUJN6HKA2NfTWRiVb98HQx F05yoz1yfjEVtkWJjt+7Tg8JXCta55BkW8QhyRTgJNQLDFNUWJOQZA== =5tsG -END PGP SIGNATURE- -- -- 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: virtcol() subject to showbreak (added: and linebreak)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On June 4, 2014 6:44:34 PM GMT+03:00, Павлов Николай Александрович zyx@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On June 4, 2014 3:48:42 PM GMT+03:00, Ingo Karkat sw...@ingo-karkat.de wrote: On 04-Jun-2014 13:34 +0200, Axel Bender wrote: I'd already be happy if virtcol() would take into account the length of the showbreak string. I'm otherwise prepared to work with UTF-8 characters... Character widths are not directly related to this, but that little incorrectness in your otherwise precise and welcome bug report shouldn't have provoked such a rant. Sorry. I consider this a flaw (well maybe a bug?) that should be fixed. I can reproduce this issue with 7.4.264. Even worse, :set linebreak also affects the virtcol() value and makes it wrong (when such wrap occurs). So, one only gets correct values out of virtcol() with :set sbr= nolbr; which indeed should be fixed! I am not sure it is a bug. Most likely it is absolutely correct behavior: pretend you need to know on which virtual line of the current line cursor is located and on which virtual column on this virtual line. Please describe how you will solve this with current behavior of virtcol() and with proposed one. Discussing whether this behavior is a bug or not is pointless without showing the use-case. I know that the above task may only be solved with bugged virtcol(), otherwise you will have to do option parsing for yourself which is a waste of time. I have a use-case: if you need to move to some character you usually use bar motion and bar motion ignores additional characters from showbreak. Thus I would suggest to patch bar motion to also take breaks into account like virtcol() does. I though think that virtcol() behavior is not a bug, but documentation is incorrect (it says the last screen position occupied by the character at that position, when the screen would be of **unlimited width** which obviously contradicts with the current behavior: no wraps are possible on the screen with unlimited width hence these options may not apply). -- regards, ingo -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTjzDRGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvg4uEAClhxgkmHRrWOvApOa70j8Zzw560RRQA6xRspJWg9UiyOEEsc2e+7O1 3gMy2HBr3kdPz7dwtWpe3azoDPvvIQe2+cznn1HPuqxtsQfGy/bWntGbBknpNhff 3V3AAD2DfmjU+0mu9gUs5+9NG7ROZg0PfHSgRkbfa759cD7GUG1fsVBPsbPy+aYM jjEV27/X61pkKsF5JgyyFpNG7pYXYrAEl9JiH0/QSuXYYjt9ptwHoEdrdwF9CFVi Ums+bp74pGwyOCMlVoVUImJT3MrHk6yiUFAgGBZqZsFWUsRYTvFluxWMTD6pLeJz +wL6WCnVxqRIZxvKFtySmZeAgRF1aRWVbFOEFz0IUjv1yhCleNWNVSdCK7FAFmvO Z6aSfyxTcgaKw9SEOxBtwysl8+BrmERv26zGt4Mfo6zxHLgPEV6eGA6e7wdWmy0z 9Cb4VKl395aLvlH2BqTQdKCp5OPhYt9wiVTHtB8LVM6DIMkyGOsscbLFNRiLedfx SovSVnsl2jzszxeOzKtmHW5uKMrrutNS3dVilZCMs1j/qm45+b0O+KGpiMwNTNHP wxJYU5jpXGEjZePZ98F5nUmopRFKDmNNfiMJQCuxVCNUJN6HKA2NfTWRiVb98HQx F05yoz1yfjEVtkWJjt+7Tg8JXCta55BkW8QhyRTgJNQLDFNUWJOQZA== =5tsG -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTjzMOGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvvTUD/98tB8KRVDs+HEA2msY0VbsPvETHCHalvd1GWGRybaPd1MFSP4amiAd xzwSMcFSYbDGq2F0QKwYe+mQxefr0wBiv4ko/HyL4lLv+/Bf9St/EO+fPO5EsILg EXwI5eEvgr/aLFiXllluyegWhSZgelz3QsmkSKlbhMaU1RZ3xj10fTyIGp6S/tRi IOVXD54MbEfxMr5Y9k3JMuhu/bUK+UBNYyOyUYrH/w3uX5Li0XhRkApt1tcaed5H I8aRwcIvzgs05mNzaRnJA5b4e1RhEa60VYvPYonR4UFwR5mUG8LRN/6/PwGL0KDP +xC2Uv0Eez0P1u/FWna5Thz9YolA65mEm+lVu4D4ZlXapZTwo3hbgvl7NnZfshtr Gpl/Vm7CLtXbt3EqeRw63oKXpbyEuh1pgpBKB43bZ29IcIuyIaihSp/ajxksQE+z ozZCpYPc+BbbYxFK5mJCg7eAucwU5hQP8OHdGIJh9Qbx2EDqrhEO84eMdo2e41oq NKgnOdFfO+xSdH/kfc4agsy56vtkMuynn1jtT/GbkKmWz4HikPFLnoHVoYsEF57g OIK9kXYPrUzeeBzqs0xBIKsMZGaLfmoxbC7Rcg+3lXUSw2JyhalXufgTTP2RVbJR kPx7DVv0iVVpigw0Xqsw1e0Px64FjJopZwibP0xEGJ+FxHSVAtgt7w== =Mj64 -END PGP SIGNATURE- -- -- 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: virtcol() subject to showbreak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On June 2, 2014 10:18:40 PM GMT+03:00, Axel Bender axel.ben...@cip-kommunal.de wrote: virtcol() fails to deliver the correct screen column if showbreak is set to a value other than and wrap is on, i.e. it doesn't take into account the length of the string that showbreak is set to. To reproduce: 1) Start a bare gvim with a text containing a long line. 2) :set nowrap 3) Position the cursor at the beginning of a word towards the end of the line. 4) :echo virtcol(.) 5) :set wrapMake sure the cursor is in a 'wrapped' line 6) :echo virtcol(.) Returns the same value 7) :set showbreak=(--) 8) :echo virtcol(.) Will return a distinct value col(.)'s return value would not change, but it's not Unicode (UTF-8) proof... Neither is virtcol(). In Unicode you have the following things: - - Variable-length tabs. - - Control characters which take one byte and occupy two or four cells (depending on vim settings). - - Fullwidth characters that are 2 cells wide. - - Ambiguous width characters which are one or two cells wide depending on terminal and vim settings. - - Combining characters which are zero cells wide (and are sometimes considered a part of a symbol). - - Unprintable characters which occupy at least 6 cells (e.g. U+FFFE represented as fffe). Additionally there are - - Incorrect bytes that vim represents as XX. - - Different terminal encodings which may alter Unicode character representation (I have not tested how though). . All this affect output of virtcol(). If you want to count a number of characters you should use something different. If you need exactly display cells do not say it has something to do with Unicode. In the last case you may use col(), getline() and strdisplaywidth(). -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTjboSGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvvKPEAClwRq4OAAsuVjxZiqjfjkntq3jbai29zetIWEVS75pO4lZDYr6mHqD xa9+KVFNxUzKby8zh1CYQpp0+rU2dO0XW53j6lhYRKW+t2QfswPjC4TX3wECdJKv uuQQa2m/khnWpXV0mUizainIj3MWPVNu89/5xqcE7vyGAlq+kTl8N2h7l8933+Y0 2GAydQit6T6c8DK5h2P/v/uZrokSSKaF7zhdwo9RxFlzpX09fmX1llkllB1TxMF3 jvGhLlLAnrgVj8DFWabj6xCij8zchHc1vw4qRy8vVJEGllTyDSAQHyQm2rvmrrzw 5ZuIbr/w6DgdJKwM98qH9QedPFpxVfziv7S0hGTzyknvxr5HM1Ct4ac3MilewSY/ N/NDczDdB+OPUq7zluuvXMdASDIiNcCYQWd1uCyEcZogapjmZ1xT60FQFm+QLZ9e RIrnBSPsx5lJl1V6Hpm4minAPQfXEdfXovF+I6rHVjuBfBQvn/KcDt13mdriYzwQ jXyrNg7Ys2mdxq3exlWUcVbiBeb57eg518ihw6pvZghagFizV3BV8CB7WJwjqmME 2I8pTmsmPL3RxbAlnP49b1K4DqqamrsiwCFQVycG2RKrLxyzNC9QbU0WUaagHuen 473Fy3wAOk7OUzgNV3H2k7aEQpq7lYG1LsJ+LorCx73TV96X9dIhSw== =ONg5 -END PGP SIGNATURE- -- -- 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] XDG Base Directory Specification support (v3)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On June 2, 2014 12:54:39 AM GMT+03:00, Jean-François Bignolles
jf.bignol...@gmail.com wrote:
Hi,
I made a new patch (based on vim 7.4.315).
Le mercredi 28 mai 2014 19:49:50 UTC+2, Bram Moolenaar a écrit :
I had a look at this.
First a small remark about the patch:
Places for your personal initializations:
-Unix$HOME/.vimrc or $HOME/.vim/vimrc
+Unix$HOME/.vimrc or $HOME/.vim/vimrc;
+with |+xdg_basedir| feature, it can also be
+$XDG_CONFIG_HOME/vim/vimrc (first place)
That should be $XDG_CONFIG_HOME/vim, without the /vimrc.
No. $XDG_CONFIG_HOME/vim is a *DIRECTORY*, not a file; it's an
alternative
choice for $HOME/vim. This documentation extract talks about the
vimrc,
the main Vim user configuration *FILE*.
Problem with making this a compile-time feature is that if the binary
is
shared with several users, or it's part of a precompiled package,
suddenly the user has to put his Vim files elsewhere. This will
quickly
lead to two different binaries, so that users can select the one that
fits them.
Making this a runtime option is problematic, since the changes are in
the default values.
In the new patch there is no compile-time switch anymore; XDG support
is
always enabled, but in a way where compatibility with non-XDG version
is
preserved.
This is far from ideal, I expect it to cause more trouble than it
would
ever solve. Who actually uses these $XDG_ variables?
For end user, defining $XDG_ variables is is optional, not mandatory.
For the developper wishing to support XDG, interpreting them is a
requirement: it allows the user to overide default locations.
That's why special logic is added for $XDG_ variables expansion.
Probably the only way is to ADD these $XDG_ directories, after the
current directories. So that they only get used if the old
directories
do not exist. Then users getting a new binary will not notice a
difference, and are free to move their files to the new location, if
that is that they prefer.
The new patch does this.
In practice this probably means users would do:
mv ~/.vim ~/.config/vim
mv ~/.vimrc ~/.config/vim/vimrc
Exactly.
So, let's give a short description:
- vimrc: $XDG_CONFIG_HOME/vim/vimrc is added (3rd choice).
- gvimrc: $XDG_CONFIG_HOME/vim/gvimrc is added (3rd choice).
- viminfo path is unchanged, but the user can use 'viminfo' option.
- 'backupdir' and 'directory': $XDG_CACHE_HOME/vim is added (2nd
choice);
if the user doesn't create this directory, Vim behaviour is unchanged.
- 'runtimepath': $XDG_CONFIG_HOME/vim and
$XDG_CONFIG_HOME/vim/after
are added, but don't replace $HOME/.vim and $HOME/.vim/after.
- 'viewdir' is unchanged (since it's a single directory option).
regards,
jfb
Note: can't make Attach a file to work, so the patch is appended...
AFAIR Google has extension filter in their web interface. You need to use name
with a known extension; .diff is known to work.
-8
diff -r 07aa56179a10 runtime/doc/gui.txt
--- a/runtime/doc/gui.txt Thu May 29 11:47:40 2014 +0200
+++ b/runtime/doc/gui.txt Sun Jun 01 22:10:28 2014 +0200
@@ -1,4 +1,4 @@
-*gui.txt* For Vim version 7.4. Last change: 2014 Mar 08
+*gui.txt* For Vim version 7.4. Last change: 2014 May 30
VIM REFERENCE MANUALby Bram Moolenaar
@@ -66,7 +66,8 @@
- If the GVIMINIT environment variable exists and is not empty, it is
executed as an Ex command.
- If the user gvimrc file exists, it is sourced. The name of this file
is
-normally $HOME/.gvimrc. You can check this with :version.
+normally $HOME/.gvimrc. It can also be
$XDG_CONFIG_HOME/vim/gvimrc
+(see |xdg_basedir|). You can check this with :version.
- For Win32, when $HOME is not set, $VIM\_gvimrc is used.
- When a _gvimrc file is not found, .gvimrc is tried too. And vice
versa.
diff -r 07aa56179a10 runtime/doc/options.txt
--- a/runtime/doc/options.txt Thu May 29 11:47:40 2014 +0200
+++ b/runtime/doc/options.txt Sun Jun 01 22:10:28 2014 +0200
@@ -1,4 +1,4 @@
-*options.txt* For Vim version 7.4. Last change: 2014 May 13
+*options.txt* For Vim version 7.4. Last change: 2014 May 30
VIM REFERENCE MANUALby Bram Moolenaar
@@ -988,7 +988,7 @@
*'backupdir'* *'bdir'*
'backupdir' 'bdir'string (default for Amiga: .,t:,
for MS-DOS and Win32: .,$TEMP,c:/tmp,c:/temp
- for Unix: .,~/tmp,~/)
+ for Unix: .,$XDG_CACHE_HOME/vim,~/tmp,~/)
global
{not in Vi}
List of directories for the backup file, separated with commas.
@@ -1008,7 +1008,8 @@
name, precede it with a backslash.
- To include a
Re: global command slow when clipboard=unnamed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On May 29, 2014 9:25:05 PM GMT+03:00, Praful Kapadia praful...@gmail.com wrote: I have had an annoying issue with gvim 7.4, with patches 1-307. If I open a large file (e.g. containing 200,000 lines) and use the global command to delete lines, the operation takes a very long time on Windows if clipboard has been set to unnamed. I'm assuming it's the constant copying of deleted lines to the Windows clipboard that's slowing gvim down. I use Windows 7 64-bit. I have compiled gvim 64-bit using ming. The issue occurs on gvim 64-bit, 32-bit and, to a lesser extent, on MacVim. On Windows, it takes several minutes to carry out the operation. During this time, Windows becomes unusable, which is poor but that's another issue. On OS X, in MacVim, the same operation takes 30 seconds. With clipboard=, it takes two seconds. Do not mislead yourself. '' character starts a comment, so set clipboard= is equivalent to set clipboard=unnamed which is really (after you strip comment) set clipboard= . There is also no need to balance quotes: set clipboard=unnamed means the same thing. Use let clipboard=... syntax if you want '' to start a string and not a comment. Here are the steps to reproduce the issue: 1. Open gvim with no plugins and no vimrc. 2. :set clipboard=unnamed 3. Open a text file with about 200,000 lines. 4. Enter:g/string/dThe string should match about 150,000 lines i.e. you want to delete lots of rows! If you do not need to *cut* lines (any Vim delete operation cuts by default) you need to use black hole register: delete _ in place of just delete (d is the short form of it). 5. Go for a coffee break (Windows!) or wait 30 seconds (OS X) In practice, if I issue the command on Windows, I kill the process then open the file again, this time setting clipboard= before I issue the command. The workaround (:set clipboard=) is fine if you remember it! It would be nice if gvim did this e.g. (pseudo-code): old_clipboard = clipboard try clipboard = execute global command finally clipboard = old_clipboard end One consideration for side effects: currently, if clipboard=unnamed, the only text that ends up on the system clipboard is the final deleted line, not all deleted lines. If anything, you might want all deleted text to be on the clipboard but that is not what currently happens. I suspect neither the last line nor all lines is generally required. I don't care (others might) what ends up on the clipboard and would be happy if there was no speed penalty when the command was issued! It would be great if someone could look at this! Thanks Praful -- -- 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. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTh8dWGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvm8TD/90z5dINDuy3tFr7RcSzd671AYa1yeBEEEfY4/dLtWebdl9nNPROFSk tJ0E9X+fyAb5zbBs+tdhtTj8Zk5wEMtcYqNDJvtkIQKEQy2o+iJKXgKNKqKF11gN YWQm0jpA5TlW7mLhSXR3AsqYXHHLKiWeRx/s+G2T8GW8GWX5/w3CbwOx88lSo7FQ K7zs+LoF8UQoXmxZjzT3XKSwve9KRhIQB9VqjvREtmBzOGS8ZW+8GNvApMqAcbdG y0HZ616R4gW8wl4yuDeWeNfIbAAYyOvzz6+hDrFtwNeNHnPf0os5+bBHNe/be6DP 8oml7sRr80pAsfLjbYx2nsImKNTX/+BBCmd2s+VQzjgJJFZzQ2Z6tcDhb4WKtFCU 0KLbmCHDE0fVkRr14gzPsNSPgA+bHLiYFMxwoZUjs5E2gv96VY1hYTlhDxCq4nx1 s5FWHUIAGwrjUDE5cY68jbxhmm6pNRrMzO0m2kQlwWjy02KgtC2+gNFNxqEq7U1a LtcVIp7tuOFud0SUvA4yVhcMdsxUdF8LYe9MCzLmrWAjE6vT16OeFJCO+Q44f8LX rJdtaDOnj5rEK+fEpQDDOQXCkGm4uli0egJ/gcd9EpwlrLoTnPDDGTGRAn3G4Bun i3sJDX6bVSXSYo+XISaa0n5HvsxltzF4f8QbOVeRhIDHVtAbuJSzEA== =t81i -END PGP SIGNATURE- -- -- 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: match_add() and match_delete() hack for matchparen speed improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On May 28, 2014 3:11:51 PM GMT+03:00, Alexey Radkov alexey.rad...@gmail.com wrote: If a new function is involved then :3match would have explicitly different behaviour than other :match commands whereas currently it is not prohibited to use :3match for purposes besides matchparen (though it is not recommended in docs). It means that backward compatibility will be broken. :3match is an alias to *VimL* matchadd() function. Bram was suggesting to add *VimL* matchaddpos() function. NOT change :3match behavior, but introduce a new VimL function that is better suited for the purposes of matchparen. This patch tries to guess if :3match was called by matchparen and do not break expected behaviour when :3match was called for other purposes. But i agree that regexp heuristics looks ugly and is not so fast. Probably using a new dedicated command instead :3match will be the best solution: the new command would be implemented by the matchaddpos() function. 2014-05-28 14:19 GMT+04:00 Bram Moolenaar b...@moolenaar.net: Alexey Radkov wrote: Hi all. My home computer is Linux 3.14.4-200.fc20.x86_64 x86_64 x86_64 x86_64 GNU/Linux running on AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ Relatively old. And matchparen (I use matchparen++ but they do not differ a lot) may perform extremely slow in some cases. I found that most slow call in the plugin is 3match and tried to increase its performance in the attached patch. The idea of the patch: Functions match_add() and match_delete() redraw whole screen passing flag SOME_VALID to redraw_later(). However matchparen does not require that all screen must be redrawn: the positions of matching pairs are well known and they are passed in the pattern regexp like \(\%24l\%31c\)\|\(\%28l\%36c\), so they can be easily retrieved in the match_add()/_delete(). Another fact that hints that we are dealing with matchparen is id 3 (:3match is mostly solely used for matchparen as the vim doc says). Now we can calculate boundaries for redrawing area, set wp-w_buffer-b_mod_set and corresponding top and bottom lines numbers and finally pass VALID to redraw_later() and it should redraw only between the top and the bottom lines. The patch works best for specific cases: when matching pairs are located on the same line or close lines and terminal area is big enough (this shows best difference due to small redraw area to the whole terminal area large relation value). I am not sure if this patch is clean (especially when using wp-w_buffer-b_mod... variables). I also attached video that shows how vim compiled with this patch (vim.fast) faster than original vim (vim.slow) (there are two sessions on the video: the first is slow, the second is fast(er)). In my opinion this is too tricky. It depends on the matchparen plugin to set exactly the pattern that the code will recognize. Instead of this, it would be much better to add a kind of match that doesn't work with a pattern but with the line number and column. Perhaps also the number of characters. That's much simpler and also more efficient. Could be done by adding a matchaddpos() function, similar to matchadd() but using a position instead of a pattern. Whether the match position is adjusted for inserted and deleted lines remains to be decided. Probably needs to be an option. -- hundred-and-one symptoms of being an internet addict: 215. Your mouse-clicking forearm rivals Popeye's. /// 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. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQI1BAEBCgAfBQJTheZrGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj HhHSvtL4EACDLvhpafQvMMM5BCZn5hoNgeeps3bAf0lK4TxGOhq/dCl6OmSwapy4 DDuaYf14rZn1m/QGnqOLRP0cx3sHFYSGgdGFHtuDpBepRV3fVD5M72m/GStzwnfl A7OX9gi2P55UdarZQ8RQhfFbBTtzlKCoXpQFIZqpRjxgSBFKyBHJpDxL1cSIC6MN /kKBuaFtP4VADzTb1/FgMKeN6KUJ+QzWAPWZQDWBNX7gK64jQs9KVAbqN4EXBV03 +EDb1GNi5ohXmZ6cTFRqNt0EhzrK7SiwQjh1DqJXvDbyjSIUQlUAVy6qBU9EPZBL yDIVJuKSUhG6AWML2dDVjF4K2e4LhLnpyTW3kjwssR1yDOo9no6Zb5hz3znF2/Qe uDi0rqu53ooWLA7qO5DLZiyns+blDp/Hon140X74Fp4YRatqHXxYcEeWXY3CuKqg /mgL5AJJVw5rB2HH3u/+n7PCnop73XuY0DXi6bnSPpvDaAgqQDZKrMyaVCpnGTmc
