headers
Andrew Pimlott | 1 May 2003 04:39

Re: Output/Input is not to/from a terminal

On Wed, Apr 30, 2003 at 02:11:59PM +0100, Walter Briscoe wrote:
> :help todo contains
> 7   Allow using Vim in a pipe: "ls | vim -u xxx.vim - | yyy".  Only needs
>     implementing ":w" to stdout in the buffer that was read from stdin.

I had no idea this was a todo, and I didn't look at your
implementation, but I've done this.  I use a wrapper script to map
some file descriptors, and a vim script to write the stdin buffer
when it's unloaded.  It's a quick hack, but do you see any problem
with it is principle?

I made :bunload, not :w, write the buffer to stdout, since my
intuition is that you're only "happy" with the buffer when you close
it.  Plus, I :w habitually, and wouldn't want this to write to
stdout.  What would happen if you :w twice?

vif:

    #!/bin/sh

    OPTS=$(getopt -o xg -n vif --long xterm,gui -- "$ <at> ")
    eval set -- "$OPTS"

    VIM='vim --cmd "runtime filter.vim"'
    CMD="$VIM -"

    while true; do
        case $1 in
            -x|--xterm) CMD="xterm -e sh -c '$VIM - <&4' 4<&0"; shift ;;
            -g|--gui)   CMD="$VIM -g -"; shift ;;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vince Negri | 1 May 2003 09:31
Picon

[PATCH] 6.2b Multiple syntax views, conceal, cursorbind

> The latest release of the combined patch, against
6.2b sources (as obtained from CVS) is
> available here:
> 
> http://www.bulbous.freeserve.co.uk/conceal-ownsyntax-62b.diff.gz
> 
New in this version is an improvement to "cursorbind"
which makes it work better in diff mode. If you
cursorbind two diff windows, then as you move through
one file the cursor position in the other is updated
to the logically equivalent line, i.e. taking
insertions/deletions into account.

> The patch implements three things:
> (Anyone new to this topic should check the archives
> for my message "[screenshot] RE: Multiple syntax views
> on one file" of 2nd April.)
> 
> 1) 'cursorbind' option - with improvements
to cursorbind so that it works nicely in diff mode.

> 2) Latest "conceal" functionality, including some
> cosmetic fixes, new customisable-per-match placeholder
> characters, a new 'conceallevel' setting, and 
> enhancements to make adding conceal functionality to
> existing syntax files easier.
> 
> 3) The ":ownsyntax" command for having multiple
> syntax views on one file.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Neil Bird | 1 May 2003 12:03
Favicon

Re: <kPlus> in xterm

Around about 30/04/2003 16:03, Vince Negri typed ...
> :imap <kPlus> hello
> .. but the keypad + continued to produce merely a "+" in
> insert mode.

   [is this really vim-dev?]

   There are a no. of things that could be happening, and a greater no. 
of ways to fix 'em :-)

   Try <Ctrl-V><kPlus> in xterm at the prompt and see what you get. 
Also try it with num-lock set.

   I've heavily customised my XTerm defaults file to ensure I get 
different key-sequences for nearly every key with every modifier for 
this very purpose, so I've no idea what the defaults are!

   E.g., in your fav. xdefaults file  (pref. $XAPPLRESDIR/XTerm), the 
following[snipped from mine - makes the KP keys work 'normally' with 
num-lock on, and vim-mapping-friendly without].  I'm not certain <kPlus> 
will work - depends what escape sequence vim thinks that is.  You might 
be able to tweak the defs. below to match, or else just map 
<esc>whatever instead.  The mappings below are what I figured were the 
correct ones by examining xterm source (!) & VT manuals.

XTerm*VT100.Translations: #override \
   <at> Num_Lock<Key>KP_Add:     string("+") \n\
   <at> Num_Lock<Key>KP_Subtract:string("-") \n\
   <at> Num_Lock<Key>KP_Decimal: string(".") \n\
   <at> Num_Lock<Key>KP_Divide:  string("/") \n\
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wichert Akkerman | 1 May 2003 13:19
Gravatar

Re: Vim version 6.2b ALPHA available

Previously David Brown wrote:
> I think CVS is primarily for the developers.  Generally, the latest and
> greatest will come from the CVS tree.

Even as a developer I would find a 6.1 branch very useful.

> If a previous release comes out, it could become a branch off of
> whatever 6.1.474 versions each file is.  CVS does branches very poorly,
> and I would like to do them as little as possible.

Imho you should branch 6.1 once the main trunk becomes 6.2, branch off
6.2 one the main trunk becomes 6.3, etc.

Wichert.

--

-- 
Wichert Akkerman <wichert <at> wiggy.net>      It is simple to make things.
http://www.wiggy.net/                     It is hard to make things simple.
Permalink | Reply | 7 comments |
headers
Dorai Sitaram | 1 May 2003 14:08

bug in explicit :setf behavior?

I would have thought that an explicit user ex command
of

:setf newfiletype

where the buffer already has a filetype=oldfiletype
would load the filetype plugins for the newfiletype,
but it doesn't seem to do so.  All it does is set the
&filetype variable to newfiletype, with none of
the accompanying settings peculiar to newfiletype.

Rationale?
Permalink | Reply | 5 comments |
headers
Bram Moolenaar | 1 May 2003 14:18
Picon

Re: bug in explicit :setf behavior?


Dorai wrote:

> I would have thought that an explicit user ex command
> of
> 
> :setf newfiletype
> 
> where the buffer already has a filetype=oldfiletype
> would load the filetype plugins for the newfiletype,
> but it doesn't seem to do so.  All it does is set the
> &filetype variable to newfiletype, with none of
> the accompanying settings peculiar to newfiletype.
> 
> Rationale?

You must be doing something wrong.  Try typing ":setf c" in a help file,
the highlighting does change.

Note that it doesn't work inside autocommands, since the side effect of
setting the 'filetype' option is disabled then (unless you explicitly
enabled nesting autocommands).

--

-- 
hundred-and-one symptoms of being an internet addict:
126. You brag to all of your friends about your date Saturday night...but
     you don't tell them it was only in a chat room.

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
(Continue reading)

Permalink | Reply | 4 comments |
headers
Benji Fisher | 1 May 2003 14:22

Re: New (?) sort implementation for Vim, beats quick sort [long]

Piet Delport wrote:
> 
> A few days ago, while trying to speed up the various quick sort
> implementation available for Vim, i unexpectedly found another algorithm
> that completely blows quick sort away on all fronts.  I thought this was
> cool enough to warrant posting here.
[snip]
> Each sort was run over a copy of the file three times, and the run time
> recorded.  The results are listed as <total runtime>: <individual runs>
> (both in seconds), with a nice graph at the end (everyone loves graphs):
> 
> QSortGenUtils   522: 174 174 174 *************************************
> QSortWebb       378: 126 126 126 ***************************
> QSort           372: 124 124 124 **************************
> QSort2          267:  89  89  89 *******************
> BISort          108:  36  36  36 *******
> BISort2          70:  24  23  23 *****

      Yes, the graphs help.

      I have not tested it myself, but if this works as well as you claim, I 
think this should be added to the distro ov vim 6.2 as (part of) a new default 
plugin.

      We have discussed this before:  how to make utility functions available to 
all plugins.  IIRC, the discussion got bogged down in questions about whether to 
use autoloading, lots of functions in one file or in many files, etc., and we 
still do not have them available.  It might be better if people used external 
scripting languages (perl, python, etc.) instead, but I have not seen much of 
this.  For portability, I think we need some basic utilities in vim script, and
(Continue reading)

Permalink | Reply | 7 comments |
headers
Mike Williams | 1 May 2003 14:34
Favicon

syntax region question

Hi,

Here is a little puzzler for a wet Thursday afternoon 
(well at least for this longitude and lattitude).

The following is a little sample file for highlighting 
a region of a file.  The region has different start and 
end patterns which can be spread over a number of lines.  
The aim is to have the start and end patterns highlighted 
differently to the rest of the region.  The obvious 
solution was to use matchgroup but this did not work for 
me (VIM62b).  My solution is keepend with contains= with 
a pattern for the start and end pattern.  Is this the 
right solution?  Shouldn't they be functionally equivalent?

Copy the following to a file and then source it.  Ignore 
the warnings, they are not important.  Comment out the first
region line and uncomment the second and re-source the file.
You should see the last line of "plain text" in bold and
the end pattern for the "5 lines" in plain text.

--------------------------8<--------------------------
syn match egDelim contained "A\(C\s*\n\)*B"
syn match egDelim contained "B\(C\s*\n\)*A"
" Following line does what I want
syn region egExample keepend start="A\(C\s*\n\)*B" 
end="B\(C\s*\n\)*A" contains=egDelim
" Following line does not do what I expect
"syn region egExample matchgroup=egDelim start="A\(C\s*\n\)*B" 
end="B\(C\s*\n\)*A"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dorai Sitaram | 1 May 2003 15:19

Re: bug in explicit :setf behavior?

Bram:
> 
> Dorai wrote:
> 
> > I would have thought that an explicit user ex command
> > of
> > 
> > :setf newfiletype
> > 
> > where the buffer already has a filetype=oldfiletype
> > would load the filetype plugins for the newfiletype,
> > but it doesn't seem to do so.  All it does is set the
> > &filetype variable to newfiletype, with none of
> > the accompanying settings peculiar to newfiletype.
> 
> You must be doing something wrong.  Try typing ":setf c" in a help file,
> the highlighting does change.

Very strange.  That works.  My test case is editing an
email message, where the filetype is initially 'mail'.
I do 'setf scheme', which, among other things should 'setl
lisp', and that doesn't happen.  On the other hand,
'setf scheme' in a help file does work.

I tried doing 'setf c' while editing an email, and I
found that while 'cindent' is indeed set, the
'formatoptions' is not changed.

So far, I can only find this behavior on buffers whose
initial filetype=mail.  (Of course, I try to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Vince Negri | 1 May 2003 15:31
Picon

RE: bug in explicit :setf behavior?

> I tried doing 'setf c' while editing an email, and I
> found that while 'cindent' is indeed set, the
> 'formatoptions' is not changed.

Is it something to do with the common code
in the plugin files?

" Only do this when not done yet for this buffer
if exists("b:did_ftplugin")
  finish
endif

" Don't load another plugin for this buffer
let b:did_ftplugin = 1

You should do an ":unlet b:did_ftplugin" before
your :setf call.

Vince

Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this 
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such 
privilege. Please advise the sender if you receive this e-mail by mistake.
Permalink | Reply | 0 comments |

Gmane