This project is read-only.

Version 3.0 Feature Requests

Topics: Developer Forum, Project Management Forum, User Forum
Jan 6, 2010 at 6:53 PM

As I look through the discussion threads, issue tracker, and some of the new features available in Scintilla that haven't yet been integrated into ScintillaNET, there is quite a bit of work to do. In addition, I think that living with the ScintillaNET 2.0 style API over the last several months (years) has taught us what works and what doesn't.

Rather than continuing to make incremental changes to the 2.0 branch, I think there is an opportunity here to create a new 3.0 version of ScintillaNET. This would give us an opportunity to make more sweeping changes to the API without disrupting the current implementation. It wouldn't be a rewrite (heavens no), but it would likely include some major overhauls. Version 2.* of ScintillaNET would continue to be supported through this migration and would continue to receive hotfixes/patches.

That's the background to what I hope will be a long ongoing discussion thread. If we were to make a version 3.0 of ScintillaNET you could help us to answer:

  • Is there a need for ScintillaNET 3.0?
  • What would you like to see in ScintillaNET 3.0? What new Scintilla features would you prioritize the highest?
  • What wouldn't you change from the current ScintllaNET 2.0 API? What would you change?
  • What is currently a source of frustration for you?
  • How can we make ScintillaNET more user friendly for beginners? More powerful for advanced users?
  • Are there any platforms/environments that we don't currently support that you would like us to?
  • Is maintaining the NativeInterface important to you or do you prefer a higher level of abstraction?
  • Do the ScintillaNET additional features such as configuration, snippets, find and replace dialog, work for you? If not, why?
  • Etc....

Obviously we can't make any specific promises but we would like your input.



Jan 11, 2010 at 6:12 PM

I'll get the ball rolling with an idea that may polarize some people--I think it's time to get rid of the NativeInterface.

It's easy to see the progression of ScintillaNET if you look back to the 1.* versions, where there was ONLY a native style API to where we are now. I think the next logical evolution of ScintillaNET is to be a first-class Windows Forms control that should work and behave just like any other. Having to cast the control as an INativeScintilla interface or access the NativeInterface property on the control (which is really a reference to itself) breaks the illusion that this is a Windows Forms control.

That's not to say that we should prevent native messages from being sent to ScintillaNET. I can see where there are some users who will want to bypass the friendly API we've written on top of Scintilla and just sent it messages directly. I fully advocate that idea--in fact I would like to make it easier to do just that, however, I don't think those users really care if we have an interface defined for that.

As such, it's my goal for ScintillaNET 3.0 to pull every possible Scintilla function into its proper place on the control and deprecate the INativeScintilla interface in favor of the managed interface or manual direct messages.




Jan 14, 2010 at 3:06 PM
Edited Jan 14, 2010 at 3:07 PM

I hope I'm not being impertinent with some of these, but speaking from the point of view of having used the ICSharpCode.TextEditor component before turning to ScintillaNET:

1) The TextEditor component supported XML syntax files, with the ability to specify file extensions as an attribute to the root element. The configuration manager in this component would automatically apply the correct syntax definition when a file is loaded. At the moment, I've had to crudely use a dictionary to store file extensions and language names, and set the appropriate properties when loading a new file, which is a lot of extra boilerplate compared to the TextEditor component.

2) Save/Load methods. At the moment, saving and loading files have to be done "manually", in the sense that you need to read and write to the Text property of the control. Not necessarily a terrible thing, but it seems like a fairly common enough use case which should be handled by the control.

3) OnCaretChanged event for the caret object. In order to emulate such an event, I've needed to set event handlers for click, keydown, textinserted, deleted and changed. I'm currently using this for a line/column tracker in the toolstrip of a winforms app.

4) For some weird reason, the caret object only has line and position, but no column. I've needed to fall back on native scintilla in order to get the column number. This would be one of those things where you need to make sure you really do get all the functions out of INativeScintilla if you're thinking about removing it.

5) Speaking as a beginner of both scintilla and scintillaNet, one of the main points of frustration was having to essentially learn two different controls. I think if you can get to the point where you no longer have to link to the scintilla documentation as the main documentation for ScintillaNET, then you're onto something good. Also, creating a formal schema for the XML config would be a plus. Having to dive through source code in order to find out the names of valid attributes and elements is not an exciting task, to say the least.



Jan 14, 2010 at 4:35 PM

Thanks James for your feedback.

You can rest assured that if/when we remove the old legacy code that we won't loose any functionality. I won't do that until we've got every feature moved over to the new API. If we meet all my goals there will be no need for users to ever have to refer to the old Scintilla documentation.

You'll be happy to know that some of your requests have already been completed in the 3.0 branch. You can use the UpdateUI event to track caret placement and the GetColumnFromByteIndex to get the current column of the caret. Both are demonstrated in the ScintillaPad sample application currently in progress and set to be included in the 3.0 release.

Load/Save methods are also already in the works in the 3.0 branch but are not there quite yet.

I also have plans to completely re-engineer the configuration manager. How, exactly I'm not sure but I'll see what we can do about lexer and file type associations.




Jan 17, 2010 at 7:25 AM

Also v2 has some things on your list

3) SelectionChange event gets fired whenever the caret moves even if there is no selection (anchor and caret are the same)

4) GetColumn() is defined in the Scintilla class. I do agree that it makes sense to make it a part of the caret.

I'm actually not much of a fan of putting save/load methods on the Scintilla class. There's hundreds of classes in .NET for loading/saving from filesystem, network, database and whatever else you can think of. Richtextbox is a good example of this, it has caused all sorts of weird problems for it. It puts the onus of checking for permissions, locked files, handling of very large files, etc onto Scintilla which is really the responsibility of the calling app. If we do get to the point where we think everything is wrapped sufficiently we can mark it as requiring lower CAS permissions, but not if we put in methods that read/write to the filesystem. Besides if we're talking about pure simplicity it doesn't get much simpler than

scintilla.Text = File.ReadAllText("blah.txt");

Jan 20, 2010 at 12:18 AM

It took me a long time to warm up to load and save methods, but I think there could be some value there. Famous last words before I go down the rabbit hole. :)


Jan 28, 2010 at 11:15 PM

Another idea I want to explorer is eliminating most (if not all) Scintilla helper objects and moving their methods and properties up to the Scintilla control itself. Some of my reasoning is that:

  1. It makes it hard for users to find some features because they are buried several levels deep.
  2. Some helpers require extra work to dispose of them properly.
  3. Some of the helper objects have a hard time staying in sync with the Scintilla control.

The number one reason is really important to me. I've seen several discussion entries over the years from users looking for a feature that exists but couldn't find it because it was buried too deep. One of the primary benefits of moving everything up to the control level is that those properties will be more visible from the Property Grid in the designer. A secondary benefit is that it simplifies the codebase and maintenance.

Naming conventions might be changed for clarity, but the majority of cases would simply be:










Feb 22, 2011 at 6:00 PM

Any news on this? I'm still having my text editor plan on my list, waiting for ScintillaNET 3 that adds support for some required Scintilla features and that possibly changes the entire API. I wouldn't want to change my whole programme, too, so I'm either waiting for ScintillaNET 3 with a new API style or trying to go my own way. Could you give me some input for my decision?

Feb 22, 2011 at 6:41 PM

Honestly I would not count on a new version coming out any time soon. Neither Jacob or I have actively worked on this in the past 9 months or so and no one else seems interested in taking over future development. 

Feb 22, 2011 at 7:50 PM

Okay, so I'd just plain cancel that effort and add all the missing things from newer Scintilla versions into the existing ScintillaNET code. Would that work or are there more problems coming?

I'm browsing the ScintillaNET code right now and it's - huge! Most of it seems to be a straight-forward projection of the C API into OOP but it can't be done automatically, so I'd be writing for weeks to rewrite this. Maybe ScintillaNET is just like it is, in whatever style. We won't make it (more?) beautiful in this life, unless some company decides to pay a developer for some months to work on it.

Mar 7, 2011 at 11:20 PM

I plan on using this for a major project of mine, so it will definitely be changed in the process. I'll submit any improvements I make in the form of patches. One thing I definitely plan to work on is intellisense support, as the current version is lacking that. My project will also require highlighting for a large number of languages, so I'll release the highlighting for them as they get completed.

Mar 8, 2011 at 6:20 AM

That sounds good. Will you start on the current "2.x" branch of ScintillaNET or is there already some usable "3.0" version you'd use? I haven't seen much of it all yet but I guess I'd be okay either way.

Mar 8, 2011 at 6:33 PM
Edited Mar 8, 2011 at 7:43 PM

Well, so far in looking at the code I haven't seen much of a difference between 2.x and 3.0 (other than the partially completed design dialog), however, I may start my work with the 3.0 branch (I'm assuming it has improvements over 2.x), But no matter which branch I start with (be it 2.x or 3.0) I will make sure I make the improvements to the other branch as well.

I also intend to bring some of the good features of the older version to the newest ones. (such as the ability to read .properties files)  As well as improve the (non-existant) documentation for the existing format.