Beta 1.50

[alex]

From my current vision, 1.50 can be now turned to a beta stage. What this mean:
- 1.49 will get only small bug fixes and will be updated without beta testing. Nothing new, only critical and small corrections.
- all big fixes will be done in 1.50. If you report something, found in 1.49, you will need to retest it in 1.50
- now you can report bug and feature request for 1.50. But until 1.50 release, only correction/optimization to existing already in 1.50 functionality will be accepted. I will not add new features to 1.50 itself but they can appear in 1.5x.
- scripting is ready and most of new requests will be implemented as script plug-ins or tools scripts. Please test this functionality, because after release changing of the API will be hard.
- after release of 1.50, line 1.4x will be closed and I will not provide any bug fix support for it.
- for some time, 1.50-1.53 probably, I will keep new features adding to 1.5x branch, after, new features will go into 1.6x line.

HippoEDIT 1.50 for Win 32 bit (Unicode)
HippoEDIT 1.50 for Win 64 bit (Unicode)
HippoEDIT 1.50 for Win 32 bit (Non-Unicode)

*All installers contain PDB files for better crash reporting, so sizes are rather big (approx 18 mb), but this does not influence performance.

From 1.5x version I drop support for Windows 98 and Me. 98/ME Version will be kept as non-Unicode alternative, but will be renamed to HippoEDIT NU. Reason to keeping it, is twice less memory consumption for files, so you can open bigger log files etc. The minimum supported Windows now is Windows 2000.
One of prerequisites is gdiplus.dll (Standard MS dll, installed on most modern systems), but it only required if scripting used.

The most of the features are already done, but some parts are left. Particularly:
- big bug fix for regular expression search/replace (problems around multi-line search replace)
- on-line functionality. This part is completely independent and should not influence stability of the rest.

HippoEDIT as a plug-in (see description below) was postponed.

Yes, now it is a BETA, but still I suggest to not use it productive, at least until you will not be sure, that it is stable enough. I am not yet sure

If you see that some plugins are not found, but you have installed them ( for example Spell Checker or File Explorer), than it is probably MFC libs are missing.. Please uninstall editor (not full uninstall), install Microsoft redistributable modules for VS 2005 and re-install HippoEDIT. For x32 versions you need vcredist_x86.EXE for x64 vcredist_x64.EXE.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Briefly, what is planned for 1.50:

• Enhancements for Find Output widow. Switching from plain output to tree output. Results can be grouped by lines, file names, searches. Editable - you can delete some results you are not interesting in. Marked as visited. The searched text would be highlighted in line preview. This should help a lot if you do Find In Files and then check results, visiting one by one.
• Spell Checker. Background spell checker that would examinate comments and strings (all styles that have text property set to 1). With interactive search dialog, suggestion list etc. Which engine would be used is not clear yet
• Scripting / Macro support. Support for recording/replaying macros in HippoEDIT, based on embedded scripting. Microsoft Active Scripting technology would be used that enable HE to use most of the scripting languages for writing scripts (JavaScript, VBScript, Perl, Lua etc). Add your comments here.
• HippoEDIT as plug-in for external applications. I am planing to have embeddable version of the HE (only editor window, without main menu, toolbars, panels etc), which can be used as viewer/editor in other applications. As MS Outlook attachment previewer, as Vista file previewer, as Total Commander editor List plug-in, as FAR manager editor plug-in, as MS Visual Studio editor plug-in. In addition same control can be used in several areas of HE itself. As editor for Code Templates window, as Viewer for Output results, as Tooltip viewer
• Command interpreter/Command console. Possibility to not only catch output form tool, but also to forward input to them. Maybe to have more then one Output windows to run several tool in interactive mode simultaneously
• On-line Functionality. Possibility to see directly in the HE Syntax Setting node list of the syntax schemes from server (in addition to already installed). With versions and Update, Install functions. Also, if you have some schema not existing on server, you should be able to upload it on server (in Purgatory) to be available for other users. If you open a file with unknown extension or syntax, HE should check on server for suitable schema and suggest you to download+install it.
• Internal Plug-in Framework. I would also evaluate what is possible to be done for plug-in infrastructure inside of HippoEDIT. For example to add additional panels (as File Explorer or Project Explorer). This would be first step to have additional windows as Clip Text, Function List, Open Windows, Clipboard content etc. But everything depends from progress with main topics, listed before.

**************************************************************************************************

Brief overview of what are already done:

• Optimization for multi core processors (search, load from files, word wrap etc).
• Recognition of not open close tags
• Virtual (search) folders for project
• Memory optimization for large files
• Changes for Quick Search bar: regular expression can be used, check box moved to edit field menu etc
• Colored Indent guides
• Colored Braces
• Persistent Undo for files open (workspace specific)
• Filtering/search for options
• Enhancements for Find Output widow
• Simple Macro support (separated from scripting)
• Interactive page width changing
• Changes in File Open dialog
• Evaluate command (execute after = or for selection) and Evaluation Informer (shows result of the selected expression on
  hover)
• Spell Checker plug-in, based on Hunspell. With background and interactive checking. Can be accessed with toolbar buttons or menu entries in Edit sub menu. If word is misspelled or duplicated, and marked in text, with context menu you can correct it in place. Plug-in options page is available in settings dialog.
• Ordinary syntax highlighting (as in MS Word) with new toolbar button or Edit->Text Highlight menu entries. Selection is permanent and stored in file satellites between sessions.
• Additional styles for Smart highlight. Permanent during session (not removed automatically on cursor move)
• Code completion in all text fields allowing template arguments and all path fields
• Assignment filter for File Association dialog
• Status bar now keeps type color till next message
• Enchantments for tooltip formating and Quick Info tool tips
• Outlining bar now can show overlapping indicators
• File Explorer plug-in
• Bookmark Manager plug-in
• Project Explore as plug-in (but built-in)
• Embedded projects (you can include project in project, aka solutions)
• Panes can be closed/open separately (close button closes active tab)
• Separated output windows for different tools with own color scheme (check output settings for tool)
• Different types of tool output consuming: output window, replace selection, replace document, tooltip, new document etc (check output settings for tool)
• Windows 7 support: task bar progress bar, Task Bar Jump Lists, Task Bar Quick Actions, Task Bar Thumbnails for open tab windows with preview.
• Scope exists: display margin indicator for syntax constructions lead to exit from scope (as return, break, continue etc) based on syntax definition. Now only added to newest cbase spec and php spec, but can be added and to the rest of definitions later. See Tools->Options->Editor->Display
• End Tag Annotations: editor display comment like annotations after close tag in the document, if distance between scope start tag and end tag is big enough and there is no other text after the end tag in the line. See Tools->Options->Editor->Display
• Better mouse support: horizontal scrolling with scrolling wheel, back/forward navigation for xbuttons, high precision mouses support
• Path editor for File Explorer added
• Persist clipboard content between sessions
• Untitled files saved silently between sessions as temp files
• Scripting: tool scripting support, scripting dialogs support
• Multi key keyboard shortcuts

[Arthur]

I suggest to implement a Plug-in from Server "download 'n install" as well (similar perhaps to JEdit).

[alex]

Yes, this is a good idea, but I think I would not do this in 1.50. Because it first requres of implementing plugin infrastructure. And this is would be too much even for major release (let see). Anotehr good example of such downloadable plugins is Miranda IM and Firefox of course.

[Arthur]

Besides, any idea when the new beta will be out?

[alex]

Currently I have no idea.
I am busy with bug fixing for 1.42 (this is more important to me) and some website work for publishing syntax bundles.
When I got a free slot I would start with 1.50.

[Arthur]

Re:

Spell Checker. Background spell checker that would examinate comments and strings (all styles that have text property set to 1). With interactive search dialog, suggestion list etc. Which engine would be used is not clear yet

you may want to take a look at http://www.codeproject.com/KB/recipes/spellchecker_pp.aspx

PS: To obtain the needed dictionaries may not be too-too easy.

[alex]

Hello Arthur,

thank for the link! I am periodically cheking articles on codeproject, but do tno remember this one.

The main point as you have mentioned not an engine itself, but dictionaries.
Because of that I thought about huhnspell (it I wrote it correclty), which is used by Open Ofiice, because it already has a lof of dictionaries.
In the case of using some GPL open source code, I think shell distribute the source code together win binaries (Ok, this is not a problem, while I am planning to have a spell checker as a plugin). Also dictonories could not bi distributed togeter wih HE, but I can include link to page where user can downlad them and instruction how to install.

Another alternatve is to use MS Office spell API, but in this case there are a lot of problems with compatibility (as I know), because different versions of Ofiice use different APIs, and you need to write plugin for every office version.

[timohayes]

A viewer plugin for Directory Opus would be really great!  They have one already for Scintilla (http://resource.dopus.com/viewtopic.php?t=1235), but a HippoEdit one would be just perfect!

[alex]

Hello Timo,

thanks for suggestion. I think if I would successed with plugin for Total Comander, creating of plugin for Direcotry Opus would rather small effort. I would evaluate this.

Best regards,
Alex.

[samuel1991]

I sugguest that if possible, the syntax files are automatically hosted on the server. When a user needs to use it, it will be automatically downloaded to his/her syntaxes folder.

[samuel1991]

I hope that from Version 1.5 onwards, HE uses a .enu or sort of to display language properties. This is an idea that make localizers easily to localize this software. Also, the auto correction, auto spelling, if possible, make it into other languages as well (Well, maybe languages like Chinese or Korean is diffcult, but maybe German or French or Latin? See our community has which native language speakers then)


PS: I do not understand German,French or Latin etc.

[alex]

Hi Samuel,

thanks for suggestions.

I sugguest that if possible, the syntax files are automatically hosted on the server. When a user needs to use it, it will be automatically downloaded to his/her syntaxes folder.

Can you please explain what is a difference to planned in 1.50 Online functionality. By design it would have all syntax bundles hosted on hippoedit server and you can install them or explicitly in available syntaxes list or by demand when file with extension of syntax not installed open. You suggest to have user dependent sets hosted on server and load them automatically during installation?

I hope that from Version 1.5 onwards, HE uses a .enu or sort of to display language properties. This is an idea that make localizers easily to localize this software. Also, the auto correction, auto spelling, if possible, make it into other languages as well (Well, maybe languages like Chinese or Korean is diffcult, but maybe German or French or Latin? See our community has which native language speakers then)

Sorry, this was unclear. Specially HE uses a .enu or sort of to display language properties. I was planing to have native language dependent sets for auto correction, but main problem was that it is verz difficult to recognized mixed native language documents... Maybe the option can be to have two list active in same time: English and + additional local (Chinese, Russian, German) set. By the way if somebody has such set in any format, send it to me I would try to add something like this.

Best regards,
Alex.

[samuel1991]

Oh, firstly,

I sugguest that if possible, the syntax files are automatically hosted on the server. When a user needs to use it, it will be automatically downloaded to his/her syntaxes folder.

, my bad for talking half. As far as i know, all syntax are in the server and can be downloaded on demand. Yes, it can be a web-based installed when there is an active connection. (So the installer can have all syntax options but as u mentioned, may have "lazy people" that just set full & forget it issue. (After all, still not much a waste, I think as now HDD are almost more than enough space.)

I hope that from Version 1.5 onwards, HE uses a .enu or sort of to display language properties. This is an idea that make localizers easily to localize this software. Also, the auto correction, auto spelling, if possible, make it into other languages as well (Well, maybe languages like Chinese or Korean is diffcult, but maybe German or French or Latin? See our community has which native language speakers then)

Well, this idea is taken from Adobe Acrobat forthe .enu (English US language file). This software, everyone knows have various languages. So the chinese version typically have a filename extension of chs or cht (Simpilifed or Traditional respectively).
This is an localized dll. And we can expect to see HE German, HE Chinese where all the interface is in our localized language etc.

Also, the auto correction is another issue. I was suggesting at least a english-like language (Languages that uses alphabets) to have auto correction such as German. (Many German spelling just differs from English but still uses alphabets right?)

[alex]

OK. Now clear.

I sugguest that if possible, the syntax files are automatically hosted on the server. When a user needs to use it, it will be automatically downloaded to his/her syntaxes folder.

So you suggest to not place a syntax bundles in installer directly but have a link to server and download them on demand. Yes, this is possible, NSIS installer allow this. But once more somebody can select all. And as I said problem is not in HDD or installer size, but in automatic activation of all syntaxes in HE. Uses would get huge list in New or Syntax menues and in settings.

I prefer to add online functionality directly to editor, and then let see if initial installation would be required by users...

hope that from Version 1.5 onwards, HE uses a .enu or sort of to display language properties. This is an idea that make localizers easily to localize this software. Also, the auto correction, auto spelling, if possible, make it into other languages as well (Well, maybe languages like Chinese or Korean is diffcult, but maybe German or French or Latin? See our community has which native language speakers then)

Understood. You talk about localized resource dlls, which are standard way for application localization. But this way has some weak points as you need to keep all languages in sync and always update then all and could not have a fall back on default English if some text is missing in destination resource dll. This was one point and another one, translation in such way producing best results, but need to be done always with involvement of the developer  and cod not be done by user itself... So I prefer to have a xml file with localized strings and dialogs that can be changed by users... But probably this would be a topic for 1.6x...

With auto correction, nobody has requested yet localized correction list by I am keeping this in mind.
 

[samuel1991]

I see, great idea!