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. > - 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. > - 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. > and file pattern & text pattern has different format. So? That’s to be expected. > - 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. > 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. >> 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. > 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. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
