Until this time text editor Aditor 2.10b was my favourite editor. But I see now that Notepad++ is much powerful and with plug-ins it can work exactly as I want.
My developed plug-in has following features:
> Encoding (russian & ukrainian):
- encoding autodetect (see below)
- cp866 -> cp1251
- koi8-r -> cp1251
- iso8859-5 -> cp1251
- mac -> cp1251
- cp1251 -> cp866
- cp1251 -> koi8-r
- cp1251 -> iso8859-5
- cp1251 -> mac
> Smart Brackets autocomlete (no stupid autocomplete always)
> 2 user-defined alternative char tables (for example, you press english T or F and it's automatically replaced by russian E or A).
F9 key swithes between english and alternative symbols.
1) encoding autodetect must be called manually because I don't know what notification message is sent by Scintilla when opening a file
2) there is no separators in plugin's menu because I can't understand how to insert them (maybe I'm to stupid?)
At first, where could I download this plugin. Could you send it to Don, so that he could publish it on his homepage?
Currently I develope a HexEditor-Plugin for Notepad++. Maybe that this is interesting.
OK, I've sent a letter to Don.
HexEditor-plugin is a great idea. Currently I use xvi32.exe as external HexEditor - it has very interesting feature called "XVI script" - internal script commands. And its 'text strings' and 'hex strings' are very useful too.
New cool feature: plugin could be compiled in two modifications.
- with RUS_CP_CONVERT defined this plugin has the same interface as described above (russian chars conversion)
- with no defined RUS_CP_CONVERT this plugin's interface is changed: instead of russian chars conversions it uses common "dos (oem) -> win" (OemToChar) and "win -> dos (oem)" (CharToOem) conversions.
So now this plugin is helpful for non-russian languages as much as for russian
I've already predicted the need for an onload and onsave event and have come up with a potential sequence.
1. plugins must be able to entirely replace the physical load process.
2. Plugins must be able to seamlessly and reliably alter editor contents during a load and save.
N++ sends the plugin a message: Do you want to handle loading files? 3 responses
0: No, no interested. All plugins will answer 0 unless specifically programmed to handle such events.
1: Yes, N++ is responsible for loading the file
2: Yes, the plugin takes responsiblity for loading the file
The plugin will also return the size of the data area necessary to store it's data should the load be successful.
If the plugin takes responsibility for loading the file, N++ will send a message with the filename when it is time to load the file. 2 responses
0: The load failed. N++ will indicate which plugin failed to load the file and may offer to commandeer the load process to force a successful completion.
1: The load succeeded. Note that the plugin should not customize the editor contents at this time.
The plugin will return which mode the editor should be set to when the load process is complete and the certainty of the specified setting.
The last message is sent when the load is complete, whether by the plugin or by Notepad++. This is when the plugin can customize the editor contents.
During this message N++ will provide the requested storage area for flags or other plugin data. A plugin might, for example, want to store the fact that a conversion from KOI8_R was performed on the text so that the exact opposite conversion will be certain to be peformed sometime later on save. Each editor window could potentially have a different conversion performed on it which is unrelated to the plugin's currently selected conversion option.
Save would go through a similar sequence. The plugin developer working on these conversions should comment whether or not this sequence is sufficient.
Eventually N++ internal loading of files should be integrated into this message process.
Subclassing isn't good enough. With it you can capture when the user hits Save, Save As, and their shortcuts. What you won't be able to capture is when the user closes Notepad and it asks "Do you want to save file.txt?" [YES/NO] You also can't be certain that every window will be modified the same way or that every window was modified by the same plugin.
In the beginning the crude methods are fine but eventually we will need full support for plugin load and save to get seamless support for convertable languages.
Give the above process, I could completely replace Load & Save with my own that doesn't have the 128MB character munging bug.
OK, thanks to everybody. I see the problem is much deeper as it seems at the first sight.
That's why I think that potential russian/ukrainian users of this plugin can press Ctrl+Alt+E manually to autodetect the encoding of the text with unreadable characters :-)
As I understand, I can't insert a separator into plugin's menu, but an existing menu item can be modified as in NPPTextFX source so that it becomes a separator.
That's how I've made it.
Now plugin's menu includes separators.
Also, external Hex Editor call has been added.
Please send me your plugin to :
if you wish your plugin to be published.
> encoding autodetect must be called manually
> because I don't know what notification message is sent by Scintilla when opening a file
Yes, it's possible to do it.
Jens, do you remember how you did it in your Function List plugin?
There is no notification. I have done a dirty way. On every time when scintilla notifies, that the edit field will be new paint, I ask notepad the count of files and the language type. If one of this condition is true, I update all my stuff.
If you are only waiting of opening and closing new files, you could this do in another way. Create a subclassing process of the notepad handle and use the notifications that are internally used in Notepad.
If you not understand or if I missunderstand you, fell free to ask!
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.