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
From Evan Gates to ~sircmpwn/sr.ht-dev
--- When going through git-send-email.io to teach a coworker, the biggest missing piece was any mention of format-patch. I find that format-patch and then send-email is a much smoother workflow when annotating or sending multiple patches. I don't want to make the decision one way or another for someone new to send-email, but I do think that they should be made aware of format-patch. I'm not subscribed to the list, please cc me in any replies. index.html | 12 ++++++++++++ 1 file changed, 12 insertions(+) [message trimmed]