"Is the "disable undo" of any use, or I should get rid of it?"
if you make an limit for stack undo then it will be useless. i will simply set limit to zero

"The "search in selection" is (...) a bit complicated task with this design."
seriously? i thought that fasmw has a line-based design and replaces can't span a line, so implementing this should be simple.

"FASMW just forgot to use it."
yes, fasmw has a problems with its memory

The limit for undo stack would only make things slower, and discard some changes trace "behind your back". I don't like such idea.

As for the "search in selection" - it's the vertical blocks that put a bit of diversity into it.

add an option - limit: infinity
why it should make things slower? you can set eg. 64kb limit and use buffer like queue. it may be 0.0001 % slower or so - because you have to care about size, but you don't have to care about allocation new segments.

why blocks make it difficult? just skip matches that appears too early or too late in a line. you only have to remember corners positions of block. and maybe local variables (per line) adjusted after each replace. only a few variables and flags to add.

it all is very easy to do but *you* must do that. i remeber that i wanted sometime to change tab length in editor and of course fasmw was constatnly crashing after my modifications

btw/ atsd:
przycina ci to forum czasem może pora zmienić na ipb?
czemu masz status hidden? za dużo peemów?

Well, maybe I can, but this would involve designing things differently, while I prefer my current one. Actually almost everything in this design has some reason, and I wrote it to be different than other editors just because I needed something different. To be honest, I wrote this editor for myself, and it reflects clearly my own expectations.


"Just". Right.


If this is so easy, then I why it's *me* who has to do it?
By the fact that I understand better what has to be done to implement something into fasmw, I also know better why some things are difficult or even undesirable.

[PL Offtopic]
Co do forum: niedługo mam nadzieję przenieść się na nowy serwer, na PowWeb rzeczywiście jest tragicznie.

ok. do what you want to do. you are stubborn as a donkey (just kidding)

i have many ideas to play with but i'm too lazy and your code design is *very very very* unintuitive, so maybe leave fasmw as is. currently i'm working on my own multimedia filter for 7-zip - so no chance for fasmw.



atsd:
na forum.optymalizcja.com piszą, że phpbb jest lekko zasobożerne.

edit:
sorry, że za dużo kozaczę. już tak mam. mam nadzieję, że cię nie obraziłem.

I just recalled that the accurate description of what my problem with implementing seach in selection was a bit different. My trouble was related to the fact, that with every search you can do "find next" after some text modifications has been made (like in "search and replace", for the simplest example). In case of selection search editor would have to track in some way, what the selection has become during the meanwhile text modifications (otherwise this feature would lead to confusing results). This is especially difficult with vertical blocks. Thus I just got used to do cut&paste of selection into a temporary editor window, do searches and replacements there and the copy it back - from the usage point of view it's almost the same, while it saved me a headaches of designing the implementation (which would anyway be potentially faulty).

as i said above: fasmw has line-based design. so i see no difference between doing search & replace in one line and in one block. maybe i'm wrong and fasmw has capability to change more than one line during _one_ replace?

when searching you already must keep track of lines legnth and treat each line indepedently. so if selection start at x1 and ends at x2 then, for each line, you must adjust them: blah: x1=min(length,x1) x2=min(length,x2); if (x1=x2) skip line; if (some word replaced) {x2=x2+length_of_new_word-length_of_replaced_word; goto blah} else {skip line; restore x1 and x2}. instead of searching line in range <0;length>, you must search in range <x1;x2>. this code is for vertical blocks only. for normal selection method the code will be similar.

i can't believe that it can be so difficult! maybe your design is wrong?

btw: this pseudocode is somewhat unoptimized (you can, for example, write: if (x1>length) skip line) and not tested but should work.

btw2: i thougth that after each replace you just move search pointer after replaced word. maybe you use some other magic method?

btw3: i don't fully understand your last post

Of course my design is wrong, it was done with other things in mind.
Note that before "find" and "find next" someone can do do absolutely ANY moditications to the WHOLE text. This was a design problem even to implement the standard "find next" at all. With selection I don't bother - I don't have time to solve such complex things now. fasmw's editor is different from the DN's one in aspect that you cannot have a selection "sticking" to the place while you edit text, and the text flows out of selection etc. - however selection sticking to the place rather than text makes not much sense for me, that's why I didn't go into such direction.

chyba się nie rozumiemy

i'm not talking about find & find next, but about search & replace. of course with find & find next my ideas are impractical and almost nobody will use them. but: usually, text editors haven't an option to search only in selection in find dialog and usually this option is present only in search & replace dialog. and i want fasmw to behave like theym.

so, what's the problem?

There's no such thing as "search&replace" in asmedit's core. You could implement the "replace next" using the existing features aswell.

And the problem is that if I implement searching in selection, then it also must in some way apply to "find next" feature - I don't consider partial solutions.

weird design and weird designer

the simplest solution is to disable find next after each modification. but it may be not acceptable. other simple solution is to implement search & replace indepedent from find & find next. this will duplicate a bit of code, but will make code much simpler, faster and more flexible. yet another solution: some editors finds all patterns at once and lists them in another window. then user simply clicks on some match and editor shows him where it is.

i'll think about this problem again later.

If you think about this problem, think about designing some new editor. It may be easier than inclining some design that was made to work differently. fasmw's editor is exactly what I wanted it to be - though you're free to take it make your own on base of it.

I consider it to be a bit like an art - the flat assembler (and it's dedicated editor also) are the works of art that I sign with my name, as they are my personal children which I designed myself up to every detail (even though sometimes I may have been taking some patterns from the works of others). Anyone is free to make his own works on base of mine, however I make available here and sign by myself only the works of my own vision, and made with my own hands. If something doesn't fit my vision, I decline to put it into my work, just like any artist would. If something does fit my vision, but it was someone else who already done it, I redo such work myself, and according my own "artistical" standards.

somewhat complicated for me

returning to thread topic - have you tired noupdate flag? set noupdate = not prompt_on_replace at beginning and clear this flag and update window at the end. disabling undo doesn't make any significant difference in speed.

I did mean the "search in selection" in a way how I saw it, not the simplified variant you mentioned, that doesn't gain much as for me.

As for the noupdate - it should actually work this way, since windows only gets updated when there's time for it. However for some reason Windows algorithms for choosing whether there is right time for an update seem to a bit unpredictable.

in short:
1. my ideas are useless for you
2. you haven't tried noupdate flag
3. donkey7 niepotrzebnie zawraca ci gitarę



btw: as you see, my english is sometimes poor

It looks they use stuffy system or high-language calls that could be
simply overriden using intrinsic.

WARNING: old thread bumped after 4 years

Is it necessary to bump multiple threads, in total 15 years old ???

FYI, slow S&R got fixed in the meantime: http://board.flatassembler.net/topic.php?t=9925