On Sunday, April 18, 2021 at 8:06:39 PM UTC-5 Gary Johnson wrote:
> On 2021-04-18, Felipe Contreras wrote:
> > Thanks for understanding.
> >
> > No, I don't understand.
> >
> > Any software developer doing things exactly the same as 10 years ago is
> a bad
> > software developer, let
吕海涛 : When looking for information about Vim, the place to look is
always the built-in help. Not Google, not the manpages, not the github
metadata, just the help. In this case: :help credits
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type
On 2021-04-18, Felipe Contreras wrote:
> Thanks for understanding.
>
> No, I don't understand.
>
> Any software developer doing things exactly the same as 10 years ago is a bad
> software developer, let alone 30 years ago.
That's just plain not true. A idea that was good 10 or even 30
On Mo, 16 Mär 2020, Ken Takata wrote:
> Parallel builds may not work for the Free plan.
>
> https://www.appveyor.com/docs/parallel-testing/#requirements
> > but jobs will run in series as the Free plan allows 1 concurrent job per
> account.
>
> One possible option is utilizing GitHub Actions.
Hi Christian,
2020/3/16 Mon 17:08:13 UTC+9 Christian Brabandt wrote:
>
>
> On Sa, 14 Mär 2020, Dominique Pellé wrote:
>
> > Yegappan Lakshmanan > wrote:
> >
> > > Hi,
> > >
> > > When a PR is updated multiple times quickly, mul
On Sa, 14 Mär 2020, Dominique Pellé wrote:
> Yegappan Lakshmanan wrote:
>
> > Hi,
> >
> > When a PR is updated multiple times quickly, multiple build requests
> > are submitted to Travis-CI and Appveyor. In Travis-CI only the last
> > build request is proce
Yegappan Lakshmanan wrote:
> Hi,
>
> When a PR is updated multiple times quickly, multiple build requests
> are submitted to Travis-CI and Appveyor. In Travis-CI only the last
> build request is processed and all the older pending build requests are
> canceled. But in Appv
Hi,
When a PR is updated multiple times quickly, multiple build requests
are submitted to Travis-CI and Appveyor. In Travis-CI only the last
build request is processed and all the older pending build requests are
canceled. But in Appveyor all the build requests are processed
in sequence
Thank you, Bram and Pontus, for tracking this one down!
On Fri, 28 Jun 2019 at 22:05, Pontus Leitzler wrote:
>
> Yeah, I don't really understand what triggers it. I've tried to create a
> small reproducible but I can't seen to make it trigger this. Could be a
> timing issue.
>
> One thing I
Yeah, I don't really understand what triggers it. I've tried to create a small
reproducible but I can't seen to make it trigger this. Could be a timing issue.
One thing I thought about is the 10ms delay that is added if there is more to
read from the channel(?). That might introduce some
> > Please try if this patch fixes your problem:
> >
> > --- prev/src/channel.c 2019-06-24 00:43:31.463691826 +0200
> > +++ channel.c 2019-06-28 04:41:25.767304149 +0200
> > @@ -2850,10 +2850,13 @@
> >
> > if (ch_mode == MODE_JSON || ch_mode == MODE_JS)
> > {
> > -
> Please try if this patch fixes your problem:
>
> --- prev/src/channel.c2019-06-24 00:43:31.463691826 +0200
> +++ channel.c 2019-06-28 04:41:25.767304149 +0200
> @@ -2850,10 +2850,13 @@
>
> if (ch_mode == MODE_JSON || ch_mode == MODE_JS)
> {
> - jsonq_T *head =
Pontus Leitzler wrote:
> Just to summarize:
> - channel_read() reads 63 bytes and calls channel_save()
> - channel_save() saves those to a new node->rq_buffer at the end of channel=
> head
>
> To convert it to JSON someone must call channel_parse_json(), and it can be=
> either from
Just to summarize:
- channel_read() reads 63 bytes and calls channel_save()
- channel_save() saves those to a new node->rq_buffer at the end of channel head
To convert it to JSON someone must call channel_parse_json(), and it can be
either from channel_read_json_block() or may_invoke_callback().
> That doesn't look right, because there should not be a complete json message.
> If there is, perhaps a call to parse it is missing?
> Perhaps a call to channel_parse_json() is needed.
Yes, maybe there is a channel_parse_json() missing somewhere. But as the flow
log shows it's also a
> This is a patch that actually fixes the problem, but I have no idea what
> other side effects it might have. Also note that the line numbers are way off
> since I've been adding stuff.
>
> @@ -2853,7 +2853,7 @@ channel_has_readahead(channel_T *channel, ch_part_T
> part)
> jsonq_T
> In both cases it's called from the end of WaitForCharOrMouse.
> I'm not entirely sure I get all line numbers right, even when I compile vim
> with -g -O0, so I had to go with the "Fprintf to stderr"-monkey style :).
>
> One further step in the stack trace:
> ui_wait_for_chars_or_timer(...),
https://github.com/MarcWeber/vim-addon-signs
all you do is pass a list, incremental updates get applied.
However if you have > 5,000 signs or so it might make sense to limit to
first X items ..
Eventually could still be done faster eg using Python whatever.
Marc Weber
--
--
You received
This is a patch that actually fixes the problem, but I have no idea what other
side effects it might have. Also note that the line numbers are way off since
I've been adding stuff.
@@ -2853,7 +2853,7 @@ channel_has_readahead(channel_T *channel, ch_part_T part)
jsonq_T *head =
In both cases it's called from the end of WaitForCharOrMouse.
I'm not entirely sure I get all line numbers right, even when I compile vim
with -g -O0, so I had to go with the "Fprintf to stderr"-monkey style :).
One further step in the stack trace:
ui_wait_for_chars_or_timer(...), the line "if
Pontus Leitzler wrote:
> I wrote the previous post yesterday but since it was my first it had
> to be moderated before showing up.
>
> Since then I did some more investigation and it turns out that the channel is
> indeed read in channel_read(...), but then the blocking select() prevents the
I wrote the previous post yesterday but since it was my first it had to be
moderated before showing up.
Since then I did some more investigation and it turns out that the channel is
indeed read in channel_read(...), but then the blocking select() prevents the
incoming message to be processed.
Hi everyone,
I've been trying to create a smaller reproducible that can demo what happens,
but it seems to be a complex combination that isn't trivial to slice down.
So I went for another option, debugging vim instead. Since the binary I have
can reproduce the behavior consistently I thought
Hi all,
In https://github.com/leitzler/govim (master branch) Pontus is adding
support to govim for signs that correspond to quickfix entries.
This is done by calling sign_place/sign_unplace as required to get the
signs for a window in the correct state.
If there are lots of errors in a file,
https://github.com/vim-scripts/taglist.vim
There are several pull requests (A version update is also present)
Who owns and maintains these scripts in the github ?
--
Thanks Regards,
R Ashwin Sathya
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
On 01-Jun-2013 18:34 +0200, ashwin sathya wrote:
https://github.com/vim-scripts/taglist.vim
There are several pull requests (A version update is also present)
Who owns and maintains these scripts in the github ?
The mirrors on http://vim-scripts.org/ are not necessarily monitored
Hi,
On Sat, Jun 1, 2013 at 9:34 AM, ashwin sathya ashwin.sat...@gmail.com wrote:
https://github.com/vim-scripts/taglist.vim
There are several pull requests (A version update is also present)
Who owns and maintains these scripts in the github ?
I released version 4.6 of the taglist plugin
On 01-Jun-2013 20:50 +0200, Yegappan Lakshmanan wrote:
I released version 4.6 of the taglist plugin few months ago. The Git hub
repository has the 4.5 version. I don't know who is the owner of the
Github vim-scripts repository.
I thinks it's more or less two guys; you can contact / open
sathya ashwin.sat...@gmail.com
wrote:
https://github.com/vim-scripts/taglist.vim
There are several pull requests (A version update is also present)
Who owns and maintains these scripts in the github ?
I released version 4.6 of the taglist plugin few months ago. The Git hub
repository
Excerpts from ashwin sathya's message of Sat Jun 01 22:56:38 +0200 2013:
vundle to manage the plugins.
Get started with vim-addon-manager and your problems are gone because
- it honors authors upstreams
- it fetches most recent plugins from vim.sf.net, not form a mirror.
I still want to see
Hi Bram!
On Mi, 01 Mai 2013, Bram Moolenaar wrote:
I think we can be rather strict. If a human is doing a lot of work, we
can ask him to try again in 4 hours. And send us a message that this
happened, so that we can tune the limit. Perhaps for specific cases.
I think it just happened:
Thanks for reporting - looks like he finally suceeded - and didn't read
the message ..
Hi xingchao,
(this mail also goes to vim_dev mailinglist)
If you cannot upload, you should see a message instead.
Due to attacks we've limited actions to 15 POST requests by IP.
Another global limit does
Marc Weber wrote:
I've introduced a total limit of 500 POST requests within 4h which is
slightly more than POST requests happen within 24h on an average day
(380 posts in 24h)
Thus if a bot uses multiple IPs, he should still fail soon
(unfortunately everybody else, too) - I think its more
times in 4 hours assume its a bot
and die.
A typical session:
- login (POST 1)
- update 5 scriptsr (POST 2-5)
Thus 7 post requests. If you forgett your password 5 times - then you're
still fine.
Yes, there might be false positives - eg many people behind
firewalls try to update their scripts
This still does not protect agains resource exhaustion (mysql users
exceeded - which appened). There are modules for apache to prevent
excessive site usage by bot like attacks. Maybe we should propose
sourcreforge to set them up?
Marc Weber
--
--
You received this message from the vim_dev
I've introduced a total limit of 500 POST requests within 4h which is
slightly more than POST requests happen within 24h on an average day
(380 posts in 24h)
Thus if a bot uses multiple IPs, he should still fail soon
(unfortunately everybody else, too) - I think its more importatnt to
protect
Charles Campbell wrote:
Hello,
Hello,
If I may ask, how did you find out about it? I suspect that there's a lot
of LaTeX users out there that would like to use the conceal feature but
don't know about it.
I found out by some random walk on vim related websites the address
Adrien Axioplase Piérard wrote:
Hello,
2011/6/14 Ben Fritzfritzophre...@gmail.com:
Am I correct in my understanding, that your file .vim/after/syntax/
tex.vim, has a line like:
let g:tex_conceal='agm'
?
If so, then your problem is in assuming the g:tex_conceal option
works like built-in
Adrien Axioplase Piérard wrote:
I would like to express some regrets regarding this extremely useful
feature, and thus plea for some enhancements, should anyone capable of
coding them read this.
Hello,
If I may ask, how did you find out about it? I suspect that there's a
lot of LaTeX
Hello,
2011/6/14 Ben Fritz fritzophre...@gmail.com:
Am I correct in my understanding, that your file .vim/after/syntax/
tex.vim, has a line like:
let g:tex_conceal='agm'
?
If so, then your problem is in assuming the g:tex_conceal option
works like built-in Vim options like 'wrap' or
2011/6/13 Christian Brabandt cbli...@256bit.org:
Hi Adrien!
Hello Christian,
On Mo, 13 Jun 2011, Adrien Axioplase Piérard wrote:
1/ It is very annoying that when one is moving in a concealed line,
motions consider the underlying text rather that what can be seen.
I started working on a
Hi Adrien!
On Mo, 13 Jun 2011, Adrien Axioplase Piérard wrote:
1/ It is very annoying that when one is moving in a concealed line,
motions consider the underlying text rather that what can be seen. For
example, suppose I have
$\lambda 42$
which will be rendered as
$λ 42$
and that my
On Jun 13, 12:25 am, Adrien Axioplase Piérard axioplase
+vim...@gmail.com wrote:
3/ A bug?
I open a tex file, and :echo g:tex_conceal
agm
as set in .vim/after/syntax/tex.vim, which is loaded, I think, last,
and sets cole to 2, and cocu to nc.
However, the dollars in LaTeX's math mode
Hello everyone,
I have been using the conceal feature extensively since I discovered
it a week ago or so.
I would like to express some regrets regarding this extremely useful
feature, and thus plea for some enhancements, should anyone capable of
coding them read this.
1/ It is very annoying that
On 05/06/10 21:04, ZyX wrote:
There are some things that my 2html from stable vim (7.2.303, USE=acl bash-
completion cscope nls perl python ruby vim-pager vim-with-x) does not support,
so I ended in writing my own format.vim script:
- 'list' and 'listchars' (lcs:tab, lcs:eol and lcs:trail)
There are some things that my 2html from stable vim (7.2.303, USE=acl bash-
completion cscope nls perl python ruby vim-pager vim-with-x) does not support,
so I ended in writing my own format.vim script:
- 'list' and 'listchars' (lcs:tab, lcs:eol and lcs:trail)
- Foreground colors for lines
46 matches
Mail list logo
