smartsearch
mobi phil
another idea that I would like to see one day implemented is a smarter search.
I am not lazy to type but often I am in the situation where instead of typing
/the great emperror
i would be much faster by typing only
/t gr e
well one could do that by writing an annoying expression like
/t[a-zA-Z]* g[a-zA-Z]* e[a-zA-Z]*
but until I write that long regexp, I write 5 times the original expression "the great emperror"
well, the code needs little change in my opinion to implement sthg. like that,
and it would be activated by a switch similar to
:set incsearch.
probably:
:set smartsearch="[a-zA-Z]"
and/or
:set smaltsearchfun=myfun()
I implemented a skeleton in ex_getln.c for the incremental search, attached please
find the diff (please do not comment hte style... it is late and I am tired, and I am a
bad C programmer :) )
Maybe I am obsessed by mobile devices, but searching information on a mobile
device with vim is a great idea, but such "smart search" features would improve
the experience....
Obviously the patterns "[a-zA-Z]" should be read from the config file... or even a
function should be defineable that would change the already inserted search string
at each iteration of the incremental search
Please help VIM to evolve :)
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
Marc Weber
> and/or
> :set smaltsearchfun=myfun()
By the way: you don't have to start coding this thing in c
You can write this in some vim script lines (however it'll start
searching after pressing enter and not on the fly)
By the way: Have a look at :h pattern.
There is \s and \S and such which makes life easier..
Try this:
noremap <F11> :call<space>feedkeys('/'.substitute(input('smart search'),'\(\S\+\)\s*','\\<\1\\S*\\>\\s*','g').nr2char(10))<cr>
Another tip: If you're trying to match text within a block. Don't search
for "If you're" but try "'re t" or "ch te" instead of "match text".
In most cases this is uniq enough.
Marc Weber
StarWing
we have cmdline complete now, but why we can't have search complete?
just C-X_C-N for buffer complete, and C-X_C-V for vim complete. is it
difficult?
mobi phil
By the way: you don't have to start coding this thing in c
You can write this in some vim script lines (however it'll start
searching after pressing enter and not on the fly)
>By the way: Have a look at :h pattern.
>There is \s and \S and such which makes life easier..
>>Try this:
>>noremap <F11> :call<space>feedkeys('/'.substitute(input('smart search'),'\(\S\+\)\s*','\\<\1\\S*\\>\\s*','g').nr2char(10))<cr>
>>Another tip: If you're trying to match text within a block. Don't search
>>for "If you're" but try "'re t" or "ch te" instead of "match text".
>>In most cases this is uniq enough.
Marc Weber
--
mobi phil
but maybe I need another feature...
we have cmdline complete now, but why we can't have search complete?
just C-X_C-N for buffer complete, and C-X_C-V for vim complete. is it
difficult?
--
Marc Weber
> just C-X_C-N for buffer complete, and C-X_C-V for vim complete. is it
> difficult?
I don't know about completion in / ? buffers etiher so it I'd say it
doesn't work. Again patching it and getting in the patch will take time.
(I'd rather see someone spend the time making vim threadsafe by adding
some locking .. :-)
So what can you do instead?
You've seen that you can feed arbitrary text to the / command.
And the input() function supports completion. See :h complete()
If that's not enough you can open a temp buffer and add a on buffer
write hook to start the real query. Eg the tlib has some support for
this. So this is a convinient workaround as well.
Maybe you can give more details about which completion is missing so
that the list can help you find the right answer?
Sincerly
Marc Weber
Marc Weber
> >
> > but maybe I need another feature...
> >
> > we have cmdline complete now, but why we can't have search complete?
> > just C-X_C-N for buffer complete, and C-X_C-V for vim complete. is it
> > difficult?
> >
>
> I miss that as well, I added it few days ago te my "whislist" (
> http://mobiphil.com/vimowiki/index.php?title=Vim_enhancement_ideas)
your item
* include an option similar to :set ignorecase :set ignorewhitespaces,
that would allow search accross multiple line, whery usefull when
viewing/editing text
Again: :h pattern : look for this line:
|/\_.| \_. \_. any single character or end-of-line
Thus you can already search across line boundaries. But it might be more
difficult to write the search pattern.
So maybe you want to refine your idea taking into account the existing
solutions. Example: search for more\_.difficult to match the
word wrap in the previous paragraph. By the way: #vim on
irc.freenode.net is your friend in such simple cases..
your item
* i new tool, eventually in C++, with very good plugin mechanism
the main point would be the possibility to add plugins, that is to
add/extend/change functionality at "insertion points", this a feature
that is missing in vim... Vim is great, but to change anything you have
to "pray" to the master :)
probably this will never happen, there are others who tried to do that
maybe it would be easier to hack other editors to add vim like
capabilities
some other short ideas at vim+
I feel the same. That's why I did start tovl
http://www.github.com/MarcWeber/theonevimlib
But again you should do more research and ask long time vim users
because:
* vim *is* extensible. Eg you can extend it using python, perl, ruby,
php, .. ( Have a look at the configure flags)
you can even load .dlls or such (but they will be reloaded again and
again)
Editors which have vi-like key bindings: Eclipse (you have to pay some $
for the plugin officially), Netbenas (great support, even v then o
works!) and probably some more. However it's hard to define the set of
"vi(m)" like features an editor must support because reading the help
pages of vim alone takes ages.. Even emacs has a vi like mode called
viper.
So without telling the list what you want to do and which plugins you
want to write it's hard to help you showing you the existing solutions.
If you want to code Java best you can do is either use Eclipse IDE or
Eclim (run vim and connect to headless Eclipse?) Why ? Because recoding
the incremental compiler which does already exist in Eclipse and is
maintained is insane. If you seach www.vim.org you can even find a Java
parser which has been written in vim script however it was not updated
for over a year.
So don't try to ask questions like "How can I make vim do this meta
thing". Rather ask: I have this use case: .... Which is the vim way to
handle this, how do you do this?
You'll get much better results. So after all don't try to use vim for
everything. Use the tool which is best for a given task (vim happens to be the
tool of choice for many of my tasks..).
Marc Weber
mobi phil
I don't know about completion in / ? buffers etiher so it I'd say it
doesn't work. Again patching it and getting in the patch will take time.
(I'd rather see someone spend the time making vim threadsafe by adding
some locking .. :-)
mobi phil
Again: :h pattern : look for this line:
|/\_.| \_. \_. any single character or end-of-line
Thus you can already search across line boundaries. But it might be more
difficult to write the search pattern.
I feel the same. That's why I did start tovl
http://www.github.com/MarcWeber/theonevimlib
* vim *is* extensible. Eg you can extend it using python, perl, ruby,
php, .. ( Have a look at the configure flags)
you can even load .dlls or such (but they will be reloaded again and
again)
So don't try to ask questions like "How can I make vim do this meta
thing". Rather ask: I have this use case: .... Which is the vim way to
handle this, how do you do this?
You'll get much better results. So after all don't try to use vim for
everything. Use the tool which is best for a given task (vim happens to be the
tool of choice for many of my tasks..).
Marc Weber
> >
> > Again: :h pattern : look for this line:
> >
> |/\_.| \_. \_. any single character or end-of-line
> > Thus you can already search across line boundaries. But it might be more
> > difficult to write the search pattern.
> >
> that is again workaround.
If you do 5 searches a minute.. Go for it - good luck.
If I have such an idea and want to implement it it turns out to take
days. That's why I suggested asking for "workarounds" and exploring
whether they could work for you.
I'd like to see some more development on vim as well.
> symbols for the script etc. The same with python. I doubt that the
> functions available to the python interface would allow me to implement
> the previously presented smartsearch for example
There is another way: Implement kind of event loop listening for
keyboard input using getchar() replacing the search pattern on the fly?
Here is an implementation which might just work for you without patching
C code, source the file and press F2, then type ba to match "bar\napple"
fun! CharsToPattern(list)
let pattern = ''
let spaces='\%(\n\|\s\)\+' " newline or space at least once
for i in a:list
let pattern .= '\<'.i.'\S*'.spaces
endfor
return pattern
endfun
" starts an event loop polling for keyboard input
" type esc to abort, <cr> to accept smart search
" TODO: don't use cursorline but use regex to highlight match
fun! SmartSearch()
echo "smart-search, type some chars"
" FIXME: turn it off again conditionally
set cursorline
let oldpos = getpos('.')
let typedchars = [] " keeps a list of characters
while 1
let c = getchar()
if index([13,10],c) >= 0
" pressed enter, keeep position
call feedkeys("/".CharsToPattern(typedchars)."\n")
return
elseif index([27], c) >=0
" esc, abort
call setpos('.', oldpos)
return ""
elseif c == "\<bs>"
" backspace, remove last item
let typedchars = typedchars[:-2]
else
call add(typedchars, nr2char(c))
endif
" reset cursor pos cause we want the next match
call setpos('.', oldpos)
let g:pattern = CharsToPattern(typedchars)
call search(g:pattern, 'w')
redraw!
echo join(typedchars,'').' press esc to exit, <cr> to accept'
endwhile
endf
noremap <F2> :call SmartSearch()<cr>
> Look, I think I am enough mature and have years of IT, I know how to
> attack a problem.
Sure. I didn't want to say you can't solve problems. Sure you can.
I want to show you that vim is its own world and has its own solutions.
So do me a favour and judge the solution above and tell how distinct is
it from a real acceptable solution ?
> Of course I will try to use it for everything. I had few month ago an
> experiment
> to go back a bit to Eclipse, but the first time I had to move my hand to the
> mouse, I was sick :)
So eclim is for you. There are some use cases using a mouse is faster.
Eg renaming keywords in Java files using Eclipse IDE cause Eclipse is
Java aware and will do a perfect job an many files. You can't get that
speed by using dozens of mappings using vim, can you?
(Of course I miss idutils and I grep code using vim far more often than
using Eclipse IDE). Another thing I'd cosider using Eclipse is debugging
PHP, Python, Java Code. There are some debuggers for vim. But they lack
some important features such as clicking on the stack trace and
exploring vars at that point of the trace. Yes, you have to leave the
keyboard.. But you can set breakpoint properties and such more easily
(IMHO).. That's what I meant by using the right tool for a task.
So for Debugging I'd vote for Eclipse. For code I know very well I'd use
vim.
> But I would not give up with the idea to search efficiently in 2GB text
> data.
2GB text data? Is it one file? Yes, you're right vim can be a good
solution for this problem (maybe switching of syntax highlighting etc..)
> you would rather smartsearch, than writing hierogliphs in your search
> commands :)
I agreed and gave you a very first proof of concept implementation. I
gave you a much smarter second one now. So judge it again and let's
see..
About locking and making vim threadsafe: I don't want to make the whole
vim code thread safe. I don't have that much time and probably I'm not
smart enough to finish that task in reasonable time.. So I'd try getting
a lock when vim runs any action (eg due to keyboard input) or a python
thread calls vim.eval. This might be doable. If you really want to have
this stuff have a look at tovl. I used vim server features to talk back
to vim using another thread. That works only when running X but it works
:)
By the way: Nice to meet you!
Marc Weber
Tony Mechelynck
Maybe the "accents" keymaps would help you. After ":set keymap=accents",
hit 'e for e-acute, `o for o-grave, :u for u-umlaut, ^i for
i-circumflex, 'c for c-cedilla, ~n for n-tilde, etc. Romanian
(t-cedilla, s-cedilla, etc.) doesn't seem to be included, also not
Hungarian (double-acute-accented vowels), the Latin-Slavic (Polish
l-bar, Czech, Slovak, Croatian consonants with acute or caron), the
Scandinavian languages (o-slash, ae-digraph, a-ball, edh, thorn),
Catalan (l with middle dot) or Esperanto (consontants with circumflex,
u-breve) but once you've understood how the system works, save the
keymap under another name in ~/.vim/keymap (Unix) or ~/vimfiles/keymap
(Windows) and edit it there.
Use Ctrl-^ (in Insert/Replace or Command-line mode) to toggle the keymap
on and off.
Also:
* searches forward for the word under the cursor
# searches backward for the word under the cursor
q/ and q? open the search history in a window (where you may do any
edits without leaving the window; Enter executes the line under the
cursor as a search command and closes the search history; :q closes it
without any other action and goes back to where you were before)
Best regards,
Tony.
--
Expense Accounts, n.:
Corporate food stamps.
Tony Mechelynck
[...]
> Look, I think I am enough mature and have years of IT, I know how to
> attack a problem. I have these ideas for years now, I wanted to be sure
> that they are useful. And now I am convinced that they are useful. What
> you say depends on what does it mean "vim way". You mean vim way of
> vim 3.7 or vim way of 10.11? There is a difference. I think you got the
> point.
> Of course I am not pretending to add a c++ compiler for the highlighting.
> That would be against the basic principle "vim is the fastest editor".
> Any feature
> that would break that basic principle is nonsense for me.
Oh, so you know better what Vim release 11 should include? Well, go
ahead, take the sources (they're there for anyone to look at) or start
from scratch, and come back 5 years from now (or somesuch - when Bram
will be releasing _his_ Vim 11.0) to put Bram's nose in his shit by
showing thim that he had it all wrong and how vim 11 REALLY should behave.
Good luck!
Tony.
--
hundred-and-one symptoms of being an internet addict:
75. You start wondering whether you could actually upgrade your brain
with a Pentium Pro microprocessor 80. The upgrade works just fine.
Marc Weber
> pure my soul I am confused about the spelling of a word, so the trick above
> does not work.
have to do that as often as you.
eg do match Straße I use Stra.e . Yeah, again a workaround ;-)
Anyway tell me how my other solution works for you.
Marc Weber
Nikolai Weibull
Mechelynck<antoine.m...@gmail.com> wrote:
> On 15/07/09 14:43, mobi phil wrote:
>> Look, I think I am enough mature and have years of IT, I know how to
>> attack a problem.
Considering that you seem to have posted your first message to this
list about one week ago, yes, that seems about right.
>> I have these ideas for years now, I wanted to be sure
>> that they are useful. And now I am convinced that they are useful. What
>> you say depends on what does it mean "vim way". You mean vim way of
>> vim 3.7 or vim way of 10.11? There is a difference. I think you got the
>> point.
> and come back 5 years from now (or somesuch - when Bram
> will be releasing _his_ Vim 11.0) to put Bram's nose in his shit by
> showing thim that he had it all wrong and how vim 11 REALLY should behave.
Jesus, that’s harsh.
StarWing
>> That would be against the basic principle "vim is the fastest editor". Any
>> feature
size
text. UltraEdit or even emacs is far more fast than Vim. Vim just can
fast
boot and fast when you edit small texts, maybe some lazy-eval tricks
and good
algorithm will make Vim more fast. that's my goal.
and, add a c++ compiler is not slow. you only need parse current
function,
other informations can obtain in tag files. and you can do a lazy
parse. I
mean, if you want Vim fast and expendable (not just compatibles with
Vi),
you can do a lot of work :-)
Nikolai Weibull
>>> Of course I am not pretending to add a c++ compiler for the highlighting.
>>> That would be against the basic principle "vim is the fastest editor". Any
>>> feature
> no, IMHO vim is not the fastest editor. you can try use Vim open a 2GB
> size
> text. UltraEdit or even emacs is far more fast than Vim.
Can you please do something about your line wrapping? Trying to read
your messages is getting rather annoying.
Anyway, where are you getting these “statistics” from? I just ran a
simple test, opening a 185 MB text file in both editors. Vim took 7
seconds, Emacs 14 seconds. I don’t know about UltraEdit, but it’s
going faster as it doesn’t need to load the whole file, last time I
checked. (Things may have changed to accomodate variable-width
encodings, which are always going to be an issue.)
Just to be clear, I’m not trying to bash Emacs, I’m trying to bash you.
> Vim just can
> fast
> boot and fast when you edit small texts, maybe some lazy-eval tricks
> and good
> algorithm will make Vim more fast. that's my goal.
Goal? Have you thought this through further than writing this email?
“Good algorithm”? Do you know anything about implementing a text
editor? Let me tell you, as someone who has written two and devoted
two years of research into the matter for my master’s thesis, that
writing a text editor is fucking hard. Vim’s method of reading and
managing a buffer may not be optimal, but it’s pretty good and writing
something that’s better will require a lot of work. A big whole
shitload of work.
> and, add a c++ compiler is not slow. you only need parse current
> function,
> other informations can obtain in tag files. and you can do a lazy
> parse. I
> mean, if you want Vim fast and expendable (not just compatibles with
> Vi),
> you can do a lot of work :-)
What are you talking about here? A C++ omni-completer? When did we
begin discussing something like that in this thread? Right now? I’m
not following.
If this is in regard to the suggested C++ rewrite of Vim, then wow, just wow.
Further, what the hell would rewriting Vim in C++ gain? Why is
everyone’s who’s clearly slightly insane’s solution (to problems that
often don’t even exist), ”Hey, have you considered rewriting it in
C++”?
What Vim needs is a clearer separation of concerns in the source code.
Different subsystems depend too much upon each other. The overuse of
#ifdef’s also makes the code rather hard to understand. What it
doesn’t need is a rewrite.
StarWing
On 7月17日, 上午12时11分, Nikolai Weibull <n...@bitwi.se> wrote:
> >>> Of course I am not pretending to add a c++ compiler for the highlighting.
> >>> That would be against the basic principle "vim is the fastest editor". Any
> >>> feature
> > no, IMHO vim is not the fastest editor. you can try use Vim open a 2GB
> > size
> > text. UltraEdit or even emacs is far more fast than Vim.
>
> Can you please do something about your line wrapping? Trying to read
> your messages is getting rather annoying.
>
defaultly 78, which too long for this mail list.
> Anyway, where are you getting these “statistics” from? I just ran a
> simple test, opening a 185 MB text file in both editors. Vim took 7
> seconds, Emacs 14 seconds. I don’t know about UltraEdit, but it’s
> going faster as it doesn’t need to load the whole file, last time I
> checked. (Things may have changed to accomodate variable-width
> encodings, which are always going to be an issue.)
>
> Just to be clear, I’m not trying to bash Emacs, I’m trying to bash you.
text file you use? I tell you: yes, if it's a "normal" text, Vim is
fast than most of editor, but, you can try use Vim to open "test" file
generated by this simple C program:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int i = 10000000;
freopen("test", "w", stdout);
while (i--)
printf("this is a fucking long line?");
return 0;
}
yes, it's a big long line. and you know what Vim do? in my Vim
7.2.228, it dead. just lost respond. and take 100% CPU usage.
just add a \n at the end of string, Vim can open this file in 7s. Why?
because Vim reads logical line, not block, it makes Vim obtain memory
unlimitly when it meet a long line. this is just one thing I want
change. in a lot of fucking fact of Vim.
>
> > Vim just can
> > fast
> > boot and fast when you edit small texts, maybe some lazy-eval tricks
> > and good
> > algorithm will make Vim more fast. that's my goal.
>
> Goal? Have you thought this through further than writing this email?
> “Good algorithm”? Do you know anything about implementing a text
> editor? Let me tell you, as someone who has written two and devoted
> two years of research into the matter for my master’s thesis, that
> writing a text editor is fucking hard. Vim’s method of reading and
> managing a buffer may not be optimal, but it’s pretty good and writing
> something that’s better will require a lot of work. A big whole
> shitload of work.
editor is really hard. I know. that's why I'm not write it now. I need
learn more things to balance, to make choice. I know it hard, but Vim
is not prefect, I just want Vim prefect. makes Vim fast than all of
other editors, and full extendable.
BUT, Vim is success, it has a lot of experience. I will read all of
its code, after understand it, I will begin my work. not now. because
I know it's hard.
IMHO, I want a new text editor, it has multithread, do on-the-fly
service background, it manage memory fast and clever, all of memory
are have ref-count and copy-on-write. yes, I'm not thinking about to
write a editor, I'm thinging about to write a Operation-system based
on Vim. that's my private hobby, I'm not beg you to join me.
>
> > and, add a c++ compiler is not slow. you only need parse current
> > function,
> > other informations can obtain in tag files. and you can do a lazy
> > parse. I
> > mean, if you want Vim fast and expendable (not just compatibles with
> > Vi),
> > you can do a lot of work :-)
>
> What are you talking about here? A C++ omni-completer? When did we
> begin discussing something like that in this thread? Right now? I’m
> not following.
Visual Studio, that's one of my plan. but must after I finished my
prefect Vim (in my mind), so maybe you can use it after 5 years.
> If this is in regard to the suggested C++ rewrite of Vim, then wow, just wow.
>
> Further, what the hell would rewriting Vim in C++ gain? Why is
> everyone’s who’s clearly slightly insane’s solution (to problems that
> often don’t even exist), ”Hey, have you considered rewriting it in
> C++”?
>
> What Vim needs is a clearer separation of concerns in the source code.
> Different subsystems depend too much upon each other. The overuse of
> #ifdef’s also makes the code rather hard to understand. What it
> doesn’t need is a rewrite.
in C++. I want to build framework to Vim, change some parts of it
(especially reguiar expression and memory manage), and fix old vim
code into new framework. current Vim is a big gold mine, rewrite is
just impolicy. AND, I think C is the best language to implement a
portable text editor.
My Plan: port a fast reguiar expression to Vim (Vim's current regex
module is hell terrible), make a middle level script language (not a
macro language in current Vim now, but current Vim-script will hold
in, for the big amount of scripts avalible now), a better memory
manager as the subordinate of the script system. and a better undo
system (since history issue, Vim's undo system is more or less
terrible), and a flesh new parser-base highlight system. all in all,
what I should do is just invente a new language for Vim. that's all
(maybe with a little other things.)
thanks for attention it. I just treat it as hobby (just as Bram do), I
planed pay years on it. I know Vim is a success software, I will not
throw it away. all I do is make it prefect, in C.
StarWing
> yes, it's a big long line. and you know what Vim do? in my Vim
> 7.2.228, it dead. just lost respond. and take 100% CPU usage.
screen of text, but after I try to select a piece of text, it dead
again :-(
Marc Weber
> terrible), and a flesh new parser-base highlight system. all in all,
About your long line use case: I don't think you have to edit this kind
of files very often. In fact I never did. So I consider this being a
corner case I'm not interested in. I could use bvi for such files.
If you're that good at C I'd write a short C app which splits the long
lines
LLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGONG LONG
into
LLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGLONG
== AUTO SPLIT ===
LONGLONG LONGLONG LONGLONG LONGLONG LONGLONG LONGONG LONG
so that you can join them again later.
Yeah it's a workaround. but you can open the file in vim then and it
will take less time than rewriting parts of vim.
I don't want you stopping your work on improving vim.
But I don't think this use case in particular is that important.
I wish you good luck, some help provided by this list
and ... much spare time..
Yours
Marc Weber
StarWing
I just treat it as a practise. there are a amount of reasons to
improve Vim, not really full rewriting it.
for long line. I used to edit bookmark.htm generated by Firefox, it
contains BASE64 line for icons, and my Vim crashed... I had to use
notepad to do some work, that makes me thought about how to prefect
Vim.
Maybe rewritten is just some kinds of over excitation. but the really
thing I want is to change the philosophy of current Vim, just solve
out
the history remain issues, remove the parts that Vim had to hold, and
do
some courageous experiment about it. that's all.
Nikolai Weibull
> On 7月17日, 上午12时11分, Nikolai Weibull <n...@bitwi.se> wrote:
>> Anyway, where are you getting these “statistics” from? I just ran a
>> simple test, opening a 185 MB text file in both editors. Vim took 7
>> seconds, Emacs 14 seconds. I don’t know about UltraEdit, but it’s
>> going faster as it doesn’t need to load the whole file, last time I
>> checked. (Things may have changed to accomodate variable-width
>> encodings, which are always going to be an issue.)
>>
>> Just to be clear, I’m not trying to bash Emacs, I’m trying to bash you.
> OK. but do you know how Vim hand memory and how Vim read a file?
Yes. Did you read my whole mail?
> what text file you use? I tell you: yes, if it's a "normal" text, Vim is
> fast than most of editor, but, you can try use Vim to open "test" file
> generated by this simple C program:
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> int i = 10000000;
>
> freopen("test", "w", stdout);
> while (i--)
> printf("this is a fucking long line?");
>
> return 0;
> }
See, that’s sort of the problem. When you could use something simple like
% repeat 10000000; do echo "this is a fucking long line?"; done > test
you’re already thinking of a C program, 13 lines long.
> yes, it's a big long line. and you know what Vim do? in my Vim
> 7.2.228, it dead. just lost respond. and take 100% CPU usage.
> just add a \n at the end of string, Vim can open this file in 7s. Why?
> because Vim reads logical line, not block, it makes Vim obtain memory
> unlimitly when it meet a long line. this is just one thing I want
> change. in a lot of fucking fact of Vim.
”Logical”? Am I getting my terminology mixed up or isn’t a logical
line what you get when you enable word wrapping?
By the way, Emacs has the exact same issue with this sort of file.
> What good algorithm? the algorithm Linus write in a OS.
I don’t follow this line of reasoning.
> IMHO, I want a new text editor, it has multithread, do on-the-fly
> service background
This is a desirable goal, yes. Having an editor support transactions
is a good goal and would allow background processing.
> it manage memory fast and clever, all of memory
> are have ref-count and copy-on-write.
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.
> yes, I'm not thinking about to
> write a editor, I'm thinging about to write a Operation-system based
> on Vim.
Ah, there it is.
> that's my private hobby, I'm not beg you to join me.
May I then beg you to create a separate mailing list where discussion
revolving around this operating-system Vim can be had instead?
> Yes. A omni-completer for C++ language. just like VisualAssist on
> Visual Studio, that's one of my plan. but must after I finished my
> prefect Vim (in my mind), so maybe you can use it after 5 years.
...
> My Plan: port a fast reguiar expression to Vim (Vim's current regex
> module is hell terrible)
I thought this had already been done?.
> make a middle level script language (not a
> macro language in current Vim now, but current Vim-script will hold
> in, for the big amount of scripts avalible now)
Hasn’t this also been done?.
> a better memory manager as the subordinate of the script system.
Memory manager for what memory use?
> and a better undo system (since history issue, Vim's undo system
> is more or less terrible)
Huh? What’s wrong with Vim’s undo?
> and a flesh new parser-base highlight system.
This I can live with.
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.
> all in all,
> what I should do is just invente a new language for Vim. that's all
> (maybe with a little other things.)
You’re tone suggests that this is easy. Invent a language? And how
does that solve all the “problems” listed above?
StarWing
repeat command, a good lesson. C is directly, but not simple.
> > yes, it's a big long line. and you know what Vim do? in my Vim
> > 7.2.228, it dead. just lost respond. and take 100% CPU usage.
> > just add a \n at the end of string, Vim can open this file in 7s. Why?
> > because Vim reads logical line, not block, it makes Vim obtain memory
> > unlimitly when it meet a long line. this is just one thing I want
> > change. in a lot of fucking fact of Vim.
>
> ”Logical”? Am I getting my terminology mixed up or isn’t a logical
> line what you get when you enable word wrapping?
> By the way, Emacs has the exact same issue with this sort of file.
and, it's nothing about emacs. Emacs is more flexable than Vim, that's
my goal -- one of my goals.
> > What good algorithm? the algorithm Linus write in a OS.
>
> I don’t follow this line of reasoning.
>
> > IMHO, I want a new text editor, it has multithread, do on-the-fly
> > service background
>
> This is a desirable goal, yes. Having an editor support transactions
> is a good goal and would allow background processing.
>
> > it manage memory fast and clever, all of memory
> > are have ref-count and copy-on-write.
>
> 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.
operating system and found that I can use these tech to improve Vim.
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 has memory leaks ( a dozen of patch are made for it), and it
waste of memory (copy lines for undo, for submatch(), etc).
- it isn't thread-safe. so you can't load service while loading
file.
- it has a weak language, can't handle all functional of Vim, and
slow.
- it had s weak reguiar expression module, just can handle context
free pattern. and file pattern & text pattern has different
format.
- 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.
With ref-count (used in eval.c now), Vim needn't copy blocks in undo.
that's why I think it's important.
first of all, we think about the mode of Vim.
In my concept, New-Vim just have two interface to hand mode. One for
normal mode, and One for insert mode:
- a normal mode accepts a count and a operator (single key), and
call functions against the operator. functions are passed to mode
interface as argument, so you can use it at any time, just create
a static/dynmanic struct, and call this mode. (e.g. normal mode,
select mode, list mode (-- More --), Yes/No, etc.)
- a insert mode accepts a string. you pass a buffer and a size of
buffer, and function list struct. if your cursor leave the place
or you press a exit key, you leave this mode. so all places you
need input something can use this mode. (e.g. insert mode, replace
mode, cmdline mode, etc.)
so, Vim archive turns to a core, two interface (for keyboard), a
interface (for screen), and amount of service. service is the function
used to fix in the struct pass to mode interface.
the most important is, In my design, the struct is especially. it can
handle native Binary code (C functions) and script function (bytecode
or dynamic library). so this archive offers flexable for Vim. and we
can fill original Vim code into services. that's why a language is
needed. (that's the framework I said)
it also makes sense in option system: current implement is awkward.
why not to use a hook-system (mentions as function list struct above)
to implement it?
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?).
current Vim script is just something like macro, not a real fast
middle-level script language (middle-level means, Vim implement by
this language, not use this language as plugin). we can even compile
it into C code, for speed. it has syntax like VimL, but has features
like perl/python/ruby. this idea just mixup Vim and emacs.
> 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.
(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?
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. it can parse anywhere, even in a wrong place, it
usually treat my code as text, just it start parse in a wrong place
:-(
StarWing
http://groups.google.com/group/vim_dev/t/890db4346d17ad0b
I use it in my script...
Marc Weber
Hi StarWing,
> I just treat it as a practise. there are a amount of reasons to
> improve Vim, not really full rewriting it.
> for long line. I used to edit bookmark.htm generated by Firefox, it
some use cases and doesn't do what you want (eg syntax highlighting).
Can you give the list a chance discussing these issues by providing
examples what doesn't work? Eg can you prepare a sinmple (real world)
example which causes problems to you?
I don't consider a 268MB file containing one line a real world example.
Also what bothers you about syntax highlighting most that you want to
enhance it?
If the list can't find solutions for you I guess some people will try to
help you fixing the issues?
By the way I've tried some more editors forcing them to open your 280MB
file:
less: seems to be a way.. However I don't know whether you can scroll
horizontally.
mc (midnight commander)
F3 view: seems to work. But updating the display
takes more than 7sec here (dual core 2.4Ghz)
F4 (edit): message "File is too large"
Eclipse: Exception:
Unable to create editor ID org.eclipse.ui.DefaultTextEditor: Editor could not be initialized. Java heap space
Netbeans: No error. It hangs for 2 sec. But it doesn't open the file.
nano: Don't know, does no longer react to keyboard input
jedit: No message, no content ? (probably some Exceptions, I didn't
check)
nvi: Works fine! But it doesn't support even the gj command
I repeated the test using a 30MB file only.
vim : works but sluggish (syn off)
mc : same
emacs : I couldn't scroll, it seems to be slower (?)
Eclipse: I killed it. It took more than a couple of minutes - still no result
netbeans: I got a warning that a 30MB file might cause a memory out of
bounds exception this time. I killed it after some minutes -
no result
jedit: I killed it. > 30sec - no
Java heap space exceptions.
oowriter (insert -> file).. I killed it. No sucess within 30sec.
So may I conclude that you should try nvi or use bvi for now?
If you want to view the file maybe even try a browser such as Opera or
Firefox (don't open FireBug ..).
> contains BASE64 line for icons, and my Vim crashed... I had to use
> notepad to do some work, that makes me thought about how to prefect
> Vim.
>
> Maybe rewritten is just some kinds of over excitation. but the really
> thing I want is to change the philosophy of current Vim, just solve
> out
> the history remain issues, remove the parts that Vim had to hold, and
I asked about making set nocompatible the default once (minor change)..
And some people don't want to change their minds.
So maybe it's best to fork for that reason?
Marc Weber
StarWing
> Hi StarWing,> I just treat it as a practise. there are a amount of reasons to
> > improve Vim, not really full rewriting it.
> > for long line. I used to edit bookmark.htm generated by Firefox, it
>
> Ok. I guess we have the cause of your mails now: Vim crashes for you in
> some use cases and doesn't do what you want (eg syntax highlighting).
>
> Can you give the list a chance discussing these issues by providing
That crash was fix by a patch (I forgot the number). but that crash
makes me to look in the code of Vim. and I saw a lot of temporary
static variables (esp. in implement of regex and autocmd). even Vim
uses a recursion call to solve expression evaluate :-( that's may slow
and dangerous. and, Vim mix up morphology and grammar. that makes the
code of eval.c confusion and lengthiness. Vim just give another
implement of eval-functions, so to get state of Vim is requires in how
much f_ function implemented, and it can't works with all version of
Vim (you even don't know in with patch fileescape() function have
added!). all of this makes me want to rewrite some part of Vim. that's
all.
But I know, current VIm can work, and can work greatly. so I just want
to open a branch to experiment new implement of part of Vim. and if it
really works better than current Vim, maybe Bram can add it into main
source.
Tony Mechelynck
> [...] even Vim
> uses a recursion call to solve expression evaluate :-( that's may slow
On the contrary, recursion is the right way to evaluate expressions,
because any expression may include full-fledged expressions as
part-results, if only within (). _Not_ using recursion to evaluate
expressions would be difficult to program, bug-prone (which rates as
"dangerous" to me) and not necessarily faster.
Regards,
Tony.
--
I value kindness to human beings first of all, and kindness to
animals. I don't respect the law; I have a total irreverence for
anything connected with society except that which makes the roads
safer, the beer stronger, the food cheaper, and old men and women
warmer in the winter, and happier in the summer.
-- Brendan Behan
Nikolai Weibull
> 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.
StarWing
On 7月17日, 下午4时39分, Nikolai Weibull <n...@bitwi.se> 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.
>
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.
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.
> > 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.
>
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.
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)
Teemu Likonen
> Emacs is more flexable than Vim, that's my goal -- one of my goals.
> IMHO, Vim has several issues:
> current Vim script is just something like macro, not a real fast
> middle-level script language (middle-level means, Vim implement by
> this language, not use this language as plugin). we can even compile
> it into C code, for speed. it has syntax like VimL, but has features
> like perl/python/ruby. this idea just mixup Vim and emacs.
Indeed Emacs is more flexible and open system, hence a better platform
for modifications and extensions. Your plans for Vim are so ambitious
that I honestly think that nothing will concrete will ever come out of
them. Sure I may be wrong, and I really _hope_ that I'm wrong.
Anyway, in my opinion it would be better to join forces with some
existing projects. If you feel that Vim's design, goal or development is
stuck and not suitable for the kind of improvements that you would like,
then maybe Yi editor project has similar goals to yours. I think Yi is
the most interesting "next generation programmer's editor" project. It's
written in Haskell language and follows the Emacs-like idea of making an
open, interactively modifiable system. Maybe you want to check Yi
project:
Nikolai Weibull
> On 7月17日, 下午4时39分, Nikolai Weibull <n...@bitwi.se> wrote:
>> On Fri, Jul 17, 2009 at 01:00, StarWing<weasley...@sina.com> wrote:
>> > 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.
No, not really. Not until it gets things like real anonymous
functions, access to a lot more low-level stuff, and so on.
I once wrote a patch to add a getpwnam() wrapper. Bram rejected it on
the basis that it wouldn’t be useful enough to warrant the addition.
I don’t agree, as I needed it for ftplugin/changelog.vim, but I
respect his view on it.
>> 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?
Yes?
> But Why you can use perl patterns to match paren? because it support
> recursive in pattern, and you can integration codes into patterns.
You’re talking about Perl 6’s grammar functionality. They’re
definitely not regular.
>> > 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?
How much code can there be that handles the file pattern stuff?
Matching file patterns is easy.
> Is it important in your mind? I think it's funny and powerful.
Without semantics, syntax is unimportant.
StarWing
> On 2009-07-16 16:00 (-0700), StarWing wrote:
>
> > Emacs is more flexable than Vim, that's my goal -- one of my goals.
> > IMHO, Vim has several issues:
> > current Vim script is just something like macro, not a real fast
> > middle-level script language (middle-level means, Vim implement by
> > this language, not use this language as plugin). we can even compile
> > it into C code, for speed. it has syntax like VimL, but has features
> > like perl/python/ruby. this idea just mixup Vim and emacs.
>
> Indeed Emacs is more flexible and open system, hence a better platform
> for modifications and extensions. Your plans for Vim are so ambitious
> that I honestly think that nothing will concrete will ever come out of
> them. Sure I may be wrong, and I really _hope_ that I'm wrong.
>
(nearly impossible). but I (personal) could get some experiment to do
it. maybe some stage goal can be used by Vim.
thanks to Nikolai Welbull, he makes me know more about my plan :-)
> Anyway, in my opinion it would be better to join forces with some
> existing projects. If you feel that Vim's design, goal or development is
> stuck and not suitable for the kind of improvements that you would like,
> then maybe Yi editor project has similar goals to yours. I think Yi is
> the most interesting "next generation programmer's editor" project. It's
> written in Haskell language and follows the Emacs-like idea of making an
> open, interactively modifiable system. Maybe you want to check Yi
> project:
>
> http://www.haskell.org/haskellwiki/Yi
several month but I can't understand Haskell, and (in my opinion)
Haskell community is more or less unfriendly (maybe it's caused by my
rude :-( I don't want that, but my English is really bad )
I want something mixed Vi & ruby. to make a ruby-like language to fit
Vim, mix it into Vi's lower level implement. that's all.
another things (undo, highlight, mode, etc.) is just further plan,
there are only ideas here.
Marc Weber
> haha, I found this for a long time. but this isn't fit me. I used
> several month but I can't understand Haskell, and (in my opinion)
> Haskell community is more or less unfriendly (maybe it's caused by my
> rude :-( I don't want that, but my English is really bad )
learning vim :)
> I want something mixed Vi & ruby. to make a ruby-like language to fit
> Vim, mix it into Vi's lower level implement. that's all.
I'd be glad if an existing language (ruby, perl, python, ..) fits your
needs. Because learning yet another language to script vim is bad IMHO.
Marc Weber
Ben Fritz
On Jul 17, 4:49 am, StarWing <weasley...@sina.com> wrote:
> 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.
>
consider it a "pattern" per se), but I successfully did this in a
single :s command...I'm just not 100% certain it's supposed to work:
http://groups.google.com/group/vim_use/browse_thread/thread/3ca623fd506820fa
Tony Mechelynck
[...]
> Haskell community is more or less unfriendly (maybe it's caused by my
> rude :-( I don't want that, but my English is really bad )
IOW, the reason you're trolling here rather than there is because we're
too friendly? Maybe that's something we ought to remember...
Yes, you're English is bad, and that may sometimes make it harder to
understand what you really mean, but the problem (IMO) is not so much
with the language as with the ideas... Maybe I'm a fossilized
dinausaurus though, unable to see progress when it stares me in the
face... Well, time will tell.
Regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
79. All of your most erotic dreams have a scrollbar at the right side.
Marc Weber
> [..] so I just want
> to open a branch to experiment new implement of part of Vim.
You can find a git mirror here: http://repo.or.cz/w/vim_mainline.git
Using top-git is most convenient (IMHO) for keeping patches up to date.
Contact me if you want to know more about top git topic branches.
Marc Weber
StarWing
little more flexable and mainly: fast. all other changes can
background.
StarWing
On Jul 17, 9:39 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
idea from other people. to find how we do the work better. Do you
think I just like a clown, raise argument and run away?
StarWing
Nikolai Weibull
> On Jul 17, 9:39 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
> wrote:
>> the problem (IMO) is not so much
>> with the language as with the ideas...
> Why you think I'm trolling here? I just show what I think and wait the
> idea from other people. to find how we do the work better. Do you
> think I just like a clown, raise argument and run away?
Because you’re basically saying that you’ve just read a book on
operating-system design and that you have a couple of things that you
want to change with Vim to make it more like an operating system and
that your comments suggest that you think this will be an easy task.
mobi phil
Oh, so you know better what Vim release 11 should include? Well, go
ahead, take the sources (they're there for anyone to look at) or start
from scratch, and come back 5 years from now (or somesuch - when Bram
will be releasing _his_ Vim 11.0) to put Bram's nose in his shit by
showing thim that he had it all wrong and how vim 11 REALLY should behave.
mobi phil
being mobile, but including technology
http://mobiphil.com
mobi phil
Excerpts from mobi phil's message of Wed Jul 15 12:21:44 +0200 2009:
> pure my soul I am confused about the spelling of a word, so the trick aboveI use . for those "unwritable" chars and go on. I agree that I don't
> does not work.
have to do that as often as you.
eg do match Straße I use Stra.e . Yeah, again a workaround ;-)
Anyway tell me how my other solution works for you.
Marc Weber
--
mobi phil
Considering that you seem to have posted your first message to thislist about one week ago, yes, that seems about right.
mobi phil
Can you please do something about your line wrapping? Trying to read
your messages is getting rather annoying.
Anyway, where are you getting these “statistics” from? I just ran a
simple test, opening a 185 MB text file in both editors. Vim took 7
seconds, Emacs 14 seconds. I don’t know about UltraEdit, but it’s
going faster as it doesn’t need to load the whole file, last time I
checked. (Things may have changed to accomodate variable-width
encodings, which are always going to be an issue.)
Goal? Have you thought this through further than writing this email?“Good algorithm”? Do you know anything about implementing a text
editor? Let me tell you, as someone who has written two and devoted
two years of research into the matter for my master’s thesis, that
writing a text editor is fucking hard. Vim’s method of reading and
managing a buffer may not be optimal, but it’s pretty good and writing
something that’s better will require a lot of work. A big whole
shitload of work.
If this is in regard to the suggested C++ rewrite of Vim, then wow, just wow.
What Vim needs is a clearer separation of concerns in the source code.
Different subsystems depend too much upon each other. The overuse of
#ifdef’s also makes the code rather hard to understand. What it
doesn’t need is a rewrite.
StarWing
On Jul 18, 12:18 am, Nikolai Weibull <n...@bitwi.se> wrote:
and, a huge version Vim isn't just like a operating system? it has
languages, memlines, swap files, etc. the only thing it lacks is
multithread. I just want it works better. not saying Bram's work is
bad.
StarWing
- Hide quoted text -
- Show quoted text -
> > your messages is getting rather annoying.
> if you are reffering to me I do my best with manual wrapping, I can use for
> the
> moment only the web browser to write email, and nothing else.
> > Anyway, where are you getting these “statistics” from? I just ran a
> > simple test, opening a 185 MB text file in both editors. Vim took 7
> > seconds, Emacs 14 seconds. I don’t know about UltraEdit, but it’s
> > going faster as it doesn’t need to load the whole file, last time I
> > checked. (Things may have changed to accomodate variable-width
> > encodings, which are always going to be an issue.)
> could be faster. Could do some sort of lazy reading. That is if certain
> variable is set, than read in only the first part of the buffer. Read the
> rest only when needed.
> More: I understand that the datatype is a linked list. For read only mode
textwidth is still 78, the text below is updated.
My algorithm against your view-mode & edit-mode data type:
We get a big (memory)buffer for use. maybe least 8K for a (vim)buffer.
one for buffer-info, and one for swap file. then, we open a swap file
for use. we write buffer-info into swap file, for its first block.
then, read info in .viminfo file, find out which block should be read.
read 4K text of file (if any) into data page. now we have 8K
(memory)buffer for a (vim)buffer. one info-buffer, and one
swap-buffer. and info-buffer signed as synced.
we do anything need with 4K swap-buffer. the complex thing is decide
where we begin to do syntax highlight. after that the text will
display on screen.
when you "insert" something. get another buffer (if we don't have) for
input. use something like vim_insert_mode(&buffer, 4096,
&info_struct); to call insert mode interface. text will put in buffer.
that's our insert- buffer. register it in buffer-info (exactly in
undo-list of buffer-info). we alloca some space (e.g. 16 items) for
page-list and undo-list and etc. if needed, they can point to a new
block. after insert, we don't move text into swap-block. just make a
sign into swap-block, for display. we just sync swap-block in 1s or 10
times input.
now we have several block: info-block(4K), swap-block(4K*N), insert-
block(for multiuse, mainly undo system). they are all 4K, can swap
into swap file. another memory are used by script system. but in
edit-system. I only want to use 4K block (maybe output to screen or
manage lists need good and careful design).
So, IMO view-mode and edit-mode are the same. view mode isn't contain
insert block, that's all. (they just skelecton, there are a dozen of
details on them. I'm trying to implement them now :-)
Nikolai Weibull
>> Can you please do something about your line wrapping? Trying to read
>> your messages is getting rather annoying.
> if you are reffering to me I do my best with manual wrapping, I can use for
> the moment only the web browser to write email, and nothing else.
No, I wasn’t referring to you. Do you know how quoting in emails
work? You managed to remove the line where it said that I was quoting
StarWing. Jesus.
> again data types used for view mode should not be the same as for editing
> mode.
God.
>> If this is in regard to the suggested C++ rewrite of Vim, then wow, just
>> wow.
> I think you mixed the two things. StarWing was referring to better syntax
> parsing.
Why are you replying to this? StarWing already responded to my question.
> Rewrite in c++ would be an option... But why not create a C++ wrapper
> around the existing VIM functionality and and and ... imagination
And the holy spirit.
Nikolai Weibull
>> Considering that you seem to have posted your first message to this
>> list about one week ago, yes, that seems about right.
> sorry, but do not understand your comment
Precisely my point.
misi e
you need to see a priest :)
mobi phil
I am afraid you confuse the email list with a church. Don't you thin
you need to see a priest :)
Probably that is not the best answer to provocations.
Both StarWing and me tried to come up with some ideas. I think there are millions of civilized ways to answer instead of adding religious words after each paragraph written by somebody else. If suggestions, or comments are not welcome then I think people like StarWing, me and others should really start a new project/mailing list somewhere else. The entire history of human kind is about conflict between people with conservative and liberal views. More, people have different views, different skills and styles of communication. The worst thing is when you do not understand what the other wants to say is to leave comments like "God", "Jesus" etc. Hundreds of open source projects, or ideas have failed to be implemented due to overreactions of this kind.
So dear vim_dev, and especially I am asking Bram, pleas tell us if you feel ofended, or unconfortable about discussions related to how to make vim even better. Are you open for "other" views or not. I think it is waste of energy and time for everybody if one gives hours of his life to present/discuss/try/etc. about fantastic ideas and others jus come with "Jesus", "God", "you are on the list for 1 week so shut up" etc.
my 5 cents about Nikolais extreme reactions
Raúl Núñez de Arenas Coronado
mobi phil <m...@mobiphil.com> dixit:
> So dear vim_dev, and especially I am asking Bram, pleas tell us if you
> feel ofended, or unconfortable about discussions related to how to
> make vim even better. Are you open for "other" views or not.
I don't think anybody is feeling offended here. And I don't think
Nikolai acted "extreme", IMHO he was just amazed.
I don't know if you've realized that Vim is open source. That means that
you can fork Vim or even make your own vim-like editor, using Bram's
sources as a base, without needing Bram's approval or implication (and
the same applies to the rest of the members of this list). To me, it
looks like you and Starwing are looking for cooperation, which is good
but you have to understand that maybe nobody wants to help you with your
ideas, or you are looking for approval and some kind of compromise of
accepting your patches. That's up to Bram, of course, and you have to
understand that probably he won't be involved in any way until you show
a bit more of code.
Again: Vim is open source, so feel free to roll your own version. You
can't expect a lot of replies to your ideas encouraging you to make them
real. That seldom happens: for it to happen you need a whole lot of
people thinking like you, and that's not common. Believe it or not, many
many people like Vim like it is, and even though may value your work,
they may not encourage you to do it. You have to understand it ;)
> I think it is waste of energy and time for everybody if one gives
> hours of his life to present/discuss/try/etc. about fantastic ideas
> and others jus come with "Jesus", "God",
In my humble opinion, using "Jesus", "God" or something like that is a
very english way of showing amazement, and your "fantastic" ideas are a
bit amazing, yes. Please, don't feel offended by that ;)
> "you are on the list for 1 week so shut up" etc.
Nobody has told that...
--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
mobi phil
I don't think anybody is feeling offended here. And I don't think
Nikolai acted "extreme", IMHO he was just amazed.
why would you make comments like "Jesus" or "god" on ideas like different datatype for view mode would be beneficial. Yes they would be if you are in view mode you do not need your datatype to be ready for insertion, however it would be faster to open, as splitting the file into any kind of linked list or similar is time consuming! And you do not need a PHD to understand that.
That's up to Bram, of course, and you have to
understand that probably he won't be involved in any way until you show
a bit more of code.
Again: Vim is open source, so feel free to roll your own version. You
can't expect a lot of replies to your ideas encouraging you to make them
real.
That seldom happens: for it to happen you need a whole lot of
people thinking like you, and that's not common. Believe it or not, many
many people like Vim like it is, and even though may value your work,
they may not encourage you to do it. You have to understand it ;)
In my humble opinion, using "Jesus", "God" or something like that is a
very english way of showing amazement, and your "fantastic" ideas are a
bit amazing, yes. Please, don't feel offended by that ;)
> "you are on the list for 1 week so shut up" etc.
--
Raúl Núñez de Arenas Coronado
mobi phil <m...@mobiphil.com> dixit:
>> I don't think anybody is feeling offended here. And I don't think
>> Nikolai acted "extreme", IMHO he was just amazed.
>
> Nikolai's comments are just disgusting.
I don't think so...
> Why would it be a problem of rewriting vim in c++? Why should one call
> sthg. like that insane idea?
Because it is, maybe. I mean, I find that an insane idea too. Rewriting
Vim is already an insane idea, but doing it in C++... And no, I'm not
discussing about C++ here, that's way off-topic.
> why would you make comments like "Jesus" or "god" on ideas like
> different datatype for view mode would be beneficial.
You make such comments out of amazement.
>> That's up to Bram, of course, and you have to understand that
>> probably he won't be involved in any way until you show a bit more of
>> code.
>
> To be honest I did not participate in too many open source projects as
> I did not have too much time.
If you don't have too much time you shouldn't start the project you have
in mind. Any serious modification in Vim code will take a very big
amount of time, so take it into account before starting.
> One guy has ported for example vim 6.0 to windows mobile, but for one
> or other reason his changes were never integrated. If they would, I
> would not need to spend that much time with that.
Again: Vim is OPEN SOURCE. You don't need Bram to integrate anything he
don't want to integrate because you can do it in your own copy of Vim
and release your own version of Vim with the changes you want.
Asking why some change was not integrated is not fair. In fact I find it
a bit rude because nobody has the right of asking for anything in an
open source project. In Vim, only the sponsors have a little right of
asking for features, and even them shouldn't do it because they are not
paying for Vim, they're just making the life of poor children a bit
better.
>> That seldom happens: for it to happen you need a whole lot of people
>> thinking like you, and that's not common. Believe it or not, many
>> many people like Vim like it is, and even though may value your work,
>> they may not encourage you to do it. You have to understand it ;)
>
> I know, but why "may not encourage". They do not want to have pain
> with that? They do not want the tool to evolve?
They may like Vim like it is now. What you consider evolution some
others may consider otherwise. Your opinion is not the absolute truth.
>> > "you are on the list for 1 week so shut up" etc.
>
>>>>Nobody has told that...
>
> Not you for sure... look back to Nikolais useless emails, and you will find
> the sentenc.
I've read the message and he didn't include the "so shut up"...