> When starting a shell with ":sh" or ":!cmd" then Vim will set the
> terminal to "cooked" mode, that is what normal commands expect.
> When running a terminal inside Vim this doesn't happen, since Vim still
> needs the raw keys, e.g. for mouse events. We can't really change that
> without breakin
ld that be possible?
I'm afraid my terminal knowledge here is close to zero.
If you could help point me in the right directions for the escape codes I
would need to try this then that would be great.
Best,
Paul
On Friday, 8 November 2019 19:35:37 UTC, Bram Moolenaar wrote:
>
&g
>
> > With my limited understanding of the Vim internals it feels like Vim
> > should be calling `listener_flush` before any autocommand events are
> > fired. Or does that not make sense?
>
> I don't see why there would be any relation between triggering an
> autocommand and the listener mechanism.
Thanks - per my response to the patch that fixes things.
--
--
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 s
Thanks - I can confirm this fixes things.
On Sat, 28 Mar 2020 at 17:07, Bram Moolenaar wrote:
>
>
> Patch 8.2.0466 (after 8.2.0452)
> Problem:Not parsing messages recursively breaks the govim plugin.
> Solution: When called recursively do handle messages but do not close
> chann
> I don't like "undefined behavior", because people will depend on it
> anyway. We could add new "BufIs" autocommands that disallow any kind of
> changes to the buffer list:
> BufIsCreated
> BufIsLoaded
> BufIsUnloaded
> BufIsWiped
>
> Do we also need events for a buffer being renamed?
>
Apologies
> It would be good to know why the recursion is needed.
The canonical example is an autocommand handler in a remote plugin
that performs some actions that trigger another autocommand that also
has a remote handler.
But we have many others.
> One thing we can
> do is to only disallow closing chan
This change has broken govim which relies on recursive calls working. I'll
submit an issue with further details tomorrow
On Thu, 26 Mar 2020, 15:05 Bram Moolenaar, wrote:
>
> Patch 8.2.0452
> Problem:channel_parse_messages() fails when called recursively.
> Solution: Return for a recursive
Thanks very much.
> > * if Vim9 script remains experimental, presumably I have to explicitly
> > enable it within a script it somehow/somewhere? Or is this the
> > vim9script reference above?
>
> The Vim9 script syntax is only used for functions defined with ":def"
> and for scripts that start wit
Hi Bram - interested to try things out.
A couple of stupid questions:
* if Vim9 script remains experimental, presumably I have to explicitly
enable it within a script it somehow/somewhere? Or is this the
vim9script reference above?
* you allude to this point above, but will the speed improvements
Sorry, as soon as I sent that I realised what was staring me in the face.
Apologies for the noise.
On Thursday, 23 January 2020 09:23:08 UTC, Paul Jolly wrote:
>
> Hi all,
>
> I might well be missing something... but:
>
> curl https://vim.org
>
> just hangs for m
Hi all,
I might well be missing something... but:
curl https://vim.org
just hangs for me.
But:
curl https://www.vim.org/vim-8.2-released.php
succeeds.
Is this expected?
Thanks,
Paul
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply be
Hi all,
In govim we get diagnostics about code that is being edited in Vim via
async notifications from gopls, the Go LSP server implementation. We
then place signs and add text properties as a function of those
diagnostics to highlight issues to the user.
Diagnostics have a versioned reference t
> > I think the simplest thing for now is to follow Bram's suggestion of
> > using user_data.
>
> Hmm, would there be any harm in triggering CompleteDone before resetting
> the complete info? I don't think so. Would anyone using the
> autocommand event depend on the completion already being clear
> > I had this same request before. complete_info() should give this info.
>
> Thank you, Prabir - this is exactly what I'm after.
Except that when completion has already finished, which is the
situation we're talking about here because we're handling
CompleteDone, then complete_info() returns a "
> I had this same request before. complete_info() should give this info.
Thank you, Prabir - this is exactly what I'm after.
--
--
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.v
Hi all,
We are using the CompleteDone event in govim
(https://github.com/govim/govim) in order to add import statements
when a user selects a completion candidate (this happens when
completion candidates result from unimported completions in gopls).
However our handler for CompleteDone needs to k
>
>
> > Although I'm unclear on the resolution - isn't a Vim fix required here?
>
> I had the same issue after upgrading to 19.10.
> The only solution I found so far is adding a flag to the compiler:
> -Wno-deprecated-declarations
>
Thanks Bram - would it make sense to do something on the
> This looks like https://github.com/vim/vim/issues/4987
Indeed (apologies, I totally forgot to search there too)
Although I'm unclear on the resolution - isn't a Vim fix required here?
Paul
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below t
Hi Bram,
I'm seeing lots of warnings compiling on stock Ubuntu 19.10:
/usr/include/gtk-2.0/gtk/gtktooltips.h:73:3: warning: ‘GTimeVal’ is
deprecated: Use 'GDateTime' instead [-Wdeprecated-declarations]
73 | GTimeVal last_popdown;
| ^~~~
In file included from /usr/include/glib-2.0
Apologies for the delay in replying.
> I wonder why those mappings don't work. Can you reproduce this with a
> simple script?
I haven't been able to reproduce this, no.
> Bash won't be able to handle the escape sequences that Ctrl keys produce
> when modifyOtherKeys is enabled.
Noted, thanks.
FWIW - I have a stock Ubuntu 19.10 installation and I'm seeing some issues here.
Specifically I'm seeing issues using the fzf plugin which has ,
and mapped.
The only setup that works for me is to disable this feature via:
let &t_TI = ""
let &t_TE = ""
It's highly possible I'm do
> > With the exception of:
> >
> > https://groups.google.com/forum/#!topic/vim_dev/3z7KlLbGpwk
>
> This cannot be reproduced. popup_getoptions() doesn't block on
> anything. Perhaps the problem is that the result is rather big, goes
> over a buffer limit and sending the reply blocks on that?
Sor
> > Would this be vim 8.2, vim 9 or vim X?
>
> Vim 8.2.
With the exception of:
https://groups.google.com/forum/#!topic/vim_dev/3z7KlLbGpwk
from a govim perspective we're very happy with the stability of the
features we're using.
Thank you again.
Paul
--
--
You received this message from th
Hi all,
I'm rather attracted by some of the features of the acme editor,
particularly those that warp the mouse in response to mouse clicks
(https://www.youtube.com/watch?v=dP1xVpMPn8M)
For example, right clicking on some text searches for the next
instance of the expanded word under the mouse an
Hi Bram,
> Thanks for helping to work through this.
Just a quick status update: our govim builds have been very solid
since these changes. Test failures we've seen have been gopls related,
so at least as far as we've been able to tell so far the SafeState*
changes are working well.
Thanks again,
> Weird. I just tried and it works fine for me. Is this with GTK?
Yes, it's with GTK.
> I do notice the log is filled with these SafeState lines, we should
> probably reduce that.
Yep, I agree (or perhaps put behind some sort of build flag in case we
need to re-enable?)
> > l:expr is:
> >
> >
> > Added some logging and bizarrely, op_pending is not being called when
> > I run this test with GVim (at least GVim hangs first).
> >
> > I'm nowhere near close enough to the code to work out what's going on
> > here so hopefully this gives you a clue :)
>
> You must be doing something wrong. f
> The "o" indicates operator-pending. To find out what happens, you could
> add an extra ch_log() call in op_pending() to see which of the
> conditions is causing this. Because of this the "S" would also appear,
> and then the SafeState and SafeStateAgain autocommands won't be
> triggered.
Added
Hi Bram,
> Thanks for checking. I'll write tests for state() and the autocommand
> events.
The only issue we're seeing is that things "lock up" with GVim.
Taking a simple example test, and running the same govim test in Vim
and then GVim:
* Vim reports that the state is 'c'
* GVim reports that
> It's better to avoid feedkeys(). ":normal" is a bit better (it saves
> and restores the typeahead buffer).
Noted, thank you. I've raised
https://github.com/govim/govim/issues/535 on the govim side to make
the switch.
> Please try with patch 8.1.2053
Just tested with 8.1.2056; all looks great,
> OK, so the feedkeys() causes the safe state to be reset. That is
> correct, since Vim is then busy with processing input, which isn't
> considered safe.
>
> The problem is that with the "xt" argument to feedkeys() the input is
> processed right away, and we don't return to the main loop. I gues
> OK, so the whole sequence is triggered by the balloon eval
> functionality. This happens in check_due_timer(). That's a fairly
> normal way a callback is invoked, in this case evaluating 'balloonexpr'.
Ok, thanks.
> You can see in line 409:
> 0.181045 : safe state reset
>
> That's why it st
> How does the mouse move trigger the sequence?
Sorry, I should have covered that before. This is a hover test, so I
use test_setmouse followed by:
feedkeys("\\", "xt")
It's then the balloonexpr function that triggers the ch_evalexpr in
point 1 above.
I've attached the channel log file - th
> I'm seeing some some instances of not getting callbacks via
> SafeStateAgain... but I'll have to investigate that later.
This was actually my mistake; state() returns 'c' when in a channel
callback handler. If that is the only state, then it is safe for me to
immediately schedule the work. But f
> > Any ideas what might be going on here?
>
> Sounds like you need a nested somewhere. Have a look at
> `:h autocmd-nested`
That was exactly it, thanks very much.
I'm seeing some some instances of not getting callbacks via
SafeStateAgain... but I'll have to investigate that later.
--
--
You r
This is great, thanks. I'm using state() and SafeStateAgain
(adding/removing the autocommand as required)
I've got a WIP PR with the changes up at https://github.com/govim/govim/pull/533
However one issue I'm seeing is that autocommands are not fired when
doing work in response to SafeStateAgain.
> > I'm not familiar with Vim's internals: please can you explain the
> > different loops you're referring to here?
>
> Most callbacks are invoked from parse_queued_messages(). This is used
> when waiting for a key and when sleeping. Only timer callbacks are
> called elsewhere (and differently wh
> > Firstly, is there still a plan for the safeState/state/whatever
> > function? Because without it, if a message arrives at a "safe" time we
> > need something unsafe to happen before it will be run?
>
> Yes, adding the state() function would be needed. It's a bit of work,
> not sure when I get
> > Does this sound OK?
>
> I decided to give it a go and did an implementation of SafeState.
> It triggers in Normal, Insert and Command-line mode when nothing is
> pending. And when a blocking channel call has been made, where the
> state was safe before blocking, so that when something is postp
Hi Bram,
Thanks for taking the time to put together the proposal.
> Add a safeState() function, which returns true when:
> - not halfway a mapping or stuffed command
> - no operator pending
> - not executing autocommand
> - no autocomplete active perhaps?
> - not blocked on waiting, e.g. ch_evale
>
> So roughly:
>
Thanks - I'll give this some thought later today and reply with any
questions/thoughts.
--
--
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
> It would only be triggered when Vim is not halfway a mapping, ":normal",
> feedkeys(), autocommand, etc.
Perfect.
> There will be no "leave", because the user then already typed something
> and I don't see what you can do. Perhaps what you want is a way to
> obtain the status, thus after trigg
Thanks, Bram.
> > Things can go wrong
>
> I think that is only true if the callback does something involving a
> blocking wait. Such as that ch_evalexpr(). So the problem is not
> invoking the listener callback itself, but what happens inside the
> callback. There are many callbacks these days
> > For example, we might happen to call from govim -> Vim while Vim is in the
> > middle of handling a listener_add callback that itself calls ch_evalexpr
> > which results in a call Vim ->govim.
>
> Can this actually happen? Is this considered a "safe" situation then?
Yes I think it can. See
> Using a timer won't help much, since you do not know when the state has
> changed. You can use autocommands, e.g.:
> if mode() =~ [iR]
> au InsertLeave * call DoTheWork()
> endif
>
> There is no generic autocommand event for changing mode, perhaps that is
> want you are
Hi all,
Within the channel-based plugin govim
(https://github.com/govim/govim), the bulk of functionality is
triggered by user actions in Vim.
However, certain events are triggered entirely independently of Vim,
for example a list of diagnostics arriving from an LSP server, the LSP
server asking
Thanks very much for this.
On Sun, 8 Sep 2019 at 14:28, Bram Moolenaar wrote:
>
>
> Patch 8.1.2008
> Problem:Error for invalid range when using listener and undo. (Paul Jolly)
> Solution: Do not change the cursor before the lines are restored.
> (closes #4908)
If anyone is planning on working on this, creating something via
asciinema would be a nice way of getting the visualisation for free.
The entire set of examples could be coded with timings, then "played"
with asciinema recording.
On Thu, 5 Sep 2019 at 15:58, Blay263 wrote:
>
> Are you still plann
> The popup window feature has been implemented. Only a few minor things
> remain.
Thanks again for all the work on this, Bram.
We're just about to fully switch to popups i.e. upgrade min version of
Vim required for govim with no fallback option to use balloons/other.
No problems seen so far, wo
Hi Bram,
> Use popup_findinfo() to find the popup info window.
> See ":help complete-popup" for the size and align options.
Ah, thanks very much. Actually the option I think we'll go for for now
is some variation of:
set completepopup=align:menu,border:off
Thanks,
Paul
--
--
You received t
Hi Bram,
> Thinking about this again, it's probably best to add popup_getinfo() and
> when the info popup is removed, to hide it instead of deleting it.
> That way the properties you set on it will be kept.
Sorry, I lost track of where we got to with this conversation.
Is there now a means by wh
>
> > One thing i would like is the ability to remove the borders. I’m not a
> > fan of the borders in general due to the extra screen space they use
> > (and this the extra code they cover). I can also live without the X in
> > the corner if the popup goes away with Ctrl-y which I think it does.
>
Hi all,
Looking for some advice on whether the following is possible/best approach.
With govim (and other LSP clients), when hovering over an identifier, the
amount of detail returned by the LSP server can be quite lengthy. Consider
hovering over a function/method name. One line of the returned h
Thanks very much for taking the time to investigate, debug and fix this.
On Wed, 17 Jul 2019 at 21:56, Bram Moolenaar wrote:
>
>
> Patch 8.1.1711
> Problem:Listener callback called at the wrong moment
> Solution: Invoke listeners before calling ml_delete_int(). (closes #4657)
> Files:
Fantastic, thank you.
On Sat, 13 Jul 2019 at 19:15, Bram Moolenaar wrote:
>
>
> Patch 8.1.1681
> Problem:Insert stray "{" when listener gets buffer line. (Paul Jolly)
> Solution: Flush the cached line after invoking listeners. (closes #4455)
> Files:
> > Reason that neither solution will work is that it requires moving
> > the cursor, and that's not at all desirable in this case.
>
> I would not generally rule out cursor moves; within a function, Vim
> doesn't update the screen, and you can save and restore the original
> view via:
>
> let
fset based equivalents of
bufsetline(), appendbufline() and deletebufline().
Paul
On Thu, 11 Jul 2019 at 09:32, Tony Mechelynck
wrote:
>
> On Thu, Jul 11, 2019 at 9:55 AM Paul Jolly wrote:
> >
> > Hi all,
> >
> > I've tried various permutations of search terms, but so
Hi all,
I've tried various permutations of search terms, but so far turned up a blank.
Is there a function/similar that will allow me to set buffer contents
between a start and end byte offset?
If there isn't, I have a "backup" in the form of a :substitute like:
%s/\%3l\%1c\_.*\%4l\%1c/hello\r/
Thanks for the various updates. A govim user just reported an issue
that I raised as https://github.com/vim/vim/issues/4637
--
--
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.v
> > Per your suggestion, I already have a custom popup_create call that is
> > positioning things as I expect.
>
> OK. And that's using the mechanism to close the popup when the mouse
> moves away?
Yes, that's correct.
I'm also using a command to trigger the exact same hover "balloon"
using the
> Sound like restoring the cursor position after drawing some text might
> be missing. Do you have a simple script to show the problem?
Repro at the end of this message. Couple of things to note:
* I've had to add redraws in order to reliably draw the popup (compare
popup_beval_example)
* 'help
or
via any movement, it's actually in its original place and so the
movement is as expected.
On Sun, 7 Jul 2019 at 22:23, Paul Jolly wrote:
>
> > > One small thing I noticed is that the popup window "balloon" is shown
> > > botleft (see problem_1.png, attached).
> > One small thing I noticed is that the popup window "balloon" is shown
> > botleft (see problem_1.png, attached). Is this intentional?
>
> Yep, the default is to show the balloon above the text and to the right.
> This can be changed with the "pos" argument.
>
> > I was expecting the "balloon" t
Hi Bram - this is outstanding, thank you.
One small thing I noticed is that the popup window "balloon" is shown
botleft (see problem_1.png, attached). Is this intentional?
I was expecting the "balloon" to appear below and to the right of the
mouse, and hence that popup create option to be topleft
> > Is this still feasible? Because I'd move to using it tomorrow if I could :)
>
> Yeah, it's been on my mind. But I want to do it properly: when the
> mouse moves over the popup, it should not be closed. That would allow
> for expanding tree nodes, for example, when inspecting the value of a
>
Hi Bram,
> Most of the popup window support has now been implemented. There are a
> few things to improve and add, but it should be good enough to use.
This is fantastic work, thanks. I have a queue of changes to govim
that I will be making over the next month to use this. Exciting times!
One f
> Yeah, the script I have picked up the wrong metadata for the commit.
> I think I fixed the tag now. I don't think I can fix the message
> without messing up the sequence of commits.
Thanks. Yeh, I think the tag is the only thing that really matters.
For anyone who has a stale version of the v8
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 tho
Hi Bram,
It looks like the Vim repo tags have gotten a bit mixed up with the
last couple of commits:
b60d8514b (HEAD, origin/master, origin/HEAD) patch 8.1.1608: the
evalfunc.c file is too big
f9c85f580 (tag: v8.1.1608) patch 8.1.1608: the evalfunc.c file is too big
548be7f12 (tag: v8.1.1606) pat
> Different plugins and user triggered commands can populate the
> quickfix/location lists. To handle plugin specific behavior, it is simpler
> to have the plugin call a user supplied function(s) or autocmd:
Thanks very much for the reply. This is the conclusion I had also reached.
Paul
--
--
This is excellent, thank you to everyone who contributed on this!
On Mon, 17 Jun 2019 at 20:48, Bram Moolenaar wrote:
>
>
> Patch 8.1.1564
> Problem:Sign column takes up space. (Adam Stankiewicz)
> Solution: Optionally put signs in the number column. (Yegappan Lakshmanan,
> clo
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, the
> Yes, that is the safe way. But Paul made a point for what he wanted,
> and it's a very small change.
Thanks, Bram. Just saw the commit too.
I very much appreciate the discussion and understand the reasons
behind the has()/exists() suggestions.
But as explained, my whole testing approach is ba
> People who use Go are crazy, never do what they do!
> (just kidding, of course).
I'm looking forward to the first commit to the Vim repo that is a .go file ;-)
> > How about returning a triple:
> >
> > [8, 1, 1512]?
>
> Why?
No particular reason, other than the fact I felt having a triple was
>
> Turning the number into a message is trivial, while using the string in
> an "if" statement is not.
>
Good point. I was indeed thinking too much from a Go perspective.
How about returning a triple:
[8, 1, 1512]?
--
--
You received this message from the "vim_dev" maillist.
Do not top-post!
> Hmm, it's possible if you ignore security fixes, these sometimes skip a
> longer range of patches.
>
> We could add v:longversion or v:versionlong, with:
>
> major version (one digit)
> minor version (two digits)
> patchlevel (four digits)
>
> Current version would be 8011
> What do you want to use the patchlevel for? If it's about checking for
> a certain feature, use this:
> if has("patch-7.4.248")
>
> ":help has-patch" for details.
Thanks, Bram and Andy.
In much the same vein as the config functions discussion, I want to
push data to govim rather than h
>> I'd like to propose a version() function (or variable I guess?) that
>> returns a string that is the semver version of Vim, i.e. v8.1.1518
>
> Sounds like you're looking for the v:version variable.
Thanks. I'd see that, but it does not include the patch information,
i.e. 801, unless I'm missing
cross) packages are
loaded _after_ the .vimrc.
A workaround for this is to do a packloadall at the end of the .vimrc,
followed by calls to the config functions.
Is there perhaps a cleaner solution?
Thanks in advance.
On Thu, 30 May 2019 at 18:06, Paul Jolly wrote:
>
> Hi all,
>
> As a foll
Hi all,
I'd like to propose a version() function (or variable I guess?) that
returns a string that is the semver version of Vim, i.e. v8.1.1518
Parsing this in a locale-aware manner from the output of :version is
brittle (particularly if we consider MacVim messes with that output
slightly)
A spe
> Well, then perhaps use a shell command?
>
> silent !echo read this message
For some reason, using this approach I don't actually see the message
(I just get a blank terminal) until I quit Vim, i.e. I don't see it at
the critical time immediately before the install is attempted.
I think
> This is what popup_notification() is for. It's not implemented yet
> though. By default it shows a message for three seconds. Maybe I'll
> implement a way to close it, so you can keep it up longer.
Thanks, Bram.
I need these messages to appear as the plugin/govim.vim file is being
sourced (b
Hi all,
I would like to kindly ask for some advice on how to do informational
logging in Vim.
When govim (https://github.com/myitcv/govim) starts up, it checks
whether it needs to "go install" a new version of the Go part of the
plugin, as well as gopls (the LSP server).
In order to keep the use
> Patch 8.1.1512 hopefully fixes the problem.
It absolutely does, thank you. For both the minimal repro and the
actual govim issue.
Best,
Paul
--
--
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 informatio
> The obvious typo, surely :setf markdown?
Possibly, but I'm looking for the _rendered_ form of a markdown file,
i.e. the file contents minus the markdown, with some Vim
interpretation of the markdown in the form of syntax highlighting.
i.e.
*test*
results in
test
but rendered in italics.
--
> Why not just use :self markdown. and a markdown syntax file?
Apologies, I'm probably missing something obvious here; but what is
the :self command?
--
--
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 inform
+10,000!
On Fri, 7 Jun 2019 at 13:25, Christian Brabandt wrote:
>
>
> On Do, 06 Jun 2019, Bram Moolenaar wrote:
>
> > Patch 8.1.1486
>
> Congratulations to 10,000 commits on github ;)
>
> Best,
> Christian
> --
> Und damit das nur gleich klar ist, wir können auch außerhalb einer
> Pressekonferenz
> What part of balloons? If you mean 'balloonexpr', it only returns plain
> text. Perhaps you mean the functionality to detect the mouse pointer is
> hovering over text for some time? Well, we could add 'balloonpopup',
> which would open a popup window with anything it likes and return the
> win
Hi all,
As a follow up to a thread I just started ("Using text properties to
show rendered documents" -
https://groups.google.com/forum/#!topic/vim_dev/Armm3XaIleo) I'd like
to ask whether folks would be supportive of using popup windows
instead of balloons (or at least having this as an option).
Hi all,
I'm somewhat/extremely behind on the text properties work, which looks
very exciting.
In the context of govim (https://github.com/myitcv/govim), I'm
considering using text properties as a way of showing a simple
rendering of markdown/HTML within a Vim window (popup to be precise).
Render
Hi all,
Despite the documentation being quite clear, I was a little surprised
that setqflist did not trigger QuickFixCmdPre|QuickFixCmdPost.
This is hardly surprising: setqflist is a function, not a command.
Not only that, if we ignore the fact it's not a command, the very
example given in Quick
Hi Christian,
> How about a wiki page on https://github.com/vim/vim/ ah that is not
> enabled at the moment. Perhaps that should be enabled?
That's a good idea, hadn't thought of that.
My initial thought had been something that I can run "live" within a
Vim instance... but that's certainly not m
Hi all,
With the popup support coming along nicely, might it be an idea to put
together some sort of showcase of the various popup options available?
Perhaps a help-like file which gives some commentary of the various
options, and demos for each option which are activated when the mouse
hovers/cl
Thanks for the detailed response.
> I don't really see the difference between configuring via global
> variable or by calling a function in your vimrc. Your plugin doesn't
> need to check vim's global variable every time you use a feature, just
> check it once during plugin initialization and set
Hi all,
As a follow up to a recent thread ("Plugins exposing events to other
plugins": https://groups.google.com/d/msg/vim_dev/uiw6gHft-0g/i8qdfT8YBQAJ)
I'd like to ask whether there is an existing pattern of configuration
functions that plugin developers follow?
Some background.
I'm not really
> I have likely not understood the OP's problem exactly, but wouldn’t
>
> doautocmd User MyEvent
>
> be one such way?
Thanks. Yes, as I understand it, it would.
My original enquiry was really to understand whether there was an
existing standard/preference amongst the various options.
Paul
Hi all,
Just a brief note to say a big thank you to Bram and everyone else who
has been contributing, particularly in the last couple of months.
In particular I'd like to highlight that Vim now has:
* full support for delta calculation as buffers change
* the very promising beginnings of popup w
Thanks for the thoughts, Bram.
> Not really. It's quite specific and it's hard to imagine what would be
> useful. It's one of those things where the one who is first running
> into it has to find a solution, and if it works well others will follow.
Yep, agreed. Just wanted to see if there was a
Hi all,
As a brief summary, govim (https://github.com/myitcv/govim) is a
Vim8.1 channel-based plugin, written in Go, that is a Language Server
Protocol (LSP) client
(https://github.com/Microsoft/language-server-protocol/blob/gh-pages/specification.md).
The TL;DR version is that such a plugin can,
1 - 100 din 118 matches
Mail list logo
