Re: GSoC Regexp engine

[Nikolai Weibull]

On 5/31/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:


What would be even cooler would be to use regular relations, as that
would allow for far superior substitution possibilities to what
:substitute has to offer.


(Someone asked off-list what regular relations were.  If anyone else
is interested, here's what I responded with.)

Here are some papers on regular relations:

http://citeseer.comp.nus.edu.sg/karttunen95replace.html
http://citeseer.comp.nus.edu.sg/karttunen96regular.html

Also see

http://www.xrce.xerox.com/competencies/content-analysis/fst/home.en.html

nikolai

P.S.
Please don't top-post.
D.S.

Re: GSoC Regexp engine

[Nikolai Weibull]

On 5/31/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:


What I think could be more useful would be boolean logic for regexp.  My
LogiPat
plugin provides this capability, but undoubtedly it'd be better if
somehow it could be
incorporated.  The resulting patterns from LogiPat seem to me to be
somewhat opaque.


What would be even cooler would be to use regular relations, as that
would allow for far superior substitution possibilities to what
:substitute has to offer.

I've long considered writing a text editor around regular relations,
and was actually hoping to get a Ph.D. based on using regular
relations in interactive processes, but that sadly never happened.

 nikolai

Re: GSoC Regexp engine

[Nikolai Weibull]

On 5/31/07, Ian Young <[EMAIL PROTECTED]> wrote:


I'm Ian, one of the two students working on improving the regexp
engine in Vim for this year's Google Summer of Code.  I haven't had a
whole lot to contribute as of yet, but now that work is underway, I'll
probably pop up here asking lots of questions some days.

Right now we're working on getting things set up and building a
testing suite, but I thought I would spark some discussion on a design
decision that will be coming up after we finish this phase, which is
whether to implement the new model ourselves, or use an alternative
engine, like TRE: . I'm tempted to
implement one ourselves, as it's an intellectually stimulating
prospect, but that doesn't mean I won't listen to reason if TRE or
another option is far better. I don't know much about the internals of
TRE, but according to previous posts to this list, it utilizes three
engines: a slow one for handling backreferences (presumably similar to
Vim's current engine), a fast one for most cases (what we are looking
to implement), and one for their 'fuzzy matching' feature.

I have a couple questions to start things off. First: I couldn't see
much need for 'fuzzy matching' in Vim, but some of you are probably
much better acquainted with regexp use cases than I am.  Would this be
a useful feature to have available?



Second: We might have to do some
gymnastics to work with multibyte characters, as discussed here: <
http://tech.groups.yahoo.com/group/vimdev/message/46408>. I haven't
worked with multibyte characters before, so I'm not clear on the
subtleties.  Would this translation to wide characters before passing
to the engine cause much of a performance hit and/or be excessively
complicated to implement? On a side note, TRE's main page says it has
both wide character and multibyte character support. I couldn't find a
version history, so I'm not sure if this is a new feature that Nikolai
isn't aware of, or if we need something more.


It supports

* Byte matching, that is, raw bytes
* Wide characters, that is, whatever wchar_t is
* Multi-byte characters, thas is, whatever mbrtowc supports
* Streams that is, objects that feed TRE characters as it needs them

It would be pretty easy to set up a stream object that would feed TRE
characters.  It would only have to keep track of where it was in the
buffer and basically request more of the buffer as TRE needs it.

It should be noted that there are quite a few bugs in TRE that relate
to the interaction of quantifiers.  I have discussed this privately
with Ville, but neither of us has been able to resolve it.  It has
also been discussed here:

http://laurikari.net/pipermail/tre-general/2007-February/thread.html

where Chris Kuklewicz suggests a solution to the problem that seems to
work.  It is a somewhat costly solution, but it may be worth it in all
its simplicity.  Chris has written an implementation of TDFAs for
Haskell that is quite simple and manages to both outperform all other
regex libraries for Haskell and still pass all POSIX tests.  Here's
the announcement:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg11442.html

This will, sadly, be of no use to us, but it does show that TDFAs are
a possibility, and that the problems TRE has with quantifiers can be
resolved.

Anyway, fuzzy matching, it seems like this is a feature that never
really caught on.  Agrep has long enjoyed the status of being one of
the few commands that remain to be implemented for the GNU project
(can't seem to find the list right now, so I can't provide a link).
This does, however, seem to indicate that no one has cared enough
about it to implement and distribute it with GNU.  It can be a quite
interesting thing to have, but it's perhaps not useful enough to care
about at this stage.

Also, you won't have time to implement this yourself.  Seriously.  It
takes a lot of work to write an efficient and
as-compatible-as-possible implementation implementation and a summer
isn't nearly enough time to complete said work.  I think that what's
most important here is to set up a test suite and the code required to
interface with a library, such as TRE.  That way one can always hook
in another library when it gets written.

Finally, good to hear from you. I think we all look forward to being
able to enjoy the fruits of your hard labor ;-).

 nikolai

Re: GSoC Regexp engine

[Nikolai Weibull]

On 5/31/07, Brian Gupta <[EMAIL PROTECTED]> wrote:

I have also heard good things about the PCRE (Perl Compatible Regex
Library). You may want to consider it as an option.


PCRE is crap.

It is crap, because it uses the same, crappy, backtracking method that
Vim, and most other crappy regex (note: not regular expression)
libraries use, which is exactly the kind of crap that this GSoC
project is aiming to scrap.

 nikocrap

Re: A performance question (patch included)

[Nikolai Weibull]

On 5/25/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:


getfsize("eval.c")  -> 478347 (after the patch)



getfsize("eval.c",1000)  -> 479   (truncated upwards)


Why can't this be done in VimScript?

 nikolai

Re: Wish: col("^")

[Nikolai Weibull]

On 5/21/07, Andy Wokula <[EMAIL PROTECTED]> wrote:

Nikolai Weibull schrieb:
> On 5/21/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
> > ... get position of first non-blank character in the line.



> > If there is col("$"), there should also be col("^").
> > In some situations (e.g. :imap )
> >:normal ^
> > is not allowed.



> Then shouldn't there also be a col("0") for symmetry?



Of course!  For symmetry, also col("|") should be added.


;-)

 nikolai

Re: Wish: col("^")

[Nikolai Weibull]

On 5/21/07, Andy Wokula <[EMAIL PROTECTED]> wrote:

... get position of first non-blank character in the line.

If there is col("$"), there should also be col("^").
In some situations (e.g. :imap )
   :normal ^
is not allowed.


Then shouldn't there also be a col("0") for symmetry?

 nikolai

Re: paste clipboard as visual block mode

[Nikolai Weibull]

On 5/16/07, Ernie Rael <[EMAIL PROTECTED]> wrote:

For jvi, not vim, I want to implement a way to "p" the clipboard as
though it were yank'd in block mode. I couldn't see anyway in the vim
doc to do this so I'm guessing that this is not supported. This could be
used to paste a rectangular selection from windows. Also, until I figure
out how to get at the vim specific info in the clipboard, it provides a
workaround for jvi.

If its possible that this might be a feature that vim would want some
day, I'd like to implement it in a compatible way. My first thought was
to use "#p to put the clipboard as block mode, the # has a block mode
flavor to it, but that's taken.


I understand exactly nothing of what you're trying to do, but here's a
function to does what "p" with a block does:

function! PasteRegion()
 let [_, lnum, col, _] = getpos('.')
 let saved_lnum = lnum
 for line in split(getreg(), '\n', 1)
   if lnum == line('$')
 if append(lnum, "") == 1
   throw 'Cannot append line to buffer while pasting region'
 endif
   endif
   let current_line = getline(lnum)
   let len = strlen(current_line)
   if len < col
 let new_line = current_line . repeat(' ', col - len) . line
   else
 let new_line = strpart(current_line, 0, col) . line .
strpart(current_line, col)
   endif
   if setline(lnum, new_line) == 1
 throw 'Cannot update line ' . lnum
   endif
   let lnum += 1
 endfor
 call cursor(saved_lnum, col + 1)
endfunction

This doesn't depend on any internal state of Vim.

Bram: Now that we have exceptions, wouldn't it make sense for append()
to throw an exception when it can't allocate memory?  Also, what's
with the C-style error codes for append() and setline()?  It's very
unintuitive, especially when there's really no other error code than
failure (1).  Too late to change, though.

 nikolai

Re: problems with vim

[Nikolai Weibull]

On 5/15/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Nageshwar M wrote:
> Hello,
>
> I compiled the vim 7.1 source for unix and installed it in my fedora
> core 4 pc. When I pressed arrows its printing A,B,C,D's(in insert
> mode) , backspace is not working and when I pressed delete
> continuously the gvim is closing down. Someone please help me.
>
> The information that vim is showing for :version is
>
> Normal version with GTK2 GUI.  Features included (+) or not (-):
[...]

This is usually due to a termcap problem. In which case(s) do you see the
problem (among the following)?

- in GUI mode (e.g. Alt-F2 then gvim)

- in console mode in a terminal displaying through X (and which one: xterm?
konsole? gnome-terminal? other[and which one]?)

- in the "pure text" linux console (hit Ctrl-Alt-Fn with n in the range
[1..6], log in if necessary, then invoke vim)


:set esckeys

may also help.

nikolai

Re: vim 7.1?

[Nikolai Weibull]

On 4/27/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:
> On 4/27/07, Jonathan Smith <[EMAIL PROTECTED]> wrote:
>
>> A.J.Mechelynck wrote:
>
>> > - Insane? All is relative. We're only at 7.0.233 as of today. FYI, Vim
>> > 6.2 went to 532 patches, see http://ftp.vim.org/pub/vim/patches/
>
>> Release early, release often :)



> Isn't that what's being done?  We're at 7.0.233.  That means that
> there's been 233 releases since 7.0.  Of course, it all depends on how
> you define release.



These 233 "releases" are incremental and source-only. (Steve Hall's
precompiled installers for Windows are compiled "in an officially supported
way" from "official sources" yet they are still "unofficial".)


Yes, I know, but the point is that Bram doesn't keep the changes to
himself until he releases 7.1.


The latest full official release with binaries was 7.0.000. To avail yourself
(as I do) of any of these 233 patchlevels to date (for instance, on Linux),
you have to, either:


[...]

Or let your package system do it for you, as on Gentoo.  Thanks Gentoo!  :-)

 nikolai

Re: vim 7.1?

[Nikolai Weibull]

On 4/27/07, Jonathan Smith <[EMAIL PROTECTED]> wrote:


A.J.Mechelynck wrote:



> - Insane? All is relative. We're only at 7.0.233 as of today. FYI, Vim
> 6.2 went to 532 patches, see http://ftp.vim.org/pub/vim/patches/



Release early, release often :)


Isn't that what's being done?  We're at 7.0.233.  That means that
there's been 233 releases since 7.0.  Of course, it all depends on how
you define release.

 nikolai

Re: syntax highlighting addition

[Nikolai Weibull]

It's getting there.

On 4/26/07, Jonathan Smith <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:



 > A better way of doing this is to do (substitute \w with whatever
 > pattern your parser actually allows)
 >
 > syn match conaryUse
 > \ "Use\.\w\+"
 > \ nextgroup=conaryUseFlag


Oops.  That should be

syn keyword conaryUse
 \ nextgroup=conaryUseFlagSeparator
 \ Use


" Vim syntax file
" Language: Conary Recipe
" Maintainer:   rPath Inc <http://www.rpath.com>
" Updated:  2007-04-26
"


The empty comment is still there.  Just leave that line blank.  No
biggie, of course, just aesthetics.


runtime! syntax/python.vim


Just to make sure: Python is allowed anywhere in a conary recipe?


syn keyword conarySFunction mainDir addAction addSource addArchive addPatch


If you change the filetype name to conaryrecipe (note: no caps),
you'll also have to change the syntax-group names.


syn match   conaryMacro "%(\w*)[sd]" contained
syn match   conaryBadMacro  "%(\w*)[^sd]" contained " no final marker


OK, so you can have the following:

%()s

or should it be "%(\w\+)[sd]"


" strings
syn region pythonString matchgroup=Normal start=+[uU]\='+ end=+'+ 
skip=+\|\\'+ contains=pythonEscape,conaryMacro,conaryBadMacro
syn region pythonString matchgroup=Normal start=+[uU]\="+ end=+"+ 
skip=+\|\\"+ contains=pythonEscape,conaryMacro,conaryBadMacro
syn region pythonString matchgroup=Normal start=+[uU]\="""+ end=+"""+ 
contains=pythonEscape,conaryMacro,conaryBadMacro
syn region pythonString matchgroup=Normal start=+[uU]\='''+ end=+'''+ 
contains=pythonEscape,conaryMacro,conaryBadMacro
syn region pythonRawString  matchgroup=Normal start=+[uU]\=[rR]'+ end=+'+ 
skip=+\|\\'+ contains=conaryMacro,conaryBadMacro
syn region pythonRawString  matchgroup=Normal start=+[uU]\=[rR]"+ end=+"+ 
skip=+\|\\"+ contains=conaryMacro,conaryBadMacro
syn region pythonRawString  matchgroup=Normal start=+[uU]\=[rR]"""+ 
end=+"""+ contains=conaryMacro,conaryBadMacro
syn region pythonRawString  matchgroup=Normal start=+[uU]\=[rR]'''+ 
end=+'''+ contains=conaryMacro,conaryBadMacro


I wonder if naming them pythonX is very good.  Bram?


if version >= 508 || !exists("did_python_syn_inits")
  command -nargs=+ HiLink hi def link 

  " The default methods for highlighting.  Can be overridden later
  HiLink conaryMacroSpecial
  HiLink conaryBFunctionFunction
  HiLink conaryGFunctionFunction
  HiLink conarySFunctionOperator
  HiLink conaryPFunctionTypedef
  HiLink conaryFlagsPreCondit
  HiLink conaryArches   Special
  HiLink conarySubArchesSpecial
  HiLink conaryBad  Error
  HiLink conaryBadMacro Error
  HiLink conaryKeywords Special
  HiLink conaryUseFlag  Typedef

  delcommand HiLink
endif


Substitute that with

hi def link conaryrecipeMacro Macro
hi def link conaryrecipeFunction Function
hi def link conaryrecipeBFunction conaryrecipeFunction
hi def link conaryrecipeGFunction conaryrecipeFunction
:
:

(If conary recipe macros aren't much like macros in C, then perhaps
Special is better.  Also note the linking of a generic group to
function and then other groups linking to them so that a user can
change them all en masse, to something they like.)

That HiLink cruft is also Vim5 compatibility stuff.  And remove the if
statement.


let b:current_syntax = "recipe"


This should be

let b:current_syntax = "conaryrecipe"

 nikolai

Re: [PATCH] Determining whether a window used :lcd

[Nikolai Weibull]

On 4/26/07, Bob Hiestand <[EMAIL PROTECTED]> wrote:

On 4/26/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
> > > Either way, wouldn't it be more useful to alter getcwd() to take an
> > > optional argument stating whether we want the local or global cwd?
>
> > The problem is that my plugin needs to change the current working
> > directory, perform an action, and then restore the previous working
> > directory.  I need to know whether to use :lcd or :cd to do that.  If
> > I use :cd in a window that had previously used :lcd, then I clobbered
> > the :lcd usage and that window is now stuck to the global directory;
> > additionally, the global directory is changed to whatever the prior
> > value.  If I instead use :lcd always, and the window wasn't previously
> > using a local directory, it now is.
>
> let saved_cwd = getcwd('local')
> let cd_cmd = (saved_cwd != getcwd('global')) ? 'lcd' : 'cd'
> exec cd_cmd '…'
> ⋮
> exec cd_cmd saved_cwd
>
> (assuming getcwd('local') returns the local directory, if there is
> one, or whatever getcwd('global') would, if not.)

While, again, that functionality would suit my plugin's need, I can't
help but feel that that's a pretty inefficient way of checking
compared to:


As in, what, perhaps 8 ms instead of 6 ms?


let cd_cmd = haslocaldir() ? 'lcd' : 'cd'

In the larger picture, I don't know why you'd want to distinguish
between local and global directory normally, other than to determine
the correct ':l?cd' to use, so I don't think that specifying a
parameter to getcwd() to be very useful.


Say that you want to change the local directory to the global directory:

:exec 'cd' getcwd('local')


haslocaldir() has the advantage of (imo) being simpler.


And the disadvantage of being incredibly specific, adding another
function, and more documentation.

And still, wouldn't it be a lot cleaner to have something like
:pushd/:popd for a directory stack.  Then one could write

:pushd ...
⋮
:popd

That way one can easily change directories and later get back to the
state one was in.

It would have to keep track of global and local changes somehow, but
that shouldn't be impossible.

 nikolai

Re: [PATCH] Determining whether a window used :lcd

[Nikolai Weibull]

On 4/25/07, Bob Hiestand <[EMAIL PROTECTED]> wrote:


On 4/25/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:



> OK, I guess then I don't understand your todo entry and Yakov's need for it.

I should clarify, it is my need, and I have no idea who added the
todo.  I found it while trying to discern if the functionality I
needed was provided already.


Ah, Yakov was only suggesting a way of doing it.

I realize you didn't add it, I'm just using "your" here to separate it
from "mine", that is, the one I suggested could be used for your need.


> Either way, wouldn't it be more useful to alter getcwd() to take an
> optional argument stating whether we want the local or global cwd?



The problem is that my plugin needs to change the current working
directory, perform an action, and then restore the previous working
directory.  I need to know whether to use :lcd or :cd to do that.  If
I use :cd in a window that had previously used :lcd, then I clobbered
the :lcd usage and that window is now stuck to the global directory;
additionally, the global directory is changed to whatever the prior
value.  If I instead use :lcd always, and the window wasn't previously
using a local directory, it now is.


let saved_cwd = getcwd('local')
let cd_cmd = (saved_cwd != getcwd('global')) ? 'lcd' : 'cd'
exec cd_cmd '…'
⋮
exec cd_cmd saved_cwd

(assuming getcwd('local') returns the local directory, if there is
one, or whatever getcwd('global') would, if not.)

 nikolai

Re: [PATCH] Determining whether a window used :lcd

[Nikolai Weibull]

On 4/25/07, Bob Hiestand <[EMAIL PROTECTED]> wrote:

On 4/25/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
> > Not at all.  This patch merely exposes some information about the
> > current cd/lcd functionality.  It does not provide new directory
> > changing stack capability.
>
> You misunderstand.  Isn't the functionality requested in "your" todo
> entry just a subset of the one above?  I mean, can't the functionality
> that your todo entry adds be made available with the addition of a
> directory stack?

No, I understand your question, but I don't see any relationship, at
all, between the two items.  Adding current directory stacks has
nothing to do with allowing introspection of the state of a window
variable.  The two changes are completely orthogonal.


OK, I guess then I don't understand your todo entry and Yakov's need for it.

The todo entry is

  There is no way to change directory and go back without changing the local
  and/or global directory.  Add a way to find out if the current window uses
  a local directory.  Add cdcmd() that returns ":cd" or ":lcd"?

I guess I'm just confused about how the first two sentences relate.
Ah, the first sentence is simply a statement that really has very
little to do with the actual todo entry.

I figured that the todo was about having a way of changing directories
and being able to go back.

Either way, wouldn't it be more useful to alter getcwd() to take an
optional argument stating whether we want the local or global cwd?

 nikolai

Re: [PATCH] Determining whether a window used :lcd

[Nikolai Weibull]

On 4/24/07, Bob Hiestand <[EMAIL PROTECTED]> wrote:

On 4/23/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
> > > The attached patch very simply implements the following from the todo:
> Wait!  I have a comment!  Isn't this todo just a subset of
>
> 6   Add ":cdprev": go back to the previous directory.  Need to remember a
> stack of previous directories.  We also need ":cdnext".

Not at all.  This patch merely exposes some information about the
current cd/lcd functionality.  It does not provide new directory
changing stack capability.


You misunderstand.  Isn't the functionality requested in "your" todo
entry just a subset of the one above?  I mean, can't the functionality
that your todo entry adds be made available with the addition of a
directory stack?

 nikolai

Re: replace VimScript

[Nikolai Weibull]

On 4/25/07, Robert Lee <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:



> The only question that is really relevant here is: why it isn't enough
> with having an ECMAScript extension instead of having it replace
> VimScript?
>
> The following arguments have been given:
>
> 1.  Because people wouldn't have to learn another language
> 2.  Because it is standardized
> 3.  Because lots of people are working on efficient implementations
>
> Argument 1) fails because not all people know ECMAScript in the first
> place.  Arguably there are many other choices for languages that more
> people know than ECMAScript.



This is completely true. EMCAScript, however, is never going away and is
known by a very large number of users (both technical and
non-technical).


Never is a very bold claim.  I'm sure Grace Hopper figured COBOL would
be around a lot longer than it was (well, OK, it /is/ still around in
legacy systems, but has, in essence,  "gone away").

And how big is the user base for ECMASCript compared to those of
Python, Perl, Ruby, PHP, Lua, Haskell, O'Caml, ML, Java, Scheme,
Erlang, Lisp?  And for the combination of language X and Vim?


Frankly, one of Vim's greatest barriers-of-entry is the
learning curve. I think much of this is due to its use of proprietary
scripting formats.


The greatest barrier is the radically different mode of operation.
Most editors people come in contact with when beginning to use
computers are the Notepad-type editors: you type in what you want and
there are certain key combinations that you can strike to execute
commands.  Vi (and thus Vim) is radically different (although it
wasn't the first editor to work this way).  Getting used to working
with modes and executing commands is what makes Vi(m) difficult for
beginners.  Having its own scripting language isn't.

And in the end, how different is VimScript from other languages.  The
biggest annoyance I have with it now is that it's not easy enough to
do prototype-based object-orientation with it and that parameters must
be prefixed with a:.


I think there is probably a great deal of overlap
between Vim users and current EMCAScript (a.k.a. JavaScript) users. For
example, I'd imaging that many PHP developers use Vim as their primary
editor (such as myself)...and that most of those users use JavaScript on
the client.


And how many PHP developers are using Vim?

I'd argue that very few people developing with ECMAScript use Vim,
considering the not-quite complete/updated syntax definition and the
lack of a good indentation definition.  I've written my own syntax
definition and contemplated writing and indentation definition, but I
don't use ECMAScript enough to actually get around to it.  Obviously,
few people have.


> Argument 2) fails because using a standardized language instead of a
> application-specific language gives us no advantages.  On can also
> argue that the application-specific language is standardized in the
> sense that it is the standard.



I disagree. By using a standard language you automatically inherit a
great deal of existing frameworks, libraries and scripts...not to
mention talent.


It seems to me that you're using the word standard here to mean normal
or common.  I'll assume that were still talking about ECMAScript being
a language with a standardization attached to it.

The ECMA standard of ECMAScript doesn't standardize any frameworks,
libraries or scripts.


I'd also state that it is no accident that EMCAScript
(JavaScript) is a standard. It is a standard because it is a technically
excellent scripting solution. It has vast support for object oriented
programming, is extensible (think DOM), is easy to learn, is very
mature, and has several available free and open source implementations.


/Prototype-based/ object-oriented programming.  This can be done with
VimScript as well, although JavaScript has "slightly" better syntax
for it.

The DOM isn't defined in the ECMAScript standard.  It is maintained by
W3.  Browsers enable access to the DOM in their ECMAScript/JavaScript
API.

Mature?  ECMAScript is rapidly changing.  Just check out what they're
doing for 1.7.  Sure, that doesn't mean that it's not mature, but it
certainly doesn't mean that it's in any way done and you won't have to
learn new stuff if you use it.


I'd add at least two additional arguments:

4) Using an existing (unmodified) implementation takes some of the
maintenance burden out of the hands of the Vim developer(s). Its always
nice to let someone else to the work. :-)


Yes.  All you have to do is replace one of the largest parts of the code base.


5) EMCAScript is more mature and technically superior. You may not like
the language personally, but certainly you cannot deny that there are
advantages in using an object oriented language.


ECMAScript is a prototype-based language, just like VimScript.

To be fair, I like neither language very much.

 nikolai

Re: replace VimScript

[Nikolai Weibull]

On 4/24/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:
> On 4/24/07, Ilya Sher <[EMAIL PROTECTED]> wrote:
>> Robert Lee wrote:
>> > [snip]
>>
>> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
>> > using SpiderMonkey) so that people don't need to learn a new language
>> If I understand you correctly, you assume that
>> ECMAScript is the most popular language among
>> the people that wish to customize VIM. How
>> do you know the assumption is right?
>
> Aw, come on.  Everyone knows ECMAScript.  It's like with HTML:
> everyone knows HTML.  It's like on the web and stuff.
>
> I mean, seriously, it's a lot more intuitive to write
>
> Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t',
> "")
>
> than
>
> :set fo-=t
>
> It's all about domain specific languages.  It's said so on the internet.



More intuitive?


I was being sarcastic.  The whole point is that VimScript has a very
specific problem-domain and the language reflects that.  If one was to
use, for example, ECMAScript as the way of giving commands to Vim one
would have a very much more cumbersome interface to work with.  Again,
having ECMAScript as an extension language, like Ruby or Python, is
fine, I don't argue with that.  But the key word of the initial
statement was "replace".  It was most likely just a wind up, but it
was then suggested that it was actually a good idea.


:set fo-=t


I'm not saying that what the above statement is obvious in what it
will actually do, if anyone thought that.  I'm just saying that it's a
very simple way to modify the options of Vim, if you know what you're
doing.

 nikolai

Re: wish: allow a: in the function def

[Nikolai Weibull]

On 4/25/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:



> Yes, that's the reason for the a: modifier.  And yes, why are they
> read-only?VimScript isn't a functionaly programming language.
> Variables are mutable; arguments should be to.



Why?

Vim is a good programming language, arguments as such should never be mutable.
When a value can be passed back (in languages which allow it), the argument is
not the value but the _address_ of the value, and that is, again, not 
changeable.


I'm not suggesting implementing pass-by-reference.

 nikolai

Re: wish: allow a: in the function def

[Nikolai Weibull]

On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:

Nikolai Weibull schrieb:
> On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
>> Thomas schrieb:
>
>> > So maybe one could make vimscript search a variable foo as l:foo,
>> a:foo,
>> > (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
>> > variable name error if none exists. Or so.
>
>> Don't like the idea.
>> In Vim script there is no need or possibility to declare variables.
>> Now, if I forget to init a fun-local variable (happens often to me)
>> Vim gives me a helpful error ("undefined variable").
>
> And I have the same problem with a: prefixes for my arguments.  Fine,
> keep prefixes for g:, w:, and b:, but a: is just such an incredibly
> nonstandard way of doing things.  In almost all languages parameters
> are treated the same as local variables.
>
>  nikolai

As long as function arguments are read-only, it is good to have
the a: modifier.

In fact, why are they read-only, although call is by value?


Yes, that's the reason for the a: modifier.  And yes, why are they
read-only?VimScript isn't a functionaly programming language.
Variables are mutable; arguments should be to.

Although I'm sure there's an implementation reason for this, it must
be possible to fix.

Still, I don't have a patch, so I should probably just shut up now.  I
just hoped it could be better to spend some time to remove this
restriction and drop the requirement of a: instead of adding
additional handling for the declaration of parameters.

 nikolai

Re: wish: allow a: in the function def

[Nikolai Weibull]

On 4/24/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:


Besides C and descentants, no other language treats function parameters
as local variables.


What am I missing?

*  You can assign to parameters in most languages.
*  You don't prefix parameters in some manner in most languages.
*  A parameter is shadowed by later declarations of variables with the
same name in most languages.


I actually like a:,l:,g:,b: etc prefixes. They are useful in practice
because in languages
like C++, people tend to invent project-specific suffixes and prefixes
to distinguish between method vars, local vars, etc.
Vim codifies this. I find this convenient.


I have never seen anyone having a separate prefix for method variables
and local variables.  Instance variables, static variables, global
variables, sure, for example, "m_", "s_", "g_".


"Incredibly nonstandard" ? Since when ALL programming languages
obey one and the same standard ? From forth to lisp to vb.net to perl ?
Where did you see common standard for all programing languages ?
This thing does not exist. There are families of related languages with
common features and spirit, yes, but where did you see "standard features"
that programming language must obey ? This is ridiculous statement.
There is no such thing.


Eh, that "incredibly nonstandard" refers to the nonstandard treatment
of parameters.

 nikolai

Re: replace VimScript (was: wish: allow a: in the function def)

[Nikolai Weibull]

On 4/24/07, Gregory Seidman <[EMAIL PROTECTED]> wrote:


In fact, what I'm asking it
to do currently rarely takes much time, but it could be really nice to ask
it to do a lot more and still not pay a huge time or memory penalty.


What plugins/functionality are we missing that require better efficiency?


Efficiency is definitely important.


VimScript is probably in the order of 10^6 times slower (if not more)
than C, and yet we have loads and loads of usable plugins.

And what about the size of, for example, Tamarin.  It's quite a big
piece of software.  That would certainly incur a memory penalty.


> >It is looking more and more like the world of scripting languages for
> >application extension (as opposed to standalone scripting languages) is
> >converging on ECMAScript and Lua, particularly for interactive apps.
>
> I'm sure Microsoft agrees with this sentiment.

What does Microsoft have to do with anything?


Microsoft has, though hardly to any real degree of success, always
pushed for VBA.  Sure it has JScript as well and many languages could
be used for application automation of windows applications.


> >There's a lot to be said for following a path that leads to
> >interoperability and code reuse.
>
> Yeah, follow-the-leader is everyone's favorite game.  And just look at
> all the libraries for both these languages.  Application extension may
> sometimes be restricted to the domain of the actual application, but
> having an abundance of libraries certainly opens up for more
> interesting possibilities.

Vim already has Perl, Python, and Ruby interpreters for application
extension, assuming you build it with the appropriate options. Any library
available for any of these languages can be made available to the Vim
runtime with minimal hassle.


Wasn't that sort of my argument?


Are there lots of VimScript libraries that are
outside the application domain? So how does replacing VimScript with
ECMAScript prevent these interesting possibilities?


I don't see why you have to replace VimScript with ECMAScript to get
ECMAScripts do what can be done with the, for example, Ruby bindings.


As for following the leader, you are on shaky ground.


No, but the following argument certainly is:


Vim followed in the
footsteps of vi just as Linux followed in the footsteps of Unix. Do you see
something wrong with adopting good choices simply because other people are
making the same good choices? I think that recognizing good choices being
made by others and benefiting from them is a pretty good idea.


Yes, Vim took over where vi had stagnated.  Linux was created as a
free version of a Unix-like operating system.  I don't see how that
has anything to do with "rip out all the internals of Vim and replace
them with a spider-monkey-type-thingy".  I mean, it's not like Bram
had Vi, removed insert mode and replaced it with virtual replace mode
and made a better editor.  (Yes, straw-man that if you like.)

And just because companies like Adobe and software foundations like
Mozilla have chosen JavaScript (and most Adobe applications have a COM
interface, so their not usually limited to just JavaScript) for their
extension languages doesn't mean it makes sense for others.


> >I would argue that international standardization lends ECMAScript an
> >edge over Lua, incidentally.
>
> Lua is standardized in the sense that it has only one implementation.

The same applies to Intercal. I don't see the relevance.

You seem to have a particularly hostile view toward ECMAScript, beyond a
simple preference for the status quo, and I'm not sure why. Would you like
me to talk about why I like it as a language, rather than why I think it
would benefit Vim?


Would you like it if I talked condescending to you?

The only question that is really relevant here is: why it isn't enough
with having an ECMAScript extension instead of having it replace
VimScript?

The following arguments have been given:

1.  Because people wouldn't have to learn another language
2.  Because it is standardized
3.  Because lots of people are working on efficient implementations

Argument 1) fails because not all people know ECMAScript in the first
place.  Arguably there are many other choices for languages that more
people know than ECMAScript.

Argument 2) fails because using a standardized language instead of a
application-specific language gives us no advantages.  On can also
argue that the application-specific language is standardized in the
sense that it is the standard.

Argument 3) fails because it simply isn't true.  Last I heard Tamarin
was going to be "integrated" with SpiderMonkey but that that mostly
meant phasing out SpiderMonkey and replacing it with Tamarin.  So that
leaves Tamarin.  And sure, there are probably a bunch of people
working on Tamarin, because it's a complex piece of software, but
plural number of (freely available) implementations I wouldn't say
that there are.

 nikolai

Re: replace VimScript (was: wish: allow a: in the function def)

[Nikolai Weibull]

On 4/24/07, Gregory Seidman <[EMAIL PROTECTED]> wrote:

On Tue, Apr 24, 2007 at 05:57:45PM +0200, Nikolai Weibull wrote:
> On 4/24/07, Ilya Sher <[EMAIL PROTECTED]> wrote:
> >Robert Lee wrote:
> >> [snip]
> >
> >> Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> >> using SpiderMonkey) so that people don't need to learn a new language
> >If I understand you correctly, you assume that
> >ECMAScript is the most popular language among
> >the people that wish to customize VIM. How
> >do you know the assumption is right?
>
> Aw, come on.  Everyone knows ECMAScript.  It's like with HTML:
> everyone knows HTML.  It's like on the web and stuff.
>
> I mean, seriously, it's a lot more intuitive to write
>
> Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t', "")
>
> than
>
> :set fo-=t
>
> It's all about domain specific languages.  It's said so on the internet.

Hey, congratulations! You designed a crappy API! Of course, you can
design a crappy API in any language.


Yes, sorrry.  My two minute API design is obviously flawed.  Perhaps
we can get to see a better one?


Take a look at this:

:let &fo = substitute(&fo, "t", "", "")

That looks terrible! Oh, hang on, you say there's a better way?


Yes?


I'm not impressed with your strawman argument.


And I'm not impressed with your argument for replacing VimScript with
ECMAScript.

Either way, this point is completely moot.  VimScript strikes a
balance between being a set of editor commands and a programming
balance.  It's not perfect by any means, but it does fit the model
quite well.  It won't be replaced, for the simple reason that
VimScript is, in essence, Vim.

 nikolai

Re: wish: allow a: in the function def

[Nikolai Weibull]

On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:

Thomas schrieb:



> So maybe one could make vimscript search a variable foo as l:foo, a:foo,
> (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> variable name error if none exists. Or so.



Don't like the idea.
In Vim script there is no need or possibility to declare variables.
Now, if I forget to init a fun-local variable (happens often to me)
Vim gives me a helpful error ("undefined variable").


And I have the same problem with a: prefixes for my arguments.  Fine,
keep prefixes for g:, w:, and b:, but a: is just such an incredibly
nonstandard way of doing things.  In almost all languages parameters
are treated the same as local variables.

 nikolai

Re: replace VimScript (was: wish: allow a: in the function def)

[Nikolai Weibull]

On 4/24/07, Ilya Sher <[EMAIL PROTECTED]> wrote:

Robert Lee wrote:
> [snip]

> Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> using SpiderMonkey) so that people don't need to learn a new language
If I understand you correctly, you assume that
ECMAScript is the most popular language among
the people that wish to customize VIM. How
do you know the assumption is right?


Aw, come on.  Everyone knows ECMAScript.  It's like with HTML:
everyone knows HTML.  It's like on the web and stuff.

I mean, seriously, it's a lot more intuitive to write

Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t', "")

than

:set fo-=t

It's all about domain specific languages.  It's said so on the internet.

 nikolai

Re: replace VimScript (was: wish: allow a: in the function def)

[Nikolai Weibull]

On 4/24/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:

On 4/24/07, Ilya Sher <[EMAIL PROTECTED]> wrote:
> Robert Lee wrote:
> > [snip]
>
> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> > using SpiderMonkey) so that people don't need to learn a new language



As a sarcastic joke, this sounds average. But seriously, vim
having supprt for embedded perl,python,ruby, tcl and scheme
interpreters, it is realistically to expect javascript interpreter added
one day.


Yes.  All that is required is that someone actually invests some time
into doing it.

 nikolai

Re: replace VimScript (was: wish: allow a: in the function def)

[Nikolai Weibull]

On 4/24/07, Gregory Seidman <[EMAIL PROTECTED]> wrote:

On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote:
> Robert Lee wrote:
> [snip]
> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> > using SpiderMonkey) so that people don't need to learn a new language
> If I understand you correctly, you assume that
> ECMAScript is the most popular language among
> the people that wish to customize VIM. How
> do you know the assumption is right?
> [snip]

Actually, I like the proposal for two entirely different reasons:

1) the language specification comes from an international standards body


So?  In what way does this make it a good language?  In what way does
this make it a good language to extend Vim with?  Anyone can write a
standard.  It doesn't mean that it's good or what is being
standardized will be, either.


2) there are lots of people working on efficient implementations, at least
   two of which are open source (SpiderMonkey and Adobe's Tamarin, though
   there seem to be some plans to convert SpiderMonkey to use Tamarin)


SpiderMonkey is a terribly inefficient implementation, which is why
Tamarin will be used in future versions of Gecko.  And I wouldn't say
that efficiency is the primary concern of a language/runtime engine to
use for Vim.


It is looking more and more like the world of scripting languages for
application extension (as opposed to standalone scripting languages) is
converging on ECMAScript and Lua, particularly for interactive apps.


I'm sure Microsoft agrees with this sentiment.


There's a lot to be said for following a path that leads to interoperability and
code reuse.


Yeah, follow-the-leader is everyone's favorite game.  And just look at
all the libraries for both these languages.  Application extension may
sometimes be restricted to the domain of the actual application, but
having an abundance of libraries certainly opens up for more
interesting possibilities.


I would argue that international standardization lends
ECMAScript an edge over Lua, incidentally.


Lua is standardized in the sense that it has only one implementation.

 nikolai

Re: [PATCH] Determining whether a window used :lcd

[Nikolai Weibull]

On 4/20/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


On 4/11/07, Bob Hiestand <[EMAIL PROTECTED]> wrote:



> The attached patch very simply implements the following from the todo:



> 7   There is no way to change directory and go back without changing the local
> and/or global directory.  Add a way to find out if the current window uses
> a local directory.  Add cdcmd() that returns ":cd" or ":lcd"?



If you agree, and nobody has something to say on this, can you change
your patch?


Wait!  I have a comment!  Isn't this todo just a subset of

6   Add ":cdprev": go back to the previous directory.  Need to remember a
   stack of previous directories.  We also need ":cdnext".

with local directory alternatives as well?  One could then change
directory and simply pop the top of the cd stack when one is done.  Of
course, this could quite easily be implemented in VimScript if builtin
commands could be overridden, like :cd and :lcd.  Then one could
maintain a stack with a VimScript list.

An alternative, seeing as how we've already discussed overriding
builtin commands and my side of the argument lost, would be to add a
DirectoryChanged autocommand.  Then one could at least implement
:Cdprev and :Cdnext.

I'm probably missing something here, but I can't see what it is.

 nikolai

Re: wish: allow a: in the function def

[Nikolai Weibull]

On 4/23/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:

wish: allow a: in the function definition line:
  function foo(a:line1, a:line2)
This is currently not allowed. But it seems logical to allow it.


Why should it be?  Extra typing?

Counterwish: implement better semantics for VimScript so that the
lookup order of variables alleviates the need for explicit
environments.  Yes, this will break backwards compatibility.  Tough.

 nikolai

Re: possible bug with vim7 and the arrow keys

[Nikolai Weibull]

On 4/23/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:

Viktor Kojouharov wrote:



> It turned out that these mappings broke the arrow keys in the terminal:
> inoremappumvisible()?"\":"\"



IMHO, if one is expecting to use vim (as opposed to gvim), mapping 
causes trouble.
That's because most terminals issue escape sequences
(..something..) when special
keys (such as the arrow keys, functions keys, etc), and that mapping of
the  key
messes up the escape sequence.


That's only true if Vim actually interprets the characters coming in
as normal characters and not an escape sequence.  In that case it
doesn't matter if  is remapped or not, you're going to get weird
results anyway.


Besides -- how do you get out of insert
mode?  I realize
one can use ctrl-o and norm!,  but that seems painful.  If you're not
using normal mode
or command mode, then you're missing a lot of vim.


If the pum isn't visible it maps to , so it's not hard to get out
of insert mode.  Just make sure the pum isn't visible.

 nikolai

Re: syntax highlighting addition

[Nikolai Weibull]

On 4/22/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:



> What I meant was that Bram mentioned that he uses Ctrl+N to complete
> names in emails to make sure he doesn't misspell people's names.  In
> his response to Jonathan's mail he wrote Nikola (note the missing 'i'
> in Nikola/i/), so I figured I'd be humorous about it and say that
> Ctrl+N completion seems broken in his version of Vim.



Ah, I see. I thought it was something that /you/ had experienced. Yes, I
missed the point, and the "l" of "completion slipped away in the process (in
part because I compose my emails using Thunderbird, not Vim, and that it
doesn't have that kind of completion).


;-)

 nikolai

Re: syntax highlighting addition

[Nikolai Weibull]

On 4/21/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:
> On 4/20/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
>> Getting better.  Nikola's comments also apply (thanks Nikola!).
>
> No problem.  I guess there's a bug in the current Ctrl+N
> implementation?  It seems to be cutting off the last character in the
> completion.  ;-)



Insert-mode competion, you mean? I don't see anything cut off; but I use ":set
completeopt=menuone,preview" which adds info (for Ctrl-N: where it was found,
if not the current file) to the right of the menu items. There seems to be a
maximum width, and the last column of the menu looks like a scrollbar. Maybe
an off-by-one error if "preview" is not included?


You totally missed the point.

What I meant was that Bram mentioned that he uses Ctrl+N to complete
names in emails to make sure he doesn't misspell people's names.  In
his response to Jonathan's mail he wrote Nikola (note the missing 'i'
in Nikola/i/), so I figured I'd be humorous about it and say that
Ctrl+N completion seems broken in his version of Vim.

 nikolai

Re: syntax highlighting addition

[Nikolai Weibull]

On 4/20/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


Getting better.  Nikola's comments also apply (thanks Nikola!).


No problem.  I guess there's a bug in the current Ctrl+N
implementation?  It seems to be cutting off the last character in the
completion.  ;-)

 nikolai

Re: syntax highlighting addition

[Nikolai Weibull]

On 4/19/07, Jonathan Smith <[EMAIL PROTECTED]> wrote:


Bram Moolenaar wrote:



> "recipe" is not a good filetype name.  Is there anything against using
> "conary"?



Well, the files are called recipes. In the same way that you wouldn't call a
spec file "rpm", you wouldn't call a recipe "conary". Conary has other file
types which it uses, which vim should not be able to edit (changesets, the
equivalent of an RPM).


Well, the rpm spec file-type has been with us a long time, well before
we knew better.  Try to give your file-type an as specific name as
possible.  You will not be getting the name "recipe"; it's way too
generic in this day and age.  Go with "conrecipe" or something
similar.  Remember: Bram has his own build system, called Aap, which
also uses recipes.  Also, if Vim will never edit a (Conary) changeset,
then why will we have to worry about a name-clash between different
conary file-types?


" Vim syntax file
" Language: Conary Recipe
" Maintainer:   rPath Inc 
" Updated:  2007-04-18
"


Nitpick: remove the empty comment.


" For version 5.x: Clear all syntax items
" For version 6.x: Quit when a syntax file was already loaded
if version < 600
  syntax clear
elseif exists("b:current_syntax")
  finish
endif


Just do

if exists("b:current_syntax")
 finish
endif

No one will be using your syntax definition with vim 5 anyway.  Let's
keep new files clean from (now) unnecessary cruft.


syn keyword conaryUseFlag   contained pcre tcpwrappers gcj gnat selinux pam
syn keyword conaryUseFlag   contained bootstrap python perl
syn keyword conaryUseFlag   contained readline gdbm emacs krb builddocs
syn keyword conaryUseFlag   contained alternatives tcl tk X gtk gnome qt
syn keyword conaryUseFlag   contained xfce gd ldap sasl pie desktop ssl kde
syn keyword conaryUseFlag   contained slang netpbm nptl ipv6 buildtests
syn keyword conaryUseFlag   contained ntpl xen dom0 domU
syn match   conaryUse   "Use\.[a-z0-9.]*" contains=conaryUseFlag


Sure that * shouldn't be a \+?  And can you have a sequence of dots,
as in Use...?  Also, you're not using

syntax case ignore,

so I don't quite see how [a-z0-9.] will match "X" or "domU".

A better way of doing this is to do (substitute \w with whatever
pattern your parser actually allows)

syn match conaryUse
\ "Use\.\w\+"
\ nextgroup=conaryUseFlag

syn keyword conaryUseFlag
\ contained
\ nextgroup=conaryUseFlagSeparator
\ pcre
\ tcpwrappers
\ ...

syn match conaryUseFlagSeparator
\ contained
\ nextgroup=conaryUseFlag
\ '\.'


"syn match   conaryR"r\.\w*" contains=conaryFunction


Leftover?


if version >= 508 || !exists("did_python_syn_inits")
  if version <= 508
   let did_python_syn_inits = 1
command -nargs=+ HiLink hi link 
  else
command -nargs=+ HiLink hi def link 
  endif


Just skip this.  No one will be using your syntax definition with Vim 5.


  "HiLink pythonStatement   Statement
  "HiLink pythonFunctionFunction
  "HiLink pythonConditional Conditional
  "HiLink pythonRepeat  Repeat
  "HiLink pythonString  String
  "HiLink pythonRawString   String
  "HiLink pythonEscape  Special
  "HiLink pythonOperatorOperator
  "HiLink pythonPreCondit   PreCondit
  "HiLink pythonComment Comment
  "HiLink pythonTodoTodo


?


" vim: ts=8


This is the default setting.

 nikolai

Re: syntax/man.vim: manSubHeading is a bit too general?

[Nikolai Weibull]

On 4/10/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:

> On 4/9/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:
>
>> In this case, by looking at syntax/man.vim, its:  Gautam H. Mudunuri
>> .
>
>
> Actually, this was actually the wrong maintainer.  Gautam was the
> previous maintainer of this file.  Nam SungHyun <[EMAIL PROTECTED]>
> maintains it now.

Whoops -- yes, you're quite right.  Sorry 'bout that...


What's worse is that that address is no longer valid.  I've tried
another address attached to one Nam SungHyun.  We'll see if he
responds.

 nikolai

Re: syntax/man.vim: manSubHeading is a bit too general?

[Nikolai Weibull]

On 4/9/07, Ian Tegebo <[EMAIL PROTECTED]> wrote:

On 4/9/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:



>   ^ \{3\}[a-z][a-z ]*[a-z]$
I hope nobody minds if I take this opportunity to ask a question about
vim's pattern matching.

After reading |pattern| I wonder if the following is more efficient:

syn match manSubHeading '^ \{3\}\l\l\?\l$'


Yes, and it may be more correct as well, at least in the first and
last instance.  However, the second part may also contain a space, so
\l isn't correct there; and I don't know where you get that \? from.
This is the correct pattern:

 ^ \{3}\l[[:alpha:] ]*\l$

(I also noticed that the apparently accepted "\{m\}" is being used in
this file instead of the documented "\{m}")

One can of course ask oneself if a subsection heading must consist of
at least two letters.  I'm guessing that the intent was to force the
line to end with a non-space:

 ^ \{3}\l\%([[:alpha:] ]*\l\)\=$

In fact, I'd prefer it be written as

 ^ \{3}\a\%([[:alpha:] ]*\a\)\=$

as 'syn case ignore' is on, \l and \a will be the same.  However, \a
meshes better with [:alpha:] and may, depending on how all this is
implemented, be a miniscule amount faster.


Taken from |pattern|:

- Matching with a collection can be slow, because each character in
  the text has to be compared with each character in the collection.
  Use one of the other atoms above when possible.  Example: "\d" is
  much faster than "[0-9]" and matches the same characters

Do people find this to make a different for moderate file sizes, e.g.
the man page for 'less' being ~2000 lines?


Probably not.

 nikolai

Re: syntax/man.vim: manSubHeading is a bit too general?

[Nikolai Weibull]

On 4/9/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:


In this case, by looking at syntax/man.vim, its:  Gautam H. Mudunuri
.


Actually, this was actually the wrong maintainer.  Gautam was the
previous maintainer of this file.  Nam SungHyun <[EMAIL PROTECTED]>
maintains it now.

 nikolai

Re: syntax/man.vim: manSubHeading is a bit too general?

[Nikolai Weibull]

On 4/9/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:



> The manSubHeading is defined as
>
> syn match  manSubHeading  "^\s\{3\}[a-z][a-z ]*[a-z]$"
>
> This will, however, match more lines than I think is intended.



> Anyone have any insight into this issue?



I suggest bringing up syntax highlighting issues for a specific filetype
with the syntax highlighting file's maintainer.
In this case, by looking at syntax/man.vim, its:  Gautam H. Mudunuri
.


Or, as the file mentions four lines down, Johannes Tanzler
<[EMAIL PROTECTED]>, who was responsible for this particular
rule.  However, I reasoned that someone with better knowledge than
myself of the output format of manual pages could jump in and correct
me or, better yet, confirm my change.  I would then be in a position
to post a patch to the maintainer.  If the maintainer or the person
responsible for this particular rule has subscribed to this list, then
they would also benefit from this discussion.  Sure, I could have
Cc:ed the responsible parties right away, but I figured that if they
don't subscribe to this list they don't want bothersome emails about
syntax-highlighting definitions that don't have a conclusion to an
issue at hand.

Some further digging has revealed that what manSubHeading tries to
match is lines marked as ".SS", that is "Subsection Heading", and that
groff and nroff formats these lines with an indent of three spaces, so
my initial suspicion was correct.  I'll therefore contact the
appropriate parties with a unified diff.

 nikolai

syntax/man.vim: manSubHeading is a bit too general?

[Nikolai Weibull]

The manSubHeading is defined as

syn match  manSubHeading  "^\s\{3\}[a-z][a-z ]*[a-z]$"

This will, however, match more lines than I think is intended.  It
will, for example, match the line

\t  returns are what are recorded and compared with the data git keeps

where "\t" is a horizontal tabulation.  I'm guessing that the actual
regex should be

 ^ \{3\}[a-z][a-z ]*[a-z]$

but I'm not sure; I haven't been able to find a reference for the
display of manual pages.

Anyone have any insight into this issue?

 nikolai

Re: Experimental patch -- clipboardwatch for Win32

[Nikolai Weibull]

On 3/26/07, Ken Hirsch <[EMAIL PROTECTED]> wrote:

Here is an experimental patch for a new feature for gvim on MS Windows.
I'm glad to hear any feedback about the code or the feature itself. I've
tried to follow the conventions in the vim source code.  I call the
feature "ClipboardWatch".

The new feature triggers an event "ClipboardChanged" whenever the
clipboard is changed (in any application).  The Windows editor "NoteTab"
implements this (as "pasteboard") and it is, at times, very handy.


This doesn't seem quite relevant enough to include in Vim.  The
example you give can quite easily be implemented with autohotkey [1].

 nikolai

[1] http://autohotkey.com/

Re: Understanding regxp implementation

[Nikolai Weibull]

On 3/22/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:


As you might know, the reg_comp() method is called twice when compiling
a r.e; first to determine the size of the compiled expression and then
to actually compile it. I was thinking if this can be used to our
advantage, while on the first pass, we look for occurrences of special
characters and set a flag in regprog_T appropriately. If such thing was
not found, we branch off the second pass into one of our own routines to
compile the expression into our own structures (say, a state diagram).
And we have to change other functions a bit to look for the above flag
and call new routines appropriately. What do you think ?


That sounds like a good way of determining whether the old engine will
be required or if a new one (with more "limited" functionality) should
be used.  One way of keeping this information as local as possible
would be to keep a set of function pointers with the compiled regex
that point to the appropriate functions to execute them on some input.

For example, you could have something like this:

typedef struct
{
   int (*exec)();
   int  regstart;
   char_u   reganch;
   char_u   *regmust;
   int  regmlen;
   unsigned regflags;
   char_u   reghasz;
   char_u   program[1]; /* actually longer.. */
} regprog_T;

and change vim_regexec() to call the exec() function of the regprog_T
in the regmatch_T that it gets passed.  You'd then set exec() to point
to either vim_old_regexec() or vim_new_regexec() (or similarly named
functions) in vim_regcomp() depending on the type of regex we have.  I
guess it could be some flag field as well, but this makes it possible
to add a third matcher, should we so desire...like a
Boyer-Moore-Horspool matcher for fixed strings.

 nikolai

Re: Understanding regxp implementation

[Nikolai Weibull]

On 3/20/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:


I went through the regxp code and have a few questions...

First, Why use this kind of a coding scheme and encode patterns rather
than using a state diagram ? ( Performance/Memory ? ).


Because that's how Henry Spencer did it.  I don't know his reasoning,
though.  It's probably a case of trying to limit memory use and
avoiding a conceptually more complex data structure, but not exactly
sure.  You can find his original sources here:

http://arglist.com/regex/


Secondly, is it a
requirement that the new implementation has to follow the same method ?
I mean, can't I use a state diagram ( which is easy to implement in my
opinion ) to simulate the NFA ?


I thought the point was that you can use whatever method you want?
And that you might use an already existing library, like TRE.

In TRE 0.7.2 (I think - might have been 0.7.0), Ville added support
for more general input.  This means that you can provide an object
that feeds the regex matcher with input.  In Vim's case that would be
feeding it the contents of successive memlines until a match is found
or the buffer is "depleted".  That should be a quite simple way of
using TRE in Vim.

The main problem with using TRE, however, is that it only works with
"ASCII" or wide character input.  That means that it isn't well-suited
for Vim's internal buffer format of just keeping bytes around in
whatever encoding they may be.  To use TRE you'd have to transcode the
buffer's bytes to wchar_t's (wide characters that are hopefully
interpreted as Unicode characters by the standard C library on the
system we're running on), depending on the buffers encoding.

Perhaps working on a Vim-specific matcher for TRE would be valuable.

I would suggest that you subscribe to the TRE mailing list.  I haven't
asked Ville what editor he prefers, but considering his indentation
style, it's probably Emacs :-(.  But perhaps he's willing to help us
out anyway?

http://laurikari.net/mailman/listinfo/tre-general

 nikolai

Re: Understanding regxp implementation

[Nikolai Weibull]

On 1/1/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:

On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote:
> On 3/19/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:
> > Hi Bram, Nicolai,
>
> A 'k' would be greatly appreciated.

I'm really really sorry, won't happen again...


Hehe, don't take it too hard, it happens to me all the time.  If I had
a dime for every misspelling of my name, I'd have...more money than I
do now.

 nikolai

Re: Understanding regxp implementation

[Nikolai Weibull]

On 3/19/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:

Hi Bram, Nicolai,


A 'k' would be greatly appreciated.


I'm unable to grasp the description ( attachment ) given in the regxp.c
file. For a moment they seem like NFA fragments for operators |,+,*


Well, yes, that's what they are.  The diagrams show you how the
different operators are represented.  I think the representation can
be a bit difficult to grasp at first, because the representation isn't
like a state diagram/tree/DAG, but more of a list of assembler
instructions.These assembler-like instructions are then executed
by an interpreter that executes the appropriate C code for doing the
matching.  This is (mainly) done in regmatch().

 nikolai

Re: Improving regexp performance

[Nikolai Weibull]

On 3/18/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:


On Sun, 2007-03-18 at 14:07 +0100, Nikolai Weibull wrote:



> Then there's the parallel one that keeps track of all the states that
> we're currently in that accepts as soon as an accepting/final state is
> reached.



I think by parallel you are referring to the usual mechanism for
simulating the NFA ( on the fly subset construction ? ). Simply, we have
a set of states ( initially S0 ) and the we keep eating a symbol at a
time, calculate the next possible set of states ( including E-closure )
and whenever the current set of states contain an accepting state of the
original NFA, Voila!


Yes.  Quite elegant, wouldn't you say?  ;-)


> And then there's the cached DFA implementation that builds the DFA
> representation of the NFA as needed while traversing the input.  This
> is the most difficult one to implement, but also the fastest for most
> inputs.



Sorry, but I'm in confusion here. Are you telling me that the current
regxp engine has a cached DFA implementation ? ( I thought such an
implementation was the aim of this project :( )


No.  The current implementation is purely backtracking, with a bunch
of tricks to speed it up.


> Russ Cox's article is good, but doesn't show anyting new, even though
> it has been received like as it would.  And he really skims over some
> of the important issues that one has to consider when using regular
> expressions for doing anything other than just accepting or rejecting
> input as being part of a regular language.  Perhaps most important is
> submatch reporting, which causes all kinds of difficulties that he
> simply doesn't mention.

I agree. Just out of curiosity, I referred to the book "Compilers -
Principles, Techniques and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey
D. Ullman". It has a very nice explanation of NFA, NFA->DFA, Regxp->NFA
and even Regxp->DFA ( I'm still trying to understand the last one ).
I used the article by Russ Cox to verify what I have learnt from the
above book. But I believe that above article is a good starter.


Yes, it's a very good and short (which is a good thing!) summary.  The
book you mention above is also very good, and covers a bit more
theory.  I can highly recommend the following books and articles:

John E. Hopcroft and Jeffrey D. Ullman, Introduction to Automata Theo-
ry, Languages, and Computation. (Addison–Wesley, Reading, Massachusetts,
1979).

This is really the reference work if you care about the theory.
Contains a lot of information on formal languages, of which only the
regular ones are really of interest for this project.

Gonzalo Navarro, NR-grep: A fast and flexible pattern matching tool ,
Software—Practice and Experience 31(13), pp. 1265–1312 (2001).

A very fast grep implementation.  The algorithm used uses bitfields to
keep track of the finite automatons state, making it very fast for
many common patterns.

Alfred V. Aho, Algorithms for Finding Patterns in Strings. In Algorithms
and Complexiy, vol. A of Handbook of Theoretical Computer Science, chapter
5, pp. 255–300 (Elsevier Science Publishers B.V., Cambridge, Massachusetts,
1990).

This last one covers the theory especially well for this project, I'd
say, and contains a very complete bibliography.

I hope you won't drown in information ;-).  More pointers can be found
in my thesis, but those are probably the most interesting ones.


Thank you so much for the feed back. :)


No problem.  I'm very interested to see where this project will go and
I hope I can be of help, should you need it.

 nikolai

Re: Improving regexp performance

[Nikolai Weibull]

On 3/18/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:


I read several articles on possible NFA implementations ( took some time
to understand ). But I think implementing an NFA based approach is quite
possible ( Russ Cox has provided a sample implementation in his
article ). But I'm having a hard time understanding the existing
approach taken :'( .


The current implementation is also an NFA-based one.  What's more
interesting is how the NFA is simulated.  The current implementation
uses backtracking, that is, it tries a solution and checks if it
works.  If so, then accept.  Otherwise, try the next one.

Then there's the parallel one that keeps track of all the states that
we're currently in that accepts as soon as an accepting/final state is
reached.

And then there's the cached DFA implementation that builds the DFA
representation of the NFA as needed while traversing the input.  This
is the most difficult one to implement, but also the fastest for most
inputs.

Russ Cox's article is good, but doesn't show anyting new, even though
it has been received like as it would.  And he really skims over some
of the important issues that one has to consider when using regular
expressions for doing anything other than just accepting or rejecting
input as being part of a regular language.  Perhaps most important is
submatch reporting, which causes all kinds of difficulties that he
simply doesn't mention.

 nikolai

Re: Google Summer of Code 2007 : Improve regexp performance

[Nikolai Weibull]

On 3/16/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:


On 3/16/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:



> Nikolai Weibull wrote:



> > I actually wrote a simplification of his library, removing the
> > approximate matching stuff, as part of my master's, which is well
> > documented.  I still haven't had time to put up the PDF, though.

> Interesting.  Although when the documentation is not available I would
> call it undocumented :-).


Argh!  Forgot (temporary) link.

http://bitwi.se/masters-project.pdf

It's also about text editors for anyone who's interested.

I was going to cannibalize some smaller articles from it, but never
got around to it.  I also like it like it is, although my supervisors
didn't.  Let's hope some of you do ;-).  I'm especially pleased with
the cover.

 nikolai

Re: Google Summer of Code 2007 : Improve regexp performance

[Nikolai Weibull]

On 3/16/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:



> I actually wrote a simplification of his library, removing the
> approximate matching stuff, as part of my master's, which is well
> documented.  I still haven't had time to put up the PDF, though.



Interesting.  Although when the documentation is not available I would
call it undocumented :-).



> Anyway, it would take an immense amount of work to turn Vim onto a new
> regex implementation.  Vim has a whole range of its own stuff, like
> matching cursor positions and so on, and is tightly bound to the
> buffer implementation with its memlines and whatnot.  Not to
> dishearten you, but I don't think this is a project that can be
> completed over a summer (not that it has to be, but you may want to
> keep that in mind).

The idea is that, when compiling the regexp, you check for special items
that are not supported by the new/fast code.  If any is found, fall back
to the old/slow code.  This way you can start with something simple and
add more features over time.  Most patterns don't use back references or
match with the cursor position, thus the new/fast code would be used in
most cases.


Yes, that's a good course of action, and is what most regex libraries
should be doing in my opinion.  It's what Tcl's does, which is,
coincidentally, also written by Henry Spencer (the same guy who wrote
the initial regex implementation that Vim uses).


Matching with text in a Vim buffer is required, can't do much without
it.


No, but what I meant was that most regex libraries expect a char * as
input.  As you yourself has stated, adding support for multiline
matching in the current implementation was nontrivial.  However, that
may mostly be due to backtracking issues, and perhaps it may be easier
to interface with some other implementation.

 nikolai

Re: Google Summer of Code 2007 : Improve regexp performance

[Nikolai Weibull]

On 3/16/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:

On Fri, 2007-03-16 at 10:44 +0100, Nicolas Weber wrote:



> > A multithreaded matcher might be useful to vim but do we have a
> > need for
> > fuzzy matching ?



> vim doesn't use threads at the moment, and Bram seems to be reluctant
> to include threads for various reasons.



I too agree, threading might complicate everything ( and a rather
difficult programing model )...


Again, multithreading as in parallel, as in being able to be in
multiple states at once.  Not pthreads or anything like that.  Sorry
about confusion.  But this may also indicate that more knowledge about
what you're actually about to undertake may be necessary before
setting out.  No offense intended, but the area of formal languages
(that includes regular expressions, regular languages, pattern
matching, and finite automata) isn't exactly the easiest of topics in
computer science, and having a good understanding of this topic really
is necessary to work on things like that discussed in this thread; so
I'd recommend seeing to it that you have the theory nailed down before
writing code or anything like that.

 nikolai

Re: Google Summer of Code 2007 : Improve regexp performance

[Nikolai Weibull]

On 3/16/07, Mikolaj Machowski <[EMAIL PROTECTED]> wrote:


Dnia piątek 16 marzec 2007, Asiri Rathnayake napisał:



> A multithreaded matcher might be useful to vim but do we have a need for
> fuzzy matching ?



For main regexp engine I think not. But it could be useful for command
line completions (think zsh).


I did write multithreading/parallel matcher.  The matcher is
multithreaded in the sense that it can be in many states at once.  It
does not mean that matching is run in separate application threads.
Being able to be in many states at once is what makes it
non-deterministic, by the way.  It also means that it will run faster
than backtracking matchers in most cases, as it never has to
second-guess itself.

 nikolai

Re: Google Summer of Code 2007 : Improve regexp performance

[Nikolai Weibull]

On 3/15/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote:

Hi all,

I went through the above idea presented for google summer of code 2007
and found it interesting. In my opinion, incorporating Thompson NFA into
regexp from the ground up is pretty cool. I also went through the
alternate TRE (http://laurikari.net/tre/index.html) but couldn't verify
whether its an implementation of Thompson NFA ( I will have to dig into
it's source and find it out ). I would like to know further details (if
any) regarding this project and the possible mentor(s).


It has its own finite automata, which is based on a Thompson NFA,
adding so called /tags/ in the mix for doing subgroup matching and
fuzzy matching.

It comes with three matchers/drivers: A backtracking one for when the
pattern requires it (backrefences), a multithreaded/parallel one, that
is, the standard two tables of active states one, and one for fuzzy
matching (approximate matching).

There's a nice paper about it as well (too actually, if you count the
first one he wrote about his first implementation for .

I actually wrote a simplification of his library, removing the
approximate matching stuff, as part of my master's, which is well
documented.  I still haven't had time to put up the PDF, though.

Sadly, both his and my implementation suffer from a bug in the
subgroup matching of "opposing" repetitions, which would have to be
fixed.  Neither of us have been able to do so yet.

Anyway, it would take an immense amount of work to turn Vim onto a new
regex implementation.  Vim has a whole range of its own stuff, like
matching cursor positions and so on, and is tightly bound to the
buffer implementation with its memlines and whatnot.  Not to
dishearten you, but I don't think this is a project that can be
completed over a summer (not that it has to be, but you may want to
keep that in mind).

Also, there's a TDFA (tagged, deterministic finite automaton)
implementation written in Haskell

http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11442.html

Quite cool.

 nikolai

Re: Fwd: A replacement for syntax/zsh.vim

[Nikolai Weibull]

On 3/13/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:

> As nothing has happened with this yet, I"m sending it out again.  I
> really think it's time we make the switch.  Felix has had ample
> opportunity to oppose this (over two years, in fact), and yet has not
> responded even once.  I don't want to seem like a yerk, but my syntax
> definition is better.

OK, I'll include this version.


Thank you.

 nikolai

Fwd: A replacement for syntax/zsh.vim

[Nikolai Weibull]

As nothing has happened with this yet, I"m sending it out again.  I
really think it's time we make the switch.  Felix has had ample
opportunity to oppose this (over two years, in fact), and yet has not
responded even once.  I don't want to seem like a yerk, but my syntax
definition is better.

 nikolai

-- Forwarded message ------
From: Nikolai Weibull <[EMAIL PROTECTED]>
Date: Jun 22, 2006 11:49 PM
Subject: A replacement for syntax/zsh.vim
To: vim-dev 

The current syntax/zsh.vim doesn't reflect the current state of Zsh
very well.  I've tried contacting the current maintainer, Felix von
Leitner, who hasn't responded to any of my three requests for comment
that I've sent over the last one-and-a-half years.  I therefore post
it to this mailing list instead, to see if anyone is interested in
seeing my version replace the one currently being distributed with
Vim.  I have had very positive comments on it from the Zsh-users
mailing list and I hope I will have the same here.

Peace.

 nikolai
" Vim syntax file
" Language:     Zsh shell script
" Maintainer:   Nikolai Weibull <[EMAIL PROTECTED]>
" Latest Revision:  2006-08-06

if exists("b:current_syntax")
  finish
endif

let s:cpo_save = &cpo
set cpo&vim

setlocal iskeyword=@,48-57,_,-

syn keyword zshTodo contained TODO FIXME XXX NOTE

syn region  zshComment  display oneline start='\%(^\|\s\)#' end='$'
\ contains=zshTodo,@Spell

syn match   zshPreProc  '^\%1l#\%(!\|compdef\|autoload\).*$'

syn match   zshQuoted   '\\.'
syn region  zshString   matchgroup=zshStringDelimiter start=+"+ end=+"+
\ contains=zshQuoted,@zshDerefs,@zshSubst
syn region  zshString   matchgroup=zshStringDelimiter start=+'+ end=+'+
" XXX: This should probably be more precise, but Zsh seems a bit confused about 
it itself
syn region  zshPOSIXString  matchgroup=zshStringDelimiter start=+\$'+
\ end=+'+ contains=zshQuoted
syn match   zshJobSpec  '%\(\d\+\|?\=\w\+\|[%+-]\)'

syn keyword zshPrecommand   noglob nocorrect exec command builtin - time

syn keyword zshDelimiterdo done

syn keyword zshConditional  if then elif else fi case in esac select

syn keyword zshRepeat   for while until repeat foreach

syn keyword zshExceptionalways

syn keyword zshKeyword  function nextgroup=zshKSHFunction skipwhite

syn match   zshKSHFunction  contained '\k\+'
syn match   zshFunction '^\s*\k\+\ze\s*()'

syn match   zshOperator '||\|&&\|;\|&!\='

syn match   zshRedir'\d\=\(<\|<>\|<<<\|<&\s*[0-9p-]\=\)'
syn match   zshRedir
'\d\=\(>\|>>\|>&\s*[0-9p-]\=\|&>\|>>&\|&>>\)[|!]\='
syn match   zshRedir'|&\='

syn region  zshHereDoc  matchgroup=zshRedir start='<<\s*\z(\S*\)'
\ end='^\z1\>' [EMAIL PROTECTED]
syn region  zshHereDoc  matchgroup=zshRedir start='<<-\s*\z(\S*\)'
\ end='^\s*\z1\>' [EMAIL PROTECTED]
syn region  zshHereDoc  matchgroup=zshRedir
\ start=+<<\s*\(["']\)\z(\S*\)\1+  end='^\z1\>'
syn region  zshHereDoc  matchgroup=zshRedir
\ start=+<<-\s*\(["']\)\z(\S*\)\1+
\ end='^\s*\z1\>'

syn match   zshVariable '\<\h\w*\ze+\=='
" XXX: how safe is this?
syn region  zshVariable oneline
\ start='\$\@'
endif

if s:zsh_syntax_variables =~ 'long\|all'
  syn match zshLongDeref
'\$\%(ARGC\|argv\|status\|pipestatus\|CPUTYPE\|EGID\|EUID\|ERRNO\|GID\|HOST\|LINENO\|LOGNAME\)'
  syn match zshLongDeref'\$\%(MACHTYPE\|OLDPWD 
OPTARG\|OPTIND\|OSTYPE\|PPID\|PWD\|RANDOM\|SECONDS\|SHLVL\|signals\)'
  syn match zshLongDeref
'\$\%(TRY_BLOCK_ERROR\|TTY\|TTYIDLE\|UID\|USERNAME\|VENDOR\|ZSH_NAME\|ZSH_VERSION\|REPLY\|reply\|TERM\)'
endif

if s:zsh_syntax_variables =~ 'all'
  syn match zshDeref'\$[=^~]*[#+]*\h\w*\>'
else
  syn match zshDereftransparent '\$[=^~]*[#+]*\h\w*\>'
endif

syn match   zshCommands '\%(^\|\s\)[.:]\ze\s'
syn keyword zshCommands alias autoload bg bindkey break bye cap cd
\ chdir clone comparguments compcall compctl
\ compdescribe compfiles compgroup

Re: Suggestion for :syn-nextgroup enhancement

[Nikolai Weibull]

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 :-(.  I'm taking the easy way out and adding the group to
everythings nextgroup instead for this syntax definition.  We'll see
if that slows things down unbearably.

 nikolai

Re: Suggestion for :syn-nextgroup enhancement

[Nikolai Weibull]

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 is much like skipwhite, skipnl, and
skipempty, but for arbitrary syntax groups.


Actually, what makes even more sense would be to add a "skippable"
directive, which could then be set on tocComment.  This may be harder
to implement, though.

 nikolai

Suggestion for :syn-nextgroup enhancement

[Nikolai Weibull]

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 example,
many languages allow comments to appear almost anywhere in the input,
which are stripped out of the input while lexing the input into tokens
that are then fed to the actual parser.  Now comments could be a part
of the grammar, simply being thrown away at that point in the process,
but it forces you to provide for the possibility of a comment
appearing basically anywhere between terminals/non-terminals.

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 is much like skipwhite, skipnl, and
skipempty, but for arbitrary syntax groups.

Here's an example of what I intend for it to do:

syn keyword tocTodo
 \ contained
 \ TODO
 \ FIXME
 \ XXX
 \ NOTE

syn match   tocComment
 \ contains=tocTodo,@Spell
 \ '//.*$'

syn keyword tocHeaderKeyword
 \ nextgroup=tocCatalogNumber
 \ skip=tocComment
 \ skipwhite
 \ skipempty
 \ CATALOG

syn match   tocCatalogNumber
 \ contained
 \ '"\d\{13\}"'

This is a partial grammar that matches comments and the CATALOG
keyword in the header part of a cdrdao(1) TOC file (yes, I'm writing a
grammar for such files).  Comments begin with a set of slashes and can
appear anywhere in the file.  The CATALOG keyword is followed by a
(optional, but let's keep it simple for this example) catalog number.
The idea here is that the skip=tocComment directive to
tocHeaderKeyword will tell the syntax highlighting engine that it
should skip any matches to tocComment that follow tocHeaderKeyword,
just as the skipwhite and skipempty pair tells it to skip whitespace
and empty lines (before and after any tocComments) before it tries to
match a tocCatalogNumber.

I have no idea how hard this would be to implement, but I'm thinking
that it can't be too difficult.  It should "only" be to add some
handling around the code that handles skipwhite/skipnl/skipempty to go
through a list of syntax groups and try to match them, highlighting
them, and then trying to highlight whatever is in nextgroup
afterwards.

I'm sure there are edge cases to consider, but I can't think that it
should be impossible.  I sadly don't have any understanding of the Vim
syntax highlighter, so someone with more knowledge will have to help
me out.

Comments?  Patches?  Complaints?

 nikolai

P.S.
Yes, I know that this can be solved by keeping track of the context by
adding a tocXComment for each and every :syntax ... X ... definition
(production) that keeps track of what the nextgroup of the production
in question was and adding the tocXComment production to that
productions nextgroup, but that doubles the number of productions and
makes it a lot harder to change it later on.

Here's an example of what that looks like for the grammar above:

syn keyword tocTodo
 \ contained
 \ TODO
 \ FIXME
 \ XXX
 \ NOTE

syn match   tocComment
 \ contains=tocTodo,@Spell
 \ '//.*$'

syn keyword tocHeaderKeyword
 \ nextgroup=
 \   tocCatalogNumberComment,
 \   tocCatalogNumber
 \ skipwhite
 \ skipempty
 \ CATALOG

syn match   tocCatalogNumberComment
 \ nextgroup=tocCatalogNumber
 \ skipwhite
 \ skipempty
 \ contains=tocTodo,@Spell
 \ contained
 \ '//.*$'

syn match   tocCatalogNumber
 \ contained
 \ '"\d\{13\}"'

Of course, all those additional groups can be automatically generated,
given a grammar, but again, it makes it harder to follow, harder to
change, and more memory-hungry than what a grammar using the (still
fictional) skip directive.
D.S.

Re: .xht and .xhtml file extensions for xhtml filetype detection

[Nikolai Weibull]

On 2/25/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


Christian J. Robinson wrote:

> On Sun, 25 Feb 2007, Sylvain Bertrand wrote:
>
> > Hi,
> > Is this possible to add .xht and .xhtml file extensions for xhtml
> > filetype detection?
>
> Yes, see ":help new-filetype".
>
> I think this should be added to the Vim distribution, and often wonder
> how it got left out of Vim7.

Apparently nobody noticed them.  Are *.xht and *.xhtml widely used for
XHTML?


I have never seen either.  .xht is perhaps even more of an abomination
than .htm is/was.

 nikolai

Re: Highlighting keywords from C libraries

[Nikolai Weibull]

On 2/21/07, Gautam Iyer <[EMAIL PROTECTED]> wrote:


Maybe a better solution would be the following: All symbols *currently*
highlighted in c.vim (and maybe some other common ones) should be moved
to "clibs/default.vim", and keywords from this file should be included
by default. Thus Vim users should see no change when they use the
supplied syntax files. And users who want more keywords to be
highlighted can control this from their vimrc.


Reasonable.


I personally find highlighting all keywords and constants from glibc and
Xlib very useful. And browsing through the source files I usually edit,
(and the Vim source) I found library calls very sparse, and the
highlighting supplied helpful. However I don't think my personal taste
should be forced on others, and hence I proposed the above modular
structure.


Yes, this is appreciated, because I personally think that having too
much highlighting goes against the purpose of highlighting - hey, the
default highlighting is to highlight everything in the same color
(black) and it works a lot better than having everything highlighted
as green, red, blue, orange, yellow, black, magenta, 

I'm not the right person to say anything here, because my syntax
definitions tend to highlight basically everything, but I've gone more
and more to defining syntaxes where people can highlight anything they
want, but keep the default set of highlights sparse.

 nikolai

Re: Vim 7 performance notes

[Nikolai Weibull]

On 2/8/07, Alexei Alexandrov <[EMAIL PROTECTED]> wrote:


> When testing it with VST it gave 3.4% speed improvements (the same
> metodology - 3 tests before and after, choose the best results).



Well, it's not that much but it's still positive result. :-)


Considering how intense these computations are and how often they are
performed (probably the most time-consuming part of Vim), any
improvement will help a lot.

It's nice to see people alongside Bram working on improving Vim.  Your
work is highly appreciated (as well ;-).

 nikolai

Re: Vim 7 performance notes

[Nikolai Weibull]

On 2/4/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:


Gnu malloc (glibc) is exceptionally fast, iirc.


Yes.  It's based on Doug Lea's malloc:

http://gee.cs.oswego.edu/dl/html/malloc.html

 nikolai

Re: Vim 8.0 Suggestion

[Nikolai Weibull]

On 1/31/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:
> On 1/30/07, Martin Krischik <[EMAIL PROTECTED]> wrote:
>> Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]:
>>
>> > - being able to open very large files quickly and
>> > without using too much memory. This could possibly
>> > be achieved by not loading the entire file immediately.
>> > File could be loaded lazily when required.
>>
>> The last (and only) editor to have that feature was The Atari Editor
>> which run
>> on 8 bit Atari computers. Was a full screen, modeing editor like vim as
>> well :-).
>
> How do you mean?  A lot of editors work like this.  The Atari Editor
> is hardly the first, or last, editor to work this way.  Sam works this
> way, Wily works this way, my editor ned works this way, James Brown's
> example editor "Neatpad" [1] works this way.
>
> It's usually down to the data structure used to manage buffer contents
> that defines whether it's possible to implement this feature or not.
> It's can also be down to support for various encodings that can
> require preprocessing of the files.
>
> I'm not sure to what degree Vim requires the whole file to be read
> before editing can commence.  I'm, however, sure that it can be made
> to load files without too much preprocessing, but I'm also pretty sure
> that it would require a lot of work and I don't think it's worth the
> kind of time that Bram would have to invest in such a feature.  Vim
> is, when it all comes down to it, designed to be a programmers editor,
> and that means that it'll mostly work with files smaller, mostly much
> smaller, than a megabyte, for which preprocessing works fine.
>
>  nikolai
>
> [1] http://www.catch22.net/
>

IIUC, Vim loads the whole file in memory before starting to edit. It might be
possible (but not necessarily worth the trouble on modern computers with their
large memory and their huge virtual-memory addressing ranges) to only keep
parts of the file in memory; but:


[a list of reasons why preprocessing may be a hidden cost of commands
being run on the file at around load-time anyway.]

That is all true, but under certain conditions it may still be the
case that pre-loading the whole file is unnecessary.


Loading the whole file in memory at the start allows
building an index (or something) which will later allow lightning-fast access
to any line given by number.


Considering that lightning travels at the speed of light, I'd say that
this is an overestimation of the line-lookup routines.


Vim is not only a programmer's editor (in the sense of an editor which can be
used to edit source programs: even Notepad can do that).


My statement was more about the size of a typical file loaded into Vim
than its specific uses.  I consider(ed) that to be obvious.

 nikolai

Re: Vim 8.0 Suggestion

[Nikolai Weibull]

On 1/30/07, Martin Krischik <[EMAIL PROTECTED]> wrote:

Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]:

> - being able to open very large files quickly and
> without using too much memory. This could possibly
> be achieved by not loading the entire file immediately.
> File could be loaded lazily when required.

The last (and only) editor to have that feature was The Atari Editor which run
on 8 bit Atari computers. Was a full screen, modeing editor like vim as
well :-).


How do you mean?  A lot of editors work like this.  The Atari Editor
is hardly the first, or last, editor to work this way.  Sam works this
way, Wily works this way, my editor ned works this way, James Brown's
example editor "Neatpad" [1] works this way.

It's usually down to the data structure used to manage buffer contents
that defines whether it's possible to implement this feature or not.
It's can also be down to support for various encodings that can
require preprocessing of the files.

I'm not sure to what degree Vim requires the whole file to be read
before editing can commence.  I'm, however, sure that it can be made
to load files without too much preprocessing, but I'm also pretty sure
that it would require a lot of work and I don't think it's worth the
kind of time that Bram would have to invest in such a feature.  Vim
is, when it all comes down to it, designed to be a programmers editor,
and that means that it'll mostly work with files smaller, mostly much
smaller, than a megabyte, for which preprocessing works fine.

 nikolai

 nikolai

[1] http://www.catch22.net/

Re: Me too vim8 idea: named marks, overlays à la emacs

[Nikolai Weibull]

On 1/30/07, Thomas <[EMAIL PROTECTED]> wrote:


As I recently (today) saw a few postings with vim8 suggestions, I would
like to propose emacs like overlays


I've already requested this and it's the only thing I'd require from
Vim8.  With overlays one wouldn't need the "hackish" :match command
and one could do funky stuff like forms and advanced abbreviations, a
la Textmate and Visual Studio.  It could be implemented using marks
that also keep track of the column in the line they adhere to, but
something lower-level would probably be way-more beneficial.

It does, however, require a lot of restructuring of the internal
buffer-handling, so I'm not hoping for much.

 nikolai

Re: for vim v8: how about keepundo ?

[Nikolai Weibull]

On 1/29/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:



> On 1/29/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:



> > The idea would be to leave the undo list alone, so that when the undo
> > table gets updated next it'll have a bigger change.



> What do you mean?  From the very short description it sounds like your
> describing :undojoin.



A "keepundo" would be more akin to the "keepjumps", "keepalt" style of
suppressing
some update for the command which follows.


But to be able to undo/redo, Vim has to know about what changes have
taken place, otherwise it can't guarantee that undo/redo will work
correctly.

 nikolai

Re: for vim v8: how about keepundo ?

[Nikolai Weibull]

On 1/29/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:

The idea would be to leave the undo list alone, so that when the undo
table gets updated next it'll have a bigger change.


What do you mean?  From the very short description it sounds like your
describing :undojoin.

 nikolai

Re: Suggestion: numbers for completion menu?

[Nikolai Weibull]

On 1/23/07, Marc Weber <[EMAIL PROTECTED]> wrote:

It would be convinient to get an item from the completion menu faster
than  .. or typing more characters.

What do you think of prepending each item with a number and add a
key-mapping
 to get the idxth item?
so 4 would select the 4th.

Would it be convinient to add another mapping space for completions?
mnoremap 2 2 ?
m = omni completion _m_enu ?

Or is there another easy way to achieve this ?


I've already mentioned this here:

http://thread.gmane.org/gmane.editors.vim.devel/15344/focus=15344

Here's the mappings:

for digit in [1, 2, 3, 4, 5, 6, 8, 9]
 execute 'inoremap  ' . digit . ' =pumvisible() ? "' .
   \ repeat('\C-N>', digit) . '" : "' . digit . '"'
endfor

However, what I also mention there is that the completion menu
flickers like mad if you use this.  It shouldn't be redrawn quite as
often as it currently is, and not as much of it either.

 nikolai

Re: BOF Vim 8 - Suggestions

[Nikolai Weibull]

On 1/21/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:

On 1/21/07, Marc Weber <[EMAIL PROTECTED]> wrote:

> My comments on nohl:
> nnoremap  :nohl  echo ""
> should clear message line and remove highlighting

nnoremap  :silent! nohighlight


Hm, sorry, my bad, the 'echo ""' is what one wants.

 nikolai

Re: BOF Vim 8 - Suggestions

[Nikolai Weibull]

On 1/21/07, Marc Weber <[EMAIL PROTECTED]> wrote:


My comments on nohl:
nnoremap  :nohl  echo ""
should clear message line and remove highlighting


nnoremap  :silent! nohighlight

?

 nikolai

Re: [BUG] Conversion error on write when 'autowriteall' is set causes infinite recursion

[Nikolai Weibull]

On 1/21/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:

> Test case:
>
> vim -c 'e ++enc=latin1 a.test | exec "normal! i\u2026" | set
> autowriteall | q'

And make sure 'encoding' is "utf-8".


Ah, sorry.  Forgot about that.


Yes, I can reproduce it.  One more
item for the todo list...


Sorry…

 nikolai

[BUG] Conversion error on write when 'autowriteall' is set causes infinite recursion

[Nikolai Weibull]

Test case:

vim -c 'e ++enc=latin1 a.test | exec "normal! i\u2026" | set
autowriteall | q'

 nikolai

Re: BOF Vim 8 - EncryptLine

[Nikolai Weibull]

On 1/19/07, Matthew Winn <[EMAIL PROTECTED]> wrote:


Gung'f ab tbbq. Erny areqf pna ernq ebg13 grkg jvgubhg hfvat fbsgjner.


Hm.  I don't understand.  Is that some sort of encryption you're using?

 nikolai

P.S.
Sorry, I couldn't keep from joking around a bit.
D.S.

Re: BOF Vim 8 - EncryptLine

[Nikolai Weibull]

On 1/19/07, John Beckett <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:
> 2.  Don't write down passwords at all - use phrases that you remember
> instead
> 3.  Don't write down passwords where other people might walk by and
> see what you're typing

Let's not start a religious war, but FWIW many authorities have changed
their mind and no longer advocate the "don't write down a password" advice.

In particular, any network admin simply has to record passwords and other
sensitive information - you can't reliably remember more than two or three
passwords, particularly when you're not using them often.


I don't understand what you're trying to say in the first part of your
sentence.  For the second part, see below.


There are many "password safe" utilities for this, but I like a simple text
file with the secrets encrypted, yet easily viewable (without changing the
file).


Which defeats the whole point of having multiple passwords, as if
someone figures out the master password then the other passwords will
also be available.  So it's better to use one good password/passphrase
and stick with it.

 nikolai

Re: Odp: BOF Vim 8 - Suggestions

[Nikolai Weibull]

On 1/19/07, John Beckett <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:
> Perhaps a better way is to leave 'hlsearch' off and provide a binding
> that toggles it on and off.  That way you don't get the "distracting"
> highlighting until you actually request it.

OK but I imagine most people would like hlsearch on while they
are searching (I certainly do).


Well, hlsearch only kicks in /after/ you've completed your search,
whether you're using 'incsearch' or not.  I once thought this was a
nice feature, but I've realized that I rarely need to have other
matches highlighted.  I mean, either I've found what I want using
'incsearch', or  I have failed to find the text location that I
wanted, and highlighting the other matches won't really help much.
Narrowing your search using 'incsearch' is often a lot quicker than
doing a quick search and pressing 'n' a bunch of times to get to the
right match.


IMHO it is quite idiotic that Vim has the really great feature of
globally highlighting searches, but the user has to learn how to
map keys to make it work in a sensible way. I suppose there
are people who don't mind the distracting highlights once
they've finished looking at them, but I'm pretty confident that
most people here have a mapping to deal with the situation.


Well then, how should it work?

One solution would be to disable it as soon as the mode changes.  That
way it's on while you're looking for matches and is turned of as soon
as you start making changes.

 nikolai

Re: Odp: BOF Vim 8 - Suggestions

[Nikolai Weibull]

On 1/19/07, John Beckett <[EMAIL PROTECTED]> wrote:


One problem was how search highlighting is persistent (which is
great), but it is very distracting to some people when you want to
turn your attention to another issue. Telling him how to map a key
to do ':nohl' is just unnecessary mumbo jumbo.


Which, presumably, is why 'hlsearch' is off by default.  If you don't
want to tell him about :nohl, then it doesn't make sense to enable
'hlsearch'.

Perhaps a better way is to leave 'hlsearch' off and provide a binding
that toggles it on and off.  That way you don't get the "distracting"
highlighting until you actually request it.

Actually, I'm going to try that out, because I find myself always
following a search command  with a ',h', which is what I have :nohl
bound to.

 nikolai

Re: BOF Vim 8 - Suggestions

[Nikolai Weibull]

On 1/18/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


I do agree that good defaults are important.  But backwards
compatibility is also important.  It's not always easy to make a choice.


I think some things would be really sane to have on by default, such
as :syntax on, but at the same time it's a whole hell of a lot easier
to change the defaults by providing a .vimrc that gets sourced if the
user doesn't have a .vimrc than change the defaults in the source (as
that affects everyone).

 nikolai

Re: BOF Vim 8 - EncryptLine

[Nikolai Weibull]

On 1/18/07, Robert Lee <[EMAIL PROTECTED]> wrote:


Also, executing such a command on a password while
someone is watching only brings attention to the password, which appears
in clear text until the command sequence has been completed (where-as
folding can be applied automatically when the file is opened, and each
fold remains closed until explicitly opened).


Seriously, where the hell are you sitting writing down passwords where
people walk by you and drop down over your shoulder to sneak a peek?

A couple of suggestions:

1.  Don't write down passwords in a file unencrypted (because what
you're suggesting is that encryption would only be necessary during
display, i.e, when the file is loaded)
2.  Don't write down passwords at all - use phrases that you remember instead
3.  Don't write down passwords where other people might walk by and
see what you're typing

 nikolai

Re: BOF Vim 8 - EncryptLine

[Nikolai Weibull]

On 1/18/07, John Beckett <[EMAIL PROTECTED]> wrote:

Suggested new feature:
Make an easy way to encrypt a secret within a line.


[Really complex scheme to implement this.]

Why is it not enough to simply implement a function that
encrypts/decrypts a range of text, much like g? ROT13s a range of
text?

 nikolai

Re: Konsole: lost focus of window or tab

[Nikolai Weibull]

On 1/17/07, Matthew Woehlke <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:
> On 1/17/07, Matthew Woehlke wrote:
>> Mikolaj Machowski wrote:
>> > Is it possible to recognize if window or tab of Konsole lost focus
>> > through termcap/terminfo sequence?
>> >
>> > Or is it at least possible with dcop or any other way?
>> >
>> > I am investigating ways to support Vim FocusGain/FocusLost autoevents.
>
>> Long answer (short answer below):
>
> [snip really long answer]



> Sorry, but I just had to ask, what exactly are you responding to?  I
> saw no suggestion of using DCOP in the vim-dev thread.  Did someone on
> the kde list suggest it?  Just curious on what they were suggesting.



Mikolaj Machowski though of it (see his original e-mail to kde-devel,
quoted above).


Ouch, missed that part.  I just figured you quoted his mail to this
list.  Sorry, I got confused.

 nikolai

Re: Konsole: lost focus of window or tab

[Nikolai Weibull]

On 1/17/07, Matthew Woehlke <[EMAIL PROTECTED]> wrote:


Mikolaj Machowski wrote:



> Is it possible to recognize if window or tab of Konsole lost focus
> through termcap/terminfo sequence?
>
> Or is it at least possible with dcop or any other way?
>
> I am investigating ways to support Vim FocusGain/FocusLost autoevents.



Long answer (short answer below):


[A really long answer]

Hi!

Sorry, but I just had to ask, what exactly are you responding to?  I
saw no suggestion of using DCOP in the vim-dev thread.  Did someone on
the kde list suggest it?  Just curious on what they were suggesting.

Thanks!

 nikolai

Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)

[Nikolai Weibull]

On 1/8/07, Trenton Schulz <[EMAIL PROTECTED]> wrote:


On Jan 8, 2007, at 12:39 PM, Martin Stubenschrott wrote:



> Would you also vote for changing the console style dialogs? I mean,
> console users are normally used to press y or n, when answering these
> kind of questions.

Well, don't you do that by typing :wq/:wq! or ZZ or whatever? Most of
the other "dialogs" on the console version don't ask yes/no questions
as far as I have encountered. I think it is a non-issue for the
console version...


% vim
 :set confirm
 iHello, Vim!
 :q
 Save changes to "Untitled"?
 [Y]es, (N)o, (C)ancel:

Sure, [S]ave, (D)iscard, (C)ancel would work - and is better, as it
better describes what would happen - but I'd venture so far as to say
that 'Y', 'N' are so deeply engrained in peoples minds by now that it
would be very irritating to have to hit 'S' or 'D' instead.  I know I
would be annoyed.  Still, perhaps it makes sense to change these as
well. And one could allow the user to type 'Y' or 'N' with the old
behavior as well.

 nikolai

Re: [Feature Request] Vim should respond to WM_PASTE

[Nikolai Weibull]

On 1/7/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:

> It seems GVim doesn't respond to the WM_PASTE message on Windows.  It
> would be really sweet if it did.  I sadly have no intention of
> implementing this myself, but would appreciate it if this could be
> added to the TODO.

Who would send a WM_PASTE message to Vim?


I would.  I have a Autohotkey script that emulates Vim's digraph
support so that I can type ^K'6 to get a LEFT SINGLE QUOTATION MARK.
Sadly, the best way to send Unicode characters to Windows applications
through a Autohotkey script is through the use of the clipboard (might
not work otherwise).  Thus, the character is stored in the clipboard
and then a PostMessage of WM_PASTE is sent to the active application.
However, if the application doesn't respond to WM_PASTE, this won't
work.

(I'll gladly post the script if anyone wants it, by they way.)

 nikolai

Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)

[Nikolai Weibull]

On 1/7/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:



> On 1/7/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:



> > > Also attached is a patch to disable guioptions="t" (tearoff menus) when
> > > compiled with FEAT_GUI_GNOME, also for desktop consistency.



> > Hey, wait! Even gvim for Windows has tearoff menus, which is a great
> > feature,
> > available in no other Windows programs AFAIK. Why disable it in Gnome
> > versions
> > on the pretext that other Gnome programs don't have it? If you don't
> > like the
> > availability of tearoff menus, include ":set guioptions-=t" in your
> > vimrc, but
> > don't deprive me of this feature. And don't tell me that I can just
> > compile
> > "with GTK but without Gnome": I want a Gnome gvim for other reasons,
> > such as
> > the ability to save its session when the KDE window manager closes.



> Eh, you who want tearoff menus (perhaps the most stupid GUI design
> choice ever) can include ":set guioptions+=t" in your vimrc.  Not that
> I'd include 'm' in my guioptions either.  Not that I'd run the gui for
> that matter.



At the moment I can. If the OP's patch makes it to the "official"
distributions (Bram forbid!) it won't work anymore


(Seriously, does it really make sense to write "OP", which I assume
means "Original Poster", instead of "Ed"?  We're not in the
military...we don't need acronyms and abbreviations for everything.
It's not cool and it's not helpful.  It just makes reading what you've
written more difficult.  I'm not trying to police this mailing list,
but come on, what's the point?  And if I ever see something like YMMV,
IANAL (hey, if you're not a lawyer, then why are you giving legal
advice in the first place?), or IAHFRTOUAAATEM (I Am , However, A
Fucking Retard That Only Uses Acronyms And Abbreviations To Express
Myself) on this list, I'll seriously consider unsubscribing.)

All his patch does is remove 't' from the default value of
'guioptions' for UNIX GUI builds that aren't Mac OS builds that have
GNOME support enabled.  It's quite clear if you look at the diff.


> > This sounds to me like "I don't want it, therefore you cannot have
> > it", a form
> > of totalitarianism completely out of place in Vim.



> Last time I checked, we had a benevolent dictator for a ruler that has
> ruled to that effect, many times in the past.



"Benevolent dictator" is a contradiction in terms.


And that's the joke.  (And if Bram ever goes off the deep end, we'll
always have the source - although I don't see who'd pick it up.)


Removing features sounds extremely un-Vim-like to me.


Again, nothing is being removed.

(Coincidentally, I consider not adding features extremely Vim-like.)

 nikolai

Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)

[Nikolai Weibull]

On 1/7/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:


> Also attached is a patch to disable guioptions="t" (tearoff menus) when
> compiled with FEAT_GUI_GNOME, also for desktop consistency.



Hey, wait! Even gvim for Windows has tearoff menus, which is a great feature,
available in no other Windows programs AFAIK. Why disable it in Gnome versions
on the pretext that other Gnome programs don't have it? If you don't like the
availability of tearoff menus, include ":set guioptions-=t" in your vimrc, but
don't deprive me of this feature. And don't tell me that I can just compile
"with GTK but without Gnome": I want a Gnome gvim for other reasons, such as
the ability to save its session when the KDE window manager closes.


Eh, you who want tearoff menus (perhaps the most stupid GUI design
choice ever) can include ":set guioptions+=t" in your vimrc.  Not that
I'd include 'm' in my guioptions either.  Not that I'd run the gui for
that matter.


This sounds to me like "I don't want it, therefore you cannot have it", a form
of totalitarianism completely out of place in Vim.


Last time I checked, we had a benevolent dictator for a ruler that has
ruled to that effect, many times in the past.

 nikolai

Re: Suggestion for a change to compiler/gcc.vim

[Nikolai Weibull]

On 8/1/06, Nicolas Schodet <[EMAIL PROTECTED]> wrote:

* Nikolai Weibull <[EMAIL PROTECTED]> [060722 12:08]:
> I am the maintainer of compiler/gcc.vim and I would like to propose
> the following change to its errorformat:

> @@ -20,7 +20,8 @@ setlocal errorformat=
>   \\"%f\"\\,\ line\ %l%*\\D%c%*[^\ ]\ %m,
>   \%D%*\\a[%*\\d]:\ Entering\ directory\ `%f',
>   \%X%*\\a[%*\\d]:\ Leaving\ directory\ `%f',
> -  \%DMaking\ %*\\a\ in\ %f
> +  \%DMaking\ %*\\a\ in\ %f,
> +  \%-G%.%#
>
> let &cpo = s:cpo_save
> unlet s:cpo_save

> The reason for this change is that I find it tiresome that whenever a
> successful build it built, I have to press enter twice to first get
> through the "shell output is finished, please hit Enter" prompt and
> then "Hi, I'm gcc command-line number one that successfully compiled
> file so and so, and hey, there are 18 more of these commands waiting
> for you to look through, so please begin by hitting Enter".
> So the addition of %-G%.%# to exclude anything but the defined formats
> from the listing saves us the trouble of seeing useless compiler
> command-lines in the list of changes.
> However, this is a rather drastic measure, and may cause messages that
> people rely on to go missing.  If so, then this patch is perhaps not
> for public consumption.  We do have the chance to add these messages
> to the errorformat, however, so if someone has any suggestions, please
> do pass them on.
> Any comments?

This could be a quite dangerous measure as any unrecognised line will be
totally ignored. Moreover, many Makefiles include other commands, and
their output should generally not be lost.


Precisely the point.  If Vim can't determine how the output of a
command should be interpreted it should be ignored.  It's as simple as
that.  If you have some special needs, it really should be treated
separately.


If you add this feature, I propose not to make it the default. This
feature is not only useful with gcc, so the variable used to activate it
could have a general name and be used in several compiler files.


True, that could be useful, but it should be on by default.


By the way, here is two lines coming from the default errorformat
option:

  \%D%*\\a:\ Entering\ directory\ `%f',
  \%X%*\\a:\ Leaving\ directory\ `%f',

They are useful when using the -C option from the vim command line.
What do you think of adding them?


OK, I'll add them.

 nikolai

Re: [Feature Request] Vim should respond to WM_PASTE

[Nikolai Weibull]

On 12/19/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:



> On 12/19/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:



> > Nikolai Weibull wrote:



> > > It seems GVim doesn't respond to the WM_PASTE message on Windows.  It
> > > would be really sweet if it did.  I sadly have no intention of
> > > implementing this myself, but would appreciate it if this could be
> > > added to the TODO.



Try using the client-server feature instead.

See
:help remote.txt
:vimgrep /\/g src/*.[ch]


I don't see how that would solve anything.  I don't want to send a
Vim-specific message.  I want to send a "Microsoft Windows"-specific
message, the reason being that I don't want to have to treat Vim
separately in the "application" I'm writing.

 nikolai

Re: [Feature Request] Vim should respond to WM_PASTE

[Nikolai Weibull]

On 12/19/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:


Nikolai Weibull wrote:



> It seems GVim doesn't respond to the WM_PASTE message on Windows.  It
> would be really sweet if it did.  I sadly have no intention of
> implementing this myself, but would appreciate it if this could be
> added to the TODO.



Doesn't it already?


No; that's why I'm posting this feature request.


Which actions do you perform to trigger that message?


PostMessage [1]


AFAIK, dragging with the mouse, or clicking Edit => Paste, both trigger an
action in (g)vim.


Yes, but as you may know, menus are much like mappings, and this
particular one executes "+gP in normal mode.

 nikolai

[1] http://www.google.com/search?q=PostMessage

[Feature Request] Vim should respond to WM_PASTE

[Nikolai Weibull]

It seems GVim doesn't respond to the WM_PASTE message on Windows.  It
would be really sweet if it did.  I sadly have no intention of
implementing this myself, but would appreciate it if this could be
added to the TODO.

Thanks.

 nikolai

Re: some ideas

[Nikolai Weibull]

On 12/12/06, Aaron Griffin <[EMAIL PROTECTED]> wrote:

On 12/11/06, Rodolfo Borges <[EMAIL PROTECTED]> wrote:
> (1)
> When tab-completing on Vim :cmdline, start with the dir of the current
> file being edited, instead of the $PWD (use ./ for that).

:h autochdir


And if you don't like how 'autochdir' works, here's a set of mappings
you may want to consider:

nnoremap c :cd %:p:h:pwd
nnoremap C :lcd %:p:h:pwd
nnoremap e :e =expand('%:p:h')/
nnoremap E :e 

 nikolai

Re: problem with vim.sf.net

[Nikolai Weibull]

On 12/7/06, Eggum, DavidX S <[EMAIL PROTECTED]> wrote:

Confirmed, I see it too...


And I can confirm receiving your confirmation.

 nikolai

Re: enhancing hlsearch

[Nikolai Weibull]

On 12/7/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote:

On 12/6/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

> I think it is doable, but it's not my province really. Some other Vim
> old-timers are much more versed than I in the creation of that kind of
> "self-undoing" mappings.

It can probably be simplified by mapping  in command mode and
check if getcmdtype() is '/' or '?' and, if so, call :match as
appropriate.


Hm, you of course need to know how you got /into/ search mode, so that
you only do this at the appropriate times.  Setting a variable and
checking for it would work, but you have to make sure to unset it if
the command line is abandoned as well.  We need
CmdLineEnter/CmdLineLeave and v:cmdexecuted or some such, so that we
can tell if the line was executed or not.  Or perhaps even better:
CmdLineEnter/CmdLineLeave/CmdLineExecutePre/CmdLineExecutePost.  With
the *Pre autocmd one can perhaps change the command line in some way
before executing it.  With *Post one can do stuff after it, like
:matching.  *Leave would be called when it is abandoned, although
perhaps the name suggests other cases as well?

Anyway, good night.

 nikolai

Re: enhancing hlsearch

[Nikolai Weibull]

On 12/6/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:


I think it is doable, but it's not my province really. Some other Vim
old-timers are much more versed than I in the creation of that kind of
"self-undoing" mappings.


It can probably be simplified by mapping  in command mode and
check if getcmdtype() is '/' or '?' and, if so, call :match as
appropriate.

However, there's no good way of doing this type of highlighting while
in 'incsearch' mode (i.e., while typing the pattern).

Anyway, here's something I cooked up for you 'incsearch' users that
actually thought this was sort of a neat idea, i.e., being able to
quickly toggle between the word anywhere in the buffer, the complete
word, and the case insensitive word.  It definitely needs work to deal
with anything but trivial patterns, e.g., only wrap the word under the
cursor, but you probably only want to do this for simple, word-type
patterns.

cmap  etoggle_word_style()

let s:word_types = [
 \ [ '^\\<\|\\>$', "", 'g', '\c', "" ],
 \ [ '^\\c', "", "", "", "" ],
 \ [ '^', "", "", '\<', '\>' ]
 \ ]

function! s:toggle_word_style()
 let line = getcmdline()
 let type = getcmdtype()

 if type != '/' && type != '?'
   return line
 endif

 for word_type in s:word_types
   if line =~ word_type[0]
 let line = word_type[3] .
  \ substitute(line, word_type[0], word_type[1], word_type[2]) .
  \ word_type[4]
 call setcmdpos(len(line) + 1)
 return line
   endif
 endfor

 return line
endfunction

Actually sort of neat, although it's not what Mohsin wants.

 nikolai

Re: Debugging errorformat strings

[Nikolai Weibull]

On 11/30/06, Hugh Sasse <[EMAIL PROTECTED]> wrote:


I was definitely getting this and it was pasted.  Pulling the old versions
of the generator script out of RCS I cannot regenerate this message.
Using old versions of the makefile doesn't help restore this.


Yeah, I remember getting these messages as well, but since the only
case I could think of where this would happen is of the type you gave
an example of I'm guessing that they changed the error message in a
very recent version (4.1.1) and I'd prefer not complicating the
errorformat unnecessarily to conform to old versions of gcc.  But
perhaps I'm wrong in my reasoning?  Anyway, I'll hold off on this
until a working test-case can be produced.

 nikolai

Re: Debugging errorformat strings

[Nikolai Weibull]

On 11/30/06, Hugh Sasse <[EMAIL PROTECTED]> wrote:

On Wed, 29 Nov 2006, Nikolai Weibull wrote:

> On 11/29/06, Hugh Sasse <[EMAIL PROTECTED]> wrote:
> > This was originally posted to vim@vim.org but I've not
> > had a reply.  Maybe it's better posted here, anyway.  This
> > is the concise form of the message.  Longer versions are
> > in the archives, but I'll explain more if needed.
>
> Sorry about that.  I don't read vim@vim.org because it's
> signal-to-noise ratio is just terrible.

That's understandable.  I'm the same with Ruby-Talk, but because there's
too much signal to read.


Sadly that's what happened to me too.


> Also, which version of gcc are you using.  I suspect that they changed
gcc (GCC) 4.1.0

> the error message in the 4.X series, because I'm not getting this

I think I saw it before.


Yes, I recognize that message, but I'm not getting that anymore.  With my gcc:

% gcc --version | head -n 1
gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)

I get

a.c:11: error: redefinition of 'minimal_function'
a.c:6: error: previous definition of 'minimal_function' was here

which works fine with the old format, as the errors are completely
separate (in the output that is).

How are you calling gcc?  I've done this with plain "gcc " and
"gcc -Wall " and both give me the same result for this error.

 nikolai

Re: Debugging errorformat strings

[Nikolai Weibull]

On 11/29/06, Hugh Sasse <[EMAIL PROTECTED]> wrote:

This was originally posted to vim@vim.org but I've not
had a reply.  Maybe it's better posted here, anyway.  This
is the concise form of the message.  Longer versions are
in the archives, but I'll explain more if needed.


Sorry about that.  I don't read vim@vim.org because it's
signal-to-noise ratio is just terrible.


--- /usr/local/share/vim/vim70/compiler/gcc.vim 2006-07-19 18:11:22.117752000 
+0100
+++ /home/hgs/.vim/compiler/gcc.vim 2006-11-22 18:33:39.269332000 +
@@ -16,6 +16,8 @@
   \\"%f\"%*\\D%l:\ %m,
   \%-G%f:%l:\ %trror:\ (Each\ undeclared\ identifier\ is\ reported\ only\ 
once,
   \%-G%f:%l:\ %trror:\ for\ each\ function\ it\ appears\ in.),
+  \%E%f:%l:\ multiple\ definitions\ of\ %m,
+  \%Z%*\\s:%f:%l:\ first\ defined\ here,
   \%f:%l:\ %m,
   \\"%f\"\\,\ line\ %l%*\\D%c%*[^\ ]\ %m,
   \%D%*\\a[%*\\d]:\ Entering\ directory\ `%f',


Can you please give an example of when this occurs?

Also, which version of gcc are you using.  I suspect that they changed
the error message in the 4.X series, because I'm not getting this
message when I think I should be getting it.

 nikolai

Re: (patch), global var that indicates default search direction

[Nikolai Weibull]

On 11/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


For the name: How about "v:searchforward"?


Sounds reasonable.

 nikolai

Re: buffer list count

[Nikolai Weibull]

On 11/13/06, Eggum, DavidX S <[EMAIL PROTECTED]> wrote:


let s:prev_last = 0
let s:prev_count = 0
function! GetBufCount()
   let last = bufnr('$')
   if last != s:prev_last


Argh...of course...that's the solution to my buffer-tracking problems
as well.  I'm writing a high-level object-oriented interface to Vim
scripting and have been fretting over how to keep track of buffers
without doing too much work, creating too many objects, without
loosing any data (e.g., when 'eventignore' has been set).  Checking
that we haven't missed a buffer being added whenever we enter a
function in the Buffers object is a good solution.

Thanks.

 nikolai

Re: RFE: :amap and :menu

[Nikolai Weibull]

On 11/9/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


buffer-local menus are complicated.  What about menus that are not for
the current buffer, hide them?  Would make jumping between buffers very
slow.


Emacs does this, I believe.  I don't think there's a noticable lag.
Mind you, I don't use menus and I don't care.  Just thought that I'd
mention that Emacs seems to manage this.

 nikolai

Re: Is always guaranteed to be the same as and is always guaranteed to be unique?

[Nikolai Weibull]

On 11/8/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:



> Ah, sorry.  My question was incomplete.  Is  guaranteed to be
> equal to  for all commands where a file isn't being
> read/sourced?  Specifically, do they refer to the same buffer for
> BufDelete?  The BufDelete documentation suggests using , but
> I'd much prefer using the buffer number.



I don't know; and since I don't know, I wouldn't bet on it one way or another.


Hehe :-)

 nikolai

Re: Is always guaranteed to be the same as and is always guaranteed to be unique?

[Nikolai Weibull]

On 11/8/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Nikolai Weibull wrote:
> Is  always guaranteed to be the same as  and is 
> always guaranteed to be unique?
>
>  nikolai
>

1. No. From ":help ":
when executing autocommands, is replaced with the file name
   for a file read or write
 when executing autocommands, is replaced with the currently
   effective buffer number (for ":r file" and ":so file" it is
   the current buffer, the file being read/sourced is not in a
   buffer).

IOW, for :read and :source,  is the current buffer and  is not.


Ah, sorry.  My question was incomplete.  Is  guaranteed to be
equal to  for all commands where a file isn't being
read/sourced?  Specifically, do they refer to the same buffer for
BufDelete?  The BufDelete documentation suggests using , but
I'd much prefer using the buffer number.


2. What do you mean, unique? A file can be opened in several windows, but the
buffer will normally be the same (I'm not sure about the case when a file is
opened by different names, owing to soft -- or, worse, hard -- links).


Forget it.  Turns out that  expands to the full path, so yes,
it's unique.  The BufDelete  documentation confused me because it
sounds like it's talking about the buffer name, not the buffer's
file's path.

Thanks.

 nikolai

Is always guaranteed to be the same as and is always guaranteed to be unique?

[Nikolai Weibull]

Is  always guaranteed to be the same as  and is 
always guaranteed to be unique?

 nikolai