what about redesigning things with c++, with powerful design patterns, eventually avoiding STL ? :)( I am smiling, as not everything should be taken to seriously :) )
Actually it is not necessary to redesign it with c++, would be enough to try to redesign it with having more in mind the concept of interfaces. About states: I would create even more states. One should design o mode to enumerate states, and their commands and key bindings. 2009/7/15 StarWing <[email protected]> > > > > On 7月15日, 下午8时13分, mobi phil <[email protected]> wrote: > > Heyy!!!!!! > > I am so happy to know there are people who think like that. I would be > happy > > to know > > that Bram Moolenar does not feel offended my such ideas. > > The powerful patterns that are > > in vim were gathered through years, but we should make the process easier > to > > let it evolve > > > >> first of all, Vim is great, but not prefect. but it really need keep > >> its compatible with old version and the old vi. but we can do > >> something like Vim++ or something else. I have some idea. > > > > why would one have vi compatibility issue? most of the power is from > > compatibility with vi, or? > > > > vi compatibility is the main design rule of Vim. but not our Vim++, I > mean, we only make Vim++ has more effective, more flexible, more > powerful, that's all rule. not full vi-compatibility. some of Vi > design > are genius, but other of it can fit our modern world, is it? > > > >> - New One is command-driven, not mode-driven. operator "i" is just > >> make us in a temporary state of Vim. We should decrease the amount > >> of this state. > > > > I agree the command driven, however the states are the same time power > > of vim, compared with a control-alt hell in emacs, what do you mean > > decrease the amount of this state? > > > >> we can merge cmdline mode and insert mode into one, and add a list > >> mode, > > > > nice to notice you see the power of the lists... but what do you mean > > merge cmdline and insert mode, how would you be able to write commands > > in insert mode... or? > > en, I mean, we don't need a large amount of states has similar > interface but not in full accord. e.g. cmdline mode and insert mode. I > like there are three main mode of Vim: normal mode, insert mode and > select mode. cmdline looks similar like insert mode, but it has a set > of > different interface between insert mode. I mean, when need insert > text, > we use a same interface (hotkey, operator, format, etc.). > > and, in this way, we can drop away ex mode. just make a scratch buffer > like emacs, after input script or command, it executes at once. > > >> and delete the quick-fix and locate window, use list mode to replace > >> them. > > > > yep.. that was my argument when talking about search is lists. Things > > like locate, quick-fix are rather temporary entities, however > > sometimes not bad to have them in front, when you want to see a window > > with long result of grep etc. I think the pattern should be transform > > any kind of list into list window if necessary. > > I think there are a way to contain read-only temporary text. I > disagree > emacs's way. a buffer is a waste of space here. I mean, we can design > a > read-only mini-buffer (and a set of operation of it) as a "list mode", > it can hold on, can disappear when we press key, or any other > possible. > just for convenient. we can select in it, can yank, but we can't > change > text in it. > > > >> - it contains a parser like yacc, we can parsed program and get some > >> information when get syntax-highlight. that means, we can make > > > > though you cannot parse c program with yacc :), fast parsers use > > heuristics, for highlighting you need fast parsers, and here vim > > probably behaves enough well > > > no, I don't like Vim's highlight method. YACC can do it. we can write > simple rule of grammar, and parse it. when we do it, we collect > informations, add attributes to text, and do something other (e.g. > collect words and names for complete.). we can get a fast, > syntax-specified complete. (because we only parse text a time and get > all > informations we need.). trust me, we can make highlight more useful > and > fast. > > e.g. we have a file-type contain "a=b" lines, then we can write below > lines: (pseudo-code:) > > syn rule text : line '\n' text | '' > syn rule line : Key '\s*=\s*' Val > syn token Key '\w\+' { key_table.add($1); } > syn token Val '.*' { val_table.add($1); } > > or simply: > > syn rule text : line '\n' text | '' > syn rule line : '\w\+' '\s*=\s*' '.*' { > key_table.add($1); > val_table.add($3); > } > > it can more readable than syn sentence Vim used now: > syn match FooWord '^\w\+' nextgroup=FooEq > syn match FooEq '\s*=\s*' contained nextgroup=FooVal > syn match FooVal '.*' contained > > > and it can support more functional, it can get the information of text > when parse text. > > you can see a text editor written with Haskell language, it has Vi- > mode > and Emacs-mode, it use parser to highlight and collect informations. > so > it can support a lot of language and implement true "syntax" > highlight. > > > > -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
