Thank you for your meticulous reply :-)

On 7月17日, 下午4时39分, Nikolai Weibull <n...@bitwi.se> wrote:
> On Fri, Jul 17, 2009 at 01:00, StarWing<weasley...@sina.com> wrote:
> > On 7月17日, 上午5时17分, Nikolai Weibull <n...@bitwi.se> wrote:
> >> Now you’re losing me again.  What does this matter?  Copy-on-write?
> >> It seems that you’ve just read a book on operating-system design or
> >> something and want to, ahem, rewrite Emacs.
> > OK. it's very important, for me. yes. I really just read a book on
> > operating system and found that I can use these tech to improve Vim.
>
> I don’t see how.
>
> > IMHO, Vim has several issues:
> >  - it has separate Eval system and Inner implement. so you can't
> >    simply use script to hand all state of Vim.
>
> It’s not as flexible as elisp, no.
>

But it can be.

> >  - it has memory leaks ( a dozen of patch are made for it), and it
> >    waste of memory (copy lines for undo, for submatch(), etc).
>
> This I have a hard time believing.
>
> >  - it isn't thread-safe. so you can't load service while loading
> >    file.
>
> True, but, as already stated, fixing that is going to basically
> require a complete overhaul of the Vim source code.
>

that's really a long boring job, is it?


> >  - it has a weak language, can't handle all functional of Vim, and
> >    slow.
>
> True, but this isn’t anything new and I don’t see how what you’re
> proposing (still unclear on what it is that you’re actually proposing,
> though) solves that.
>
> >  - it had s weak reguiar expression module, just can handle context
> >    free pattern.
>
> Um, what?
>
> The problem with Vim’s regular expression implementation is that it
> uses backtracking to match.  This is more or less required, as Vim’s
> ”regular expressions” include backreferences, which, as it turns out,
> aren’t regular at all.
>
> Regular expressions can’t match context-free grammars.  That’s
> basically the whole point of regular expressions.  NFAs, TFAs, and
> regular expressions are deeply intertwined, just as context-free
> grammars and NDPAs are deeply intertwined.  Irregular expressions are
> not as clearcut, but they certainly can’t match context-free grammars.
>

But Why you can use perl patterns to match paren? because it support
recursive in pattern, and you can integration codes into patterns. but
that's not necessary. just a parser can do recursive thing. (or
current :syntax command, but It can't do anything other than
highlight)

can you write a pattern to replaced foo to bar in code, but not in
string and comment? that's useful, but Vim pattern doesn't support
that :-( maybe makes user can get current syntax state easily is
better.

> > and file pattern & text pattern has different format.
>
> So?  That’s to be expected.

That makes code complex, maybe a interchangeable flexable regex engine
is better?

> >  - it writes repeat code for same function. in writefile/readfile,
> >    the IO is just rewrite, so we can't hand file encoding, file
> >    information, etc. with it. there are amount of switch block in
> >    code, they just for the same purpose. just use a thread-safe mode
> >    invoke function to replace them will offer flexable and space.
>
> I don’t see how lack of reuse, which does exist, yes, has much to do
> with being thread safe.

Maybe Vim can make a hal to include all lower level function :-)

> > then, you see, the regex module is the part of service. I prepare made
> > it more powerful, complete, just like perl regex (can you write a Vim
> > regex to handle paren-match?).
>
> Yeah, that’s not the problem.  Again, don’t use regular expressions to
> match nested structures.

But how? I think sometimes it's necessary. (just the example above).

> >> By the way, I still haven’t written the article I was going to write
> >> on this, but Vim’s current :syntax command is powerful enough to parse
> >> LALR(1) grammars, and perhaps others as well, in a recursive descent
> >> fashion.
> > can you use :syntax to write a real "syntax" highlight script? in:
> > (foo)*bar
> > can you make foo highlight as a type when there is:
>
> > typedef int foo;
> > before, and highlight foo as a variable when I delete the typedef
> > line?
>
> No, but that’s because the C grammar isn’t context-free.  And, by the
> way, syntax is not the same thing as semantics, which is what you’re
> looking for.
>

Yes, I said semantics, i forgot that word :-\
Is it important in your mind? I think it's funny and powerful.

> > Vim syntax command is great, but it can't handle informations in
> > parsing. one reason is VimL is so slow, another reason is it can't
> > avoid parsing error.
>
> :syntax being slow or not has nothing to do with VimL being slow.


:function is slow, either. it just copy lines, do parse time and time.
maybe a bytecode compiler will make it better. but before that we
should package the commands first, that's the original idea I have.
and the idea growes as now.

we discuss the possible and impossible of Vim. but I think we should
make things easy to get more possible and less impossible. A middle
level language is needed, in my mind (just like elisp in emacs)

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Raspunde prin e-mail lui