Re: {func} of sort()
Am 21.08.2014 um 03:50 schrieb mattn: About making list sorted by string of one of value. echo "3" < "3 0" This is TRUE, then: echo MapSort([{"foo":{"bar": "3"}}, {"foo":{"bar": "3 0"}}], 'v:val["foo"]["bar"]') We expecet it should be kept: [{"foo":{"bar": "3"}}, {"foo":{"bar": "3 0"}}] But results are: [{'foo': {'bar': '3 0'}}, {'foo': {'bar': '3'}}] We need to escape string to avoid to handle index as value. I don't think so. I don't want to need to provide this function in all plugins. Just want to get it in official sort function. The reason is: :echo sort(['3 0', '3 0 1']) ['3 0 1', '3 0'] I'd expect ['3 0', '3 0 1']. :echo '3 0' < '3 0 1' 1 Bug in sort() function? -- Andy -- -- 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: [Bulk] Re: [Bulk] Re: Add count to :close and :hide commands
Am 21.08.2014 um 07:49 schrieb Christian Brabandt: Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev: Some people expect :1,$bd or :%bd to delete all buffers. That only works by accident, because your current buffer has more lines than you have open buffers. Or saying it differently, this does not work in an empty buffer. So this expectation is not really valid. Best, Christian Er, what you cited implies that it doesn't work at the moment (as expected (by some people (for a long time))). The idea is to make it become valid ... Marcin Szamotulski wrote: There are probably a few other commands that could benefit with a similar approach. Got it? -- Andy -- -- 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: [Bulk] [Bulk] Add count to :close and :hide commands
On Do, 21 Aug 2014, 'Andy Wokula' via vim_dev wrote: > Am 21.08.2014 um 07:49 schrieb Christian Brabandt: > >Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev: > >>Some people expect :1,$bd or :%bd to delete all buffers. > > > >That only works by accident, because your current buffer has more > >lines than you have open buffers. > > > >Or saying it differently, this does not work in an empty buffer. > > > >So this expectation is not really valid. > > Er, what you cited implies that it doesn't work at the moment > (as expected (by some people (for a long time))). > > The idea is to make it become valid ... > > >Marcin Szamotulski wrote: > >>There are probably a few other commands that could benefit with a > >>similar approach. > > Got it? > Ah, I thought you wanted to keep the current behaviour, that currently %bd already does delete all buffers (but only, if your buffer has enough lines). Best, Christian -- Richtiges Auffassen einer Sache und Mißverstehen der gleichen Sache schließen einander nicht aus. -- Franz Kafka -- -- 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: docker syntax files
Lokesh Mandvekar wrote: > I was hoping syntax highlighting for docker could be included by default in > vim. The files can be found here: > https://github.com/docker/docker/tree/master/contrib/syntax/vim > > Would the BSD license cause any trouble in this matter? I prefer the author sending the file to me, so that it's explicit that it is OK to include in the distribution. I don't see a License statement in the file itself. I would have to include the LICENSE file somehow. -- A fine is a tax for doing wrong. A tax is a fine for doing well. /// 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: docker syntax files
(The following assumes I haven't missed something about the Vim development process during my extended absence from vim-{dev/use}.) On Thu, Aug 21, 2014 at 3:39 PM, Bram Moolenaar wrote: > > Lokesh Mandvekar wrote: > >> I was hoping syntax highlighting for docker could be included by default in >> vim. The files can be found here: >> https://github.com/docker/docker/tree/master/contrib/syntax/vim >> >> Would the BSD license cause any trouble in this matter? > > I prefer the author sending the file to me, so that it's explicit that > it is OK to include in the distribution. > > I don't see a License statement in the file itself. I would have to > include the LICENSE file somehow. > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ As with the Docker Zsh completion file that just got included in upstream Zsh, I'd prefer that this doesn't make it into Vim "proper". Including it in another project just makes changes harder to propagate. Instead of taking just a pull request against the Docker repo, a change goes through the idiosyncratic (and slower) Vim runtime files change process (which apparently still involves emailing files in the year 2014). I think the state of the Vim ecosystem would be much better if: 1. Vim shipped with (or at least advocated the use of) a reasonable plugin/addon/package manager - This would at least discourage the poor manageability of "Just untar this into ~/.vim" 2. Vim didn't distribute (m/)any language-/tool-specific addons - They contribute to the amount of maintenance work Bram has to do - They detract from the amount of work that can be done on core Vim - They can't be updated as easily as they can if developed independently - They're subject to Vim's licensing (... kind of?). (At a minimum, licensing has to be considered. In the separately-developed scenario, it's simply not a concern.) - They're weirdly tied to a single (point of failure) author. 3. Projects (like Docker) that have Vim files would set them up in a way usable by (a) Vim plugin manager(s). - "Via pathogen, the usual way..."¹ seems a bit glib/useless #'s 1 and 2 are obviously out-of-scope for this Docker-specific request. But #3 should be easily achievable, AFAICT: My preferred plugin manager, Vundle², for example, makes installing the Docker syntax files as simple³ as adding one of the following to `.vimrc` or equivalent: ``` " if installing from scratch: Plugin 'docker/docker', {'rtp': 'contrib/syntax/vim/'} " if you already have `docker/docker` checked out: Plugin 'file:///home/bhaskell/git/docker/contrib/syntax/vim' ``` -- Best, Ben ¹: https://github.com/docker/docker/tree/cb47ddd968747091fd1b3d408dd36c4c2086e69f/contrib/syntax/vim#installation ²: https://github.com/gmarik/Vundle.vim ³: "simple", and in this case, amazingly inefficient (since it clones the whole Docker repo). "simple" != "perfect". With Pathogen, on the other hand, you could download an archive of just that `contrib/syntax/vim/` directory. But that's an extra (manual!) step. -- -- 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.
minor issue with c.vim
The C syntax file doesn't appear to handle this properly (the {} braces are highlighted in red which isn't correct): #define ALIGNOF(_t) offsetof(struct { char c; _t _m; }, _m) I'm running very current vim (changeset: 6146:7af530381fec) with c.vim at this changeset: changeset: 5968:92751673cc37 user:Bram Moolenaar date:Thu Jun 12 21:46:14 2014 +0200 description: Update runtime files. -- Will Fiveash -- -- 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: {func} of sort()
> > We need to escape string to avoid to handle index as value. > I don't think so. > > I don't want to need to provide this function in all plugins. Just > > want to get it in official sort function. > The reason is: > :echo sort(['3 0', '3 0 1']) > ['3 0 1', '3 0'] > I'd expect ['3 0', '3 0 1']. > :echo '3 0' < '3 0 1' > 1 > Bug in sort() function? See :help sort() > The sort is stable, items which compare equal (as number or as > string) will keep their relative position. E.g., when sorting > on numbers, text strings will sort next to each other, in the > same order as they were originally. It need to do like below with MapSort() echo MapSort([{"foo":{"bar": "3"}}, {"foo":{"bar": "3 0"}}], '0 + v:val["foo"]["bar"]') If using my patch, it is possible easy to avoid this. :echo sort(["3 0", "3 0 1"], "a:lhs < a:rhs") And MapSort() can't look local variable in the expression. For example, this doesn't work. --- function! s:foo() let rank = {"queen": 12, "king": 13} return MapSort(["queen", "king"], 'rank[v:val]') endfunction echo s:foo() --- But: --- function! s:foo() let rank = {"queen": 12, "king": 13} return sort(["queen", "king"], 'rank[v:lhs] < rank[v:rhs]') endfunction echo s:foo() --- This should be worked. -- -- 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: {func} of sort()
On Friday, August 22, 2014 12:05:33 PM UTC+12, mattn wrote: > > Bug in sort() function? > > See :help sort() > > > The sort is stable, items which compare equal (as number or as... There is indeed a bug in sort(). The stability of the sort is not relevant. I haven't been following the thread too closely, but became interested on seeing Andy's report of :echo sort(['3 0', '3 0 1']) ['3 0 1', '3 0'] I tried :echo sort(['foo bar','foo']) ['foo bar', 'foo'] but :echo sort(['foobar','foo']) ['foo', 'foobar'] The space makes a difference, because it sorts less than a single quote. Try :echo sort(['foo','foo&bar','foo(bar']) ['foo&bar', 'foo', 'foo(bar'] Looking in eval.c, to compare list items tv2string is called to stringify each item. tv2string calls string_quote, which puts single quotes around each string (and doubles any single quotes in the string). This effectively adds a single quote to the end of each string, and if it's being compared to a string that has something comparing less than a quote, it sorts ahead. I don't know why string_quote is called; it clearly is not useful for this purpose, but may be needed for another. Regards, John Little -- -- 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: docker syntax files
On Thu, Aug 21, 2014 at 04:43:58PM -0400, Benjamin R. Haskell wrote: > As with the Docker Zsh completion file that just got included in > upstream Zsh, I'd prefer that this doesn't make it into Vim "proper". > Including it in another project just makes changes harder to From a distro package perspective, using zsh completion or vim syntax from contrib causes ownership issues (certainly on fedora and its downstreams, perhaps other distros too) as the dirs in which these files would be installed are owned by other packages. See: https://bugzilla.redhat.com/show_bug.cgi?id=1127570#c3 Including them in the main repo would solve that. If it's only Fedora's/RHEL's problem and if others don't want it included here, I'm cool with bugging the package maintainers to include this in their rpms. > propagate. Instead of taking just a pull request against the Docker > repo, a change goes through the idiosyncratic (and slower) Vim runtime > files change process (which apparently still involves emailing files > in the year 2014). The files that were upstreamed certainly won't be deleted from docker/contrib as per https://github.com/docker/docker/issues/7657 . I guess some people could take it upon themselves to periodically upstream changes from docker/contrib. > > I think the state of the Vim ecosystem would be much better if: > > 1. Vim shipped with (or at least advocated the use of) a reasonable > plugin/addon/package manager > - This would at least discourage the poor manageability of "Just > untar this into ~/.vim" > > 2. Vim didn't distribute (m/)any language-/tool-specific addons > - They contribute to the amount of maintenance work Bram has to do > - They detract from the amount of work that can be done on core Vim > - They can't be updated as easily as they can if developed independently > - They're subject to Vim's licensing (... kind of?). (At a > minimum, licensing has to be considered. In the separately-developed > scenario, it's simply not a concern.) > - They're weirdly tied to a single (point of failure) author. > > 3. Projects (like Docker) that have Vim files would set them up in a > way usable by (a) Vim plugin manager(s). > - "Via pathogen, the usual way..."¹ seems a bit glib/useless > > #'s 1 and 2 are obviously out-of-scope for this Docker-specific > request. But #3 should be easily achievable, AFAICT: > > My preferred plugin manager, Vundle², for example, makes installing > the Docker syntax files as simple³ as adding one of the following to > `.vimrc` or equivalent: > > ``` > " if installing from scratch: > Plugin 'docker/docker', {'rtp': 'contrib/syntax/vim/'} > > " if you already have `docker/docker` checked out: > Plugin 'file:///home/bhaskell/git/docker/contrib/syntax/vim' > ``` Haven't used plugin managers myself, and I'll be sure to try them out, but I think the aforementioned file/dir ownership issues would be applicable in this case too. Correct me if I'm wrong. > > -- > Best, > Ben > > ¹: > https://github.com/docker/docker/tree/cb47ddd968747091fd1b3d408dd36c4c2086e69f/contrib/syntax/vim#installation > ²: https://github.com/gmarik/Vundle.vim > ³: "simple", and in this case, amazingly inefficient (since it clones > the whole Docker repo). "simple" != "perfect". With Pathogen, on the > other hand, you could download an archive of just that > `contrib/syntax/vim/` directory. But that's an extra (manual!) step. Thanks, -- Lokesh pgpDfZyo8EJPG.pgp Description: PGP signature