From Evan Gates to ~emg/dev
On Thu Oct 7, 2021 at 4:59 AM PDT, adigitoleo (Leon) wrote: > Hi, thanks for the nice plugin. I've only just discovered cscope so I > don't know much about it, but would it be difficult to add an inverse of > the :cs pop command? Something to go forward in the cscope "jump > history", without opening up the vis-menu again? > > Cheers, > Leon I recently hacked at pulling the position stack out of vis-cscope and into a separate plugin so I can have multiple plugins control it (specifically the ability to pull up git blame type information in a new, currently extremely hacky, vis-git plugin). The new plugin, vis-jumplist, does include the ability to move fowards and backwards
From Evan Gates to ~martanne/devel
Marks use 'am and 'aM to mirror register usage for yank/put and allow a default mark when one is not specified. For anyone coming from vim and used to ma and 'a usage, using a default mark when none is specified is a foreign concept. This leads to e.g. ''m and ''| when m and | would do. Explain in the man page that the default mark is used when none is specified for mark and selection set operations. [0]: ad10da5 (vis: cleanup marks implementation) --- man/vis.1 | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/man/vis.1 b/man/vis.1 [message trimmed]
From Evan Gates to ~martanne/devel
The commit that added vis:message[0] used the existing vis_message_show
function which is used internaly to display lua stack traces. That
function uses the internal error_file. vis_event_emit does not trigger
events for internal files in order to avoid extra lua errors when already
printing a lua stack trace[1]. Due to this setup any usage of vis:message
showed the text in a window with default theme/syntax/status bar colors.
Instead of using the internal vis_message_show function, create a new
window and file that are not marked internal in the same manner as
cmd_help so themes are applied.
[0]: d815268 (vis-lua: implement vis:message(msg))
[1]: d555c90 (vis: properly redraw status bar of windows displaying internal files)
---
[message trimmed]
From Evan Gates to ~martanne/devel
Update the README to point to irc.libera.chat after the great migration of 2021. --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index b35f559..8336ee2 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ [](https://scan.coverity.com/projects/3939) [](https://codecov.io/gh/martanne/vis) [](http://vis.readthedocs.io/en/master/?badge=master) [message trimmed]
From Evan Gates to ~sircmpwn/aerc
On Tue Oct 13, 2020 at 11:23 AM PDT, Reto wrote: > thanks for the patch. > However I won't merge this, if you don't want wrapping use a different > template. > > We shouldn't special case characters other than the quoting char. Understood. Since aerc claims "First-class support for working with git & email"[0] I find it odd that it mangles inline patches by default when replying. It also doesn't include a template that doesn't mangle the patches. Would you accept a quoted_reply_nowrap template? How do people using aerc normally handle this?
From Evan Gates to ~sircmpwn/aerc
The wrapText function used in the quoted_reply template squeezes whitespace due to the use of strings.Fields. As a result any code in the body would lose leading whitespace for indentation. There was already a check to not wrap quoted lines (lines begining with '>'). Add more characters and don't wrap if a line starts with '+', '-', ' ', '\t'. These characters provide an heuristic that the text is code or part of a patch. --- lib/templates/template.go | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/templates/template.go b/lib/templates/template.go index 4346111..31bf46f 100644 --- a/lib/templates/template.go [message trimmed]
From Evan Gates to ~martanne/devel
On Wed Oct 7, 2020 at 9:01 AM PDT, Matěj Cepl wrote: > I agree, but it is a bit complicated. The purpose of LSP client > is to translate events in the editor into LSP events and make the > language server do the right thing. Here we would have to devise > some mechanism how to collect those events from vis. Looks like a proof of concept with only explicit requests could work. I'm also intrigued by the idea of making a more general purpose interface for it akin to cscope -L.
From Evan Gates to ~martanne/devel
On Wed Oct 7, 2020 at 4:39 AM PDT, Matěj Cepl wrote: > any ideas about implementing > https://github.com/martanne/vis/issues/853 ( > https://github.com/kak-lsp/kak-lsp and > https://github.com/fhs/acme-lsp seem like a lovely idea)? That's cool. I hadn't heard of that before. I did enjoy learning to use lua and vis' plugin capabilities so I'll look into it, but definitely no promises. I do think that it doesn't belong inside vis as that feels like it works against vis' goal of a simple core.
From Evan Gates to ~martanne/devel
Announcing vis-cscope, a plugin to provide a cscope interface for the editor vis. It works similarly (but not identically) to vim's cscope support. It's new, there will be bugs, please report them and/or send patches to ~emg/dev@lists.sr.ht https://git.sr.ht/~emg/vis-cscope
From Evan Gates to ~emg/dev
Announcing vis-cscope, a plugin to provide a cscope interface for the editor vis. It works similarly (but not identically) to vim's cscope support. It's new, there will be bugs, please report them and/or send patches to ~emg/dev@lists.sr.ht https://git.sr.ht/~emg/vis-cscope