Johannes Schmid
2007-12-24 23:47:13 UTC
Hi!
Anjuta preferences to clean up the dialog.
interfaces seems better to me.
too slow. What did you use?
rather than a computer scientist and can't say much about it but from
what I read it would be a lot faster.
some #ifdef'ing but maybe we can disable regex searching completely for
older Glib versions. People would need to update if they want it.
a block and this depends on the language. We could of course limit it to
some languages (C/C++/Java, maybe some else) for now.
fix it. It's possible that they are dirty because of the loading. But if
you are unsure, I will have a look at it.
Well, you are really doing an amazing work! Thanks a lot!
Johannes
Best wishes for the festive season, if you have one of those now ...
Thanks - same for you!* Added command and keybinding (F3, stolen from build plugin because all the editors I sampled use F3 for this) to repeat the prior search-box operation (hence some more docman changes)
* When <ctrl>f is repeated with a search-box already open, any currently selected text is passed to the pattern entry
* Added command and keybinding (<shift>F3) to repeat the prior "main" search, if any
* Reinstated anj 1.2.x command and context-menu item to "list all matches" (most of that code was still there)
* Conformed data pointers used in the plugin and in search prefs. I suspect the search prefs were not doing anything
Might be true. Maybe we should move the preferences to a page in the* When <ctrl>f is repeated with a search-box already open, any currently selected text is passed to the pattern entry
* Added command and keybinding (<shift>F3) to repeat the prior "main" search, if any
* Reinstated anj 1.2.x command and context-menu item to "list all matches" (most of that code was still there)
* Conformed data pointers used in the plugin and in search prefs. I suspect the search prefs were not doing anything
Anjuta preferences to clean up the dialog.
* Concluded that since "non-editor-native" searching is needed for regex and not-opened files, that mode might as well be retained for all search/replace
Yes, of course. Though for the quick search using the native editorinterfaces seems better to me.
* Use slices for allocated memory
* Convert newly-opened file buffers to UTF-8 if needed, before use, because search-patterns from UI and all text in opened buffers (so Naba said) are already in that encoding
* Added funcs to map reasonably quickly both ways between byte-position and char-position
Interesting. I tried to do something like that but ended up being much* Convert newly-opened file buffers to UTF-8 if needed, before use, because search-patterns from UI and all text in opened buffers (so Naba said) are already in that encoding
* Added funcs to map reasonably quickly both ways between byte-position and char-position
too slow. What did you use?
* Added more checks about which search operations can be performed
* Some memory cleans, including at plugin deactivation
* Fixed several minor bugs
* Lots of style conforms
* Deployed line_t and position_t which are both gint for now at least
* Quite a bit of API documentation and other explanation
Next
* implement Knuth-Morris-Pratt algorithm for forward searching at least (backward too if possible)
Wow, that would be nice of course. Since I am (becoming) an engineer* Some memory cleans, including at plugin deactivation
* Fixed several minor bugs
* Lots of style conforms
* Deployed line_t and position_t which are both gint for now at least
* Quite a bit of API documentation and other explanation
Next
* implement Knuth-Morris-Pratt algorithm for forward searching at least (backward too if possible)
rather than a computer scientist and can't say much about it but from
what I read it would be a lot faster.
* implement utf8 form of regex searching
GRegex does this though it's only in the newest GLib. We probably needsome #ifdef'ing but maybe we can disable regex searching completely for
older Glib versions. People would need to update if they want it.
* fix function/block/selection searching (maybe I broke those, but anyhow, they don't work)
I guess they did not work before. The problem is that we need to detecta block and this depends on the language. We could of course limit it to
some languages (C/C++/Java, maybe some else) for now.
* decide which of the 2 provided versions for both find-next and find-previous are more user-friendly
Which two version do you mean?* improve some UI logic in the search dialog
* implement some way to turn off highlighting other than a repeated search with 0 matches (might be just any edit of the buffer)
* testing and bugs .... off-by-one etc etc
BTW, in playing with un-opened files, I noticed that ianjuta_docman_add_buffer() ignores content, I fixed that and anjuta_docman_add_editor() to make paths into uris so that the notebook tabs work properly for files opened during a search. Except that such files are marked as dirty even though they are just bookmarked, say.
You can use (and you might know that) ianjuta_file_set_dirty (FALSE) to* implement some way to turn off highlighting other than a repeated search with 0 matches (might be just any edit of the buffer)
* testing and bugs .... off-by-one etc etc
BTW, in playing with un-opened files, I noticed that ianjuta_docman_add_buffer() ignores content, I fixed that and anjuta_docman_add_editor() to make paths into uris so that the notebook tabs work properly for files opened during a search. Except that such files are marked as dirty even though they are just bookmarked, say.
fix it. It's possible that they are dirty because of the loading. But if
you are unsure, I will have a look at it.
Well, you are really doing an amazing work! Thanks a lot!
Johannes