wrong plugin is blamed
-
Wrong plugin is reported during plugin crash. The FIRST plugin in the plugin folder is blamed
anyone else seeing this?
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/1980
It can explain why dspellcheck has a bad name - and I’ve never had it crashing.
-
Hello Kasper,
good point - I can confirm this behavior. I got reported that compare plugin failed while
mine threw an exception.Cheers
Claudia -
@Claudia-Frank perhaps you should join the github discussion.
what plugins are you maintaining?
-
I guess isn’t needed anymore as dail has already provided a patch .
what plugins are you maintaining?
Just some protocol decoders/converters for my companies application, nothing which npp community can benefit from.
Cheers
Claudia -
ok but you still know your way around n++/scintilla - so you must have done some rather complex stuff
-
Not as complex as you might think ;-)
Protocol en/decoding and converting is, from my point of view,
one of the simpler programming tasks as it is as strict as possible.
Reading stream, do task, output stream.
OK, with real time systems you need to be sure that your code
is as efficient as possible but my task has mostly to do with testing,
so I don’t care if it takes 20ns or 100ms if stream has been manipulated.Most of the things I know from npp/scintilla I got taught by the forum members.
Lately, as I try to become a better c++ programmer, I was forced to read the npp
source code to understand how it works but unfortunately the learning curve
isn’t as steady as with other programming languages.Cheers
Claudia -
@Claudia-Frank I just read parts of the code myself yesterday. N++ is doing textsearching rather in-efficiently. Really wanted to change the code but C++ and the code style is so far away from how I code (small classes, lots of unit tests)… perhaps I’ll post an issue on github with a link to a much better search algorithm (boyer moore https://en.wikipedia.org/wiki/Boyer–Moore_string_search_algorithm ) but raising issues is like fighting a pillow it seems.
maybe @dail can work some magic here? ;)
-
I’ll agree the code is not the prettiest or easiest to maintain.
N++ is doing textsearching rather in-efficiently
What part are you meaning in particular? AFAIK it uses Scintilla to do the searching (and boost as well for regex stuff).
-
@dail what about here https://github.com/notepad-plus-plus/notepad-plus-plus/blob/287ce9ec147d6d64224d8990f99385f57a240df4/scintilla/src/Document.cxx#L1682 it looks like a linear search - the algorithm link i sent the other day is much faster
-
That is part of Scintilla so any changes would have to go through the Scintilla project.
-
Ah sorry. Ill raise an issue there. Cool even faster searching in the future
:) -
Custom better search algorithms often have a potential problem connected to character representation. I mean, they operate with character tables to accelerate the search, but it’s not easy to create a proper character table for UTF-8 non-Latin text when 1 symbol can be represented by 2 or more bytes. So the developer should thoroughly weigh the pros and cons of an algorithm to be used.
-
@Vitaliy-Dovgan good point. But that as i see it would only make the jump table less inefficient. Also when you look at the charat() both in my link and on the Document class it is delegating to it seems to be operating on char.
-
@Vitaliy-Dovgan good point. But that as i see it would only make the jump table more inefficient. A full comparison i taking place on every potential match
Also when you look at the charat() both in my link and on the Document class it is delegating to it seems to be operating on char.