Gary Johnson wrote:
It appears that I may need to install the ncurses package and
reconfigure vim in order to get color.
That would be likely; ncurses is (AFAIK) *much* better than termcap.
--
Matthew
Obscurity: +5
On 2007-02-28, Frodak Baksik <[EMAIL PROTECTED]> wrote:
> On 2/27/07, Gary Johnson wrote:
> > On 2007-02-15, Frodak Baksik wrote:
> >
> > > Here are all the changes in a single patch.
> > > I'm also posting this to the cygwin-apps mailing list, so if anyone
> > > over there could try it out would b
On 2/28/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Nikolai Weibull wrote:
[Add a skip directive to the :syn command to allow arbitrary skipping.]
Sounds like a good idea. I'll add it to the todo list.
Great!
If you really want this added you would have to send a patch...
Yeah :-(.
Nikolai Weibull wrote:
> I'm a firm believer in the nextgroup directive for defining syntaxes.
> It allows you to define grammars, which I really enjoy doing.
> However, one problem is that many languages allow things to appear in
> their input that's not part of the language's grammar. For exam
Yakov Lerner wrote:
> Maybe vim would better set &eol/&noel after ':r !cmd' also,
> no only after reading the file into buffer ? (that is, the condition
> whether input had final \n or not).
> As I can see currently, this piece of info is lost after ': !cmd' ?
It completely depends on what you a
Michael Schaap wrote:
> When editing a read-only file, ":confirm w" only works the first time
> you use it in a session. The second time you try to use it, you simply
> get an error message, as if you didn't use ":confirm".
> The same problem occurs when using ":set confirm".
>
> To recreate:
Yakov Lerner wrote:
Hello Bram,
Maybe vim would better set &eol/&noel after ':r !cmd' also,
no only after reading the file into buffer ? (that is, the condition
whether input had final \n or not).
As I can see currently, this piece of info is lost after ': !cmd' ?
Yakov
Maybe after :$r !cmd
On Sunday, February 11 at 09:34 PM, quoth Nicolas Weber:
Hi,
vim-mac stripped the attachment again. I hope it comes through on
this list.
I like it! But it has a weird problem for me... if the focus is on
some other application (say, Mail.app), and I click on the vim
window's tab list edge
Hello Bram,
Maybe vim would better set &eol/&noel after ':r !cmd' also,
no only after reading the file into buffer ? (that is, the condition
whether input had final \n or not).
As I can see currently, this piece of info is lost after ': !cmd' ?
Yakov
On 2/27/07, Gary Johnson wrote:
On 2007-02-15, Frodak Baksik wrote:
> Here are all the changes in a single patch.
> I'm also posting this to the cygwin-apps mailing list, so if anyone
> over there could try it out would be nice.
I just applied this patch to the latest Cygwin vim source package,
I just applied this patch to the latest Cygwin vim source package,
vim-7.0.122-1, and configured it with
Using the latest official vim sources (via CVS) I was able to apply
the patch and execute configure && make && make install with no
issues. Do you know if the patch applied successfully?
Ch
On 2/28/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:
Yakov Lerner wrote:
> On 2/27/07, Michael Schaap <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> When editing a read-only file, ":confirm w" only works the first time
>> you use it in a session. The second time you try to use it, you simply
>> get an
Yakov Lerner wrote:
On 2/27/07, Michael Schaap <[EMAIL PROTECTED]> wrote:
Hi,
When editing a read-only file, ":confirm w" only works the first time
you use it in a session. The second time you try to use it, you simply
get an error message, as if you didn't use ":confirm".
The same problem occu
On 2/27/07, Michael Schaap <[EMAIL PROTECTED]> wrote:
Hi,
When editing a read-only file, ":confirm w" only works the first time
you use it in a session. The second time you try to use it, you simply
get an error message, as if you didn't use ":confirm".
The same problem occurs when using ":set c
On 2/27/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
Anyway, what I'm actually suggesting is a way to get around this issue
by adding a new directive to the :syntax command that can be used
alongside nextgroup to skip certain syntax groups before trying the
groups defined by nextgroup. This i
15 matches
Mail list logo
