Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

> > That is a reasonable request. If the "start" packages were not loaded > then :packadd can also look there. > When I saw these replies I thought, "well now I have some vacation days, this is a good time to try to go and implement this". But I see Bram already added it himself, so Thank

Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

Alejandro Hernandez wrote: > Testing plugins in isolation is frequently done. Under the current > system, all > plugins one wants to test have to be moved under `opt` to be able to > use `:packadd`. Relying on `:runtime` is both error-prone and > cumbersome. There's no need for the user to

Corrupt display when editing remotely via ssh

Hi, I'm having problems with garbling of the displayed text when ssh'ing into a remote machine to edit a file. Here's a 'MWE' of the steps that produce the problem. 1. Open xterm on local_machine (Slackware 14.1), check environment: TERM is 'xterm' XTERM_VERSION is 'X.Org 7.6.0(297)

Re: Any way to make packadd load plugins in start when -u NONE or --noplugins are passed

Testing plugins in isolation is frequently done. Under the current system, all plugins one wants to test have to be moved under `opt` to be able to use `:packadd`. Relying on `:runtime` is both error-prone and cumbersome. There's no need for the user to replicate `:packadd` functionality using

Re: Ring bell when search wraps? (i.e. on "search hit BOTTOM, continuing at TOP")

On Saturday, December 16, 2017 at 4:16:54 PM UTC+11, Asheq Imran wrote: > I miss the message that says > "search hit BOTTOM, continuing at TOP" The solution is to adjust the highlight that applies to that message. That depends on what colorscheme you use, but if using a dark background,

Re: highlighting prefixed keywords

On Sun, Dec 17, 2017 at 9:14 PM, Tim Chase wrote: > On 2017-12-17 19:16, Jorge Almeida wrote: >> Just a detail: is it possible to enumerate the keywords in a >> separate declaration, to improve maintainability? (The actual list >> is more extense). I'm thinking of

Re: highlighting prefixed keywords

On 2017-12-17 19:16, Jorge Almeida wrote: > Just a detail: is it possible to enumerate the keywords in a > separate declaration, to improve maintainability? (The actual list > is more extense). I'm thinking of something similar to: > > syntax keyword Foo open close mount umount > > Even if it's

highlighting prefixed keywords

I need to apply custom highligthing in a setup that should be simple for people who understand highligthing: I have a bunch of keywords with a common prefix, the single character 'c'. The keywords are to be listed one by one, not obtained via some algorithm. Example: cmount cumount copen cclose

Re: highlighting prefixed keywords

On 2017-12-17 18:49, Jorge Almeida wrote: > I need to apply custom highligthing in a setup that should be simple > for people who understand highligthing: > > I have a bunch of keywords with a common prefix, the single > character 'c'. The keywords are to be listed one by one, not > obtained via

Re: highlighting prefixed keywords

On Sun, Dec 17, 2017 at 7:02 PM, Tim Chase wrote: > On 2017-12-17 18:49, Jorge Almeida wrote: >> I need to apply custom highligthing in a setup that should be simple >> for people who understand highligthing: >> >> I have a bunch of keywords with a common prefix, the