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.

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

Raspunde prin e-mail lui