1 Apr 2005 03:05
1 Apr 2005 02:19
Re: [scintilla-FeatureRequests-1165611]Autocompletioncosmeticandperformance enhancements
Neil Hodgson <nyamatongwe <at> gmail.com>
2005-04-01 00:19:04 GMT
2005-04-01 00:19:04 GMT
Blair McGlashan: > It seems I'm not going to be able to persuade you that there is value in > having auto-completion list contents guaranteed to match the sort ordering > expected by the list. I try to prevent expansion of Scintilla's scope beyond what is reasonable and maintainable. Sort callbacks triggered my hypergeneralization / You Aren't Gonna Need It response. > Also I can't see how the current mechanism properly supports unicode > characters, or even the ordering of accented european characters. It imposes an arbitrary but repeatable ordering. > As a language implementor I find that a bit of a generalisation. Looks like Smalltalk isn't for me then(Continue reading)> Languages > that have their roots as internet scripting languages (perhaps an unfair > characterisation of Python) may well have placed some optimisation effort > there and pulled down the sorting implementation (both algorithm and > comparison functions) into C in the VM/runtime. Implementing the comparison function in Python rather than using a builtin adds about 5% to the run time. > Other languages (or platform > libraries such as .NET) which are perhaps more general purpose may implement
1 Apr 2005 03:06
1 Apr 2005 03:28
Re: Anyone try to build ScintillaNet with a Visual Studio C++ 8 beta?
Garrett Serack <gserack <at> gmail.com>
2005-04-01 01:28:06 GMT
2005-04-01 01:28:06 GMT
I might be mistaken, but didn't I eliminate all the C++ from ScintillaNET like, almost a year ago? hmmm... You may be using a much older version of the library. I ended up writing the current version as a C# wrapper that uses the native C++ library compiled as is from Scite. the C++ version introduced just too many troubles when keeping the main source tree synched with the Scintilla main line code. The latest version is much more flexible with binding into .NET languages... It's been over a year since I looked at C++/CLI, and at that time the C++ folks at MS had said that there would be essentially two C++ profiles for .NET : Managed C++ (should have been source compatable with any MC++ from today, [uses /clr:oldSyntax ]) and C++/CLI (which was a new effort to merge C++ with .NET [uses /clr]). If you are still using the C++ version, I really don't know what to say.... uhh., wow. :) Garrett On Thu, 31 Mar 2005 11:02:28 -0800, Eric Promislow <ericp <at> activestate.com> wrote: > I managed to build it with the November and December betas of VS 8, > with little problem - > but am running into problems dealing with changes to managed C++(Continue reading)
1 Apr 2005 03:29
Re: Anyone try to build ScintillaNet with a Visual Studio C++ 8 beta?
Garrett Serack <gserack <at> gmail.com>
2005-04-01 01:29:46 GMT
2005-04-01 01:29:46 GMT
Ah. I just saw that you were posting this on the Scintilla group. You may want to take a peek at the ScintillaNET mailing list at http://tinyurl.com/yvoh2 and the website at http://scide.net Garrett On Thu, 31 Mar 2005 18:28:06 -0700, Garrett Serack <gserack <at> gmail.com> wrote: > I might be mistaken, but didn't I eliminate all the C++ from > ScintillaNET like, almost a year ago? > > hmmm... > > You may be using a much older version of the library. I ended up > writing the current version as a C# wrapper that uses the native C++ > library compiled as is from Scite. > > the C++ version introduced just too many troubles when keeping the > main source tree synched with the Scintilla main line code. > > The latest version is much more flexible with binding into .NET languages... > > It's been over a year since I looked at C++/CLI, and at that time the > C++ folks at MS had said that there would be essentially two C++ > profiles for .NET : Managed C++ (should have been source compatable > with any MC++ from today, [uses /clr:oldSyntax ]) and C++/CLI (which > was a new effort to merge C++ with .NET [uses /clr]). > > If you are still using the C++ version, I really don't know what to > say.... uhh., wow. :) >(Continue reading)
1 Apr 2005 02:33
Re: Question about the marker that *wouldn't die*
Neil Hodgson <nyamatongwe <at> gmail.com>
2005-04-01 00:33:26 GMT
2005-04-01 00:33:26 GMT
Robert Roessler: > Really, why is the behavior with deleting marked lines defined this > way? If I get rid of a line, there are at least times (if not every > time) when I want the marker[s] do disappear without a trace too. Deleting lines before a marker moves the markers up so that breakpoints or bookmarks stay with their text. Should this occur even when the marker is on a line that is deleted? When the user is removing parts of a line then the normal answer is no even if is the line end or beginning that is being deleted as the text being marked still probably exists, possibly on a different line number. When the whole line is deleted more of an argument can be made for deleting all markers. The reason that they are still there is that it may be easier for the application to treat the markers as the primary identities of the user entities but have other information (pass count for a break point, etc) keyed off them and deleting them may disrupt the application's data structures. It is quite easy for the application to remove markers itself. > BTW, here is my "use case" (some of you use this terminology): I am > inserting some lines (basically error descriptions) in the user's > buffer, and would like to call attention to them - the marker thing > seems ideal for this, BUT I also want the user to be able to hit > Ctrl-Z and make the lines go away... but while the lines are deleted, > the marker[s] remain on an adjacent (the docs say preceding, I think) > line. This is less than ideal. :( SCI_MARKERDELETEALL(Continue reading)
1 Apr 2005 04:22
Test download
Neil Hodgson <nyamatongwe <at> gmail.com>
2005-04-01 02:22:51 GMT
2005-04-01 02:22:51 GMT
There is a test download available including almost all of what will be 1.63 which may be released on April 4. Available from CVS and from http://scintilla.sourceforge.net/scite.zip Source http://scintilla.sourceforge.net/wscite.zip Windows executable To do: List changes on history page Possibly add some of the GTK+ file chooser modifications Neil
1 Apr 2005 06:59
Re: Question about the marker that *wouldn't die*
Robert Roessler <robertr <at> rftp.com>
2005-04-01 04:59:41 GMT
2005-04-01 04:59:41 GMT
Neil Hodgson wrote: > Robert Roessler: > > >>Really, why is the behavior with deleting marked lines defined this >>way? If I get rid of a line, there are at least times (if not every >>time) when I want the marker[s] do disappear without a trace too. > > > Deleting lines before a marker moves the markers up so that > breakpoints or bookmarks stay with their text. Should this occur even > when the marker is on a line that is deleted? When the user is > removing parts of a line then the normal answer is no even if is the > line end or beginning that is being deleted as the text being marked > still probably exists, possibly on a different line number. This makes sense, but wasn't a concern. > When the whole line is deleted more of an argument can be made for > deleting all markers. The reason that they are still there is that it > may be easier for the application to treat the markers as the primary > identities of the user entities but have other information (pass count > for a break point, etc) keyed off them and deleting them may disrupt > the application's data structures. It is quite easy for the > application to remove markers itself. If there is this concern about hanging on to this [maybe there, maybe not] data for the app, then maybe it makes more sense to have a PRE-delete notification and let the app grab anything it cares about(Continue reading)
1 Apr 2005 07:28
Notifications and inserts...
Robert Roessler <robertr <at> rftp.com>
2005-04-01 05:28:58 GMT
2005-04-01 05:28:58 GMT
... together and separately. When I paste multiple lines of text into a Scintilla window (this is in GTK+2.4-land), I notice that I get the notification, but the linesAdded is ZERO - the "length" is fine. Of course, the number refers to STYLED chars (i.e., every char is followed by a zero). OTOH, when I delete a full line, the length is correct, the linesAdded is correct - but POSITIVE. And the text points at UN-styled chars. :) Here is a biggy WRT to pasting text - I *really* wish that pasted text was made to conform to the the currently active EOL setting for that buffer. I got into some real trouble (read "wasted a bunch of time") doing some pattern matching on some pasted in text, because it came in with CR/LF, even though I had set the EOL type to LF. And the #$*^#$ pattern-matching lib I am using felt that the CR was somehow *before* the real EOL, so regular exprs with "$" at the end would NOT match. :( Of course, the pattern problem is not because of Scintilla, nor is the CR/LF problem per se... but I think it illustrates a difficulty - when adding text into a buffer, it is not all that easy to "fix" the EOL sequences if they don't already match the buffer's. Re-translating the whole buffer on every text-insertion notification doesn't seem very appealing... and when *wouldn't* you want the auto-translate on insert behavior? Finally, I notice (when tracing Scintilla notifications being sent to its GTK container) that there is a constant stream of SCN_PAINTEDs showing up - it looks like one every second. Is this expected? This happens with or without Pango, if that matters.(Continue reading)
1 Apr 2005 13:43
Re: Test download
Massimo Maria Ghisalberti <nissl <at> tiscali.it>
2005-04-01 11:43:54 GMT
2005-04-01 11:43:54 GMT
Neil Hodgson wrote: > There is a test download available including almost all of what >will be 1.63 which may be released on April 4. > > Available from CVS and from >http://scintilla.sourceforge.net/scite.zip Source >http://scintilla.sourceforge.net/wscite.zip Windows executable > > To do: >List changes on history page >Possibly add some of the GTK+ file chooser modifications > > Neil >_______________________________________________ >Scintilla-interest mailing list >Scintilla-interest <at> lyra.org >http://mailman.lyra.org/mailman/listinfo/scintilla-interest > > > Neil, is it possible to change, in the SciTE about window before the new release, "nissl" (my nickname) to "Massimo Maria Ghisalberti" ? Thanks... :) Massimo Maria Ghisalberti LINee multimediaagency - www.linee.it(Continue reading)
RSS Feed