About the Joy of Writing an Editor

[jj2007]

Just for fun, a new simple editor - just 111 lines of code

Features:
- search with listbox for found matches (RichMasm style)
- select a word and hit F3 to find all matches
- build all button (or hit F6; you need to extract the bldall.bat to the same folder)
- multilingual interface
- remembers last document opened, i.e. just launch the exe to see the last source you worked on
- 8 files MRU menu
- reads plain text *.asm and Rich Text Format (*.asc, *.rtf) sources
- handles spaces in folders and filenames properly
- drag and drop enabled
- handles Unicode filenames properly
- no need to save your current edits, just hit the F6 key (but do save that precious stuff when closing the editor...)

Version 3 attached, with small improvements but still 111 119 lines short. The archive contains everything needed to build the editor with MasmBasic version 6 December (check the Rsrc section for proper locations) - please let me know if there are any problems

Inter alia,
- the language menu is now a submenu of &File
- the chosen language will be remembered when reopening the editor
- there is a Project menu with Console vs Windows build, plus an item "copy source path to clipboard"
- added some checks for safer editing

Attached is also the Excel spreadsheet that defines the GUI elements - over 700 strings. I am aware of Biteriders thread, and wish him luck in his endeavour. However, I believe that the GUI is too complex to hand it over to a Google API.



I chose to rename the batch file to buildSE.bat, in order to avoid name conflicts. There is still no provision for linking resources; usually, I check for the presence of <filename>.rc, then for rsrc.rc

Note that SimpleEditor != RichMasm. Big Brother's source stands currently at over 24,000 lines, and obviously many features are missing in this simple editor (like autoindent, bookmarks, WinApi tooltips help, edit history...). The image below shows the SimpleEditor source in RichMasm:

[jj2007]

Below the snippets necessary to create and manage the most recently used list in SmallEditor's File menu:

  SetMru "EditorDemo.ini"            ; use this ini file for the most recently used files list
  void Ini$()                                   ; load SimpleEditor.ini
  SetMenuLanguage Val(Ini$("Language"))
  SetGlobals MyEd$="Simple editor:", CurrentFile$, x$
  Let CurrentFile$=uCL$()                      ; get the commandline
  xchg eax, ecx
  If_ byte ptr [ecx]=="#" Then Let CurrentFile$=Mru$(0)         ; load the last file (unless a file was passed in the commandline)

...
Event Menu
  Switch_ MenuID
  Case_ MruFirst .. MruLast: <xCall @Open, MruText$()>          ; open file from Most Recently Used menu

...
Event Close
  StoreUtf8 Cat$(MbExeFolder$+"\EditorDemo.ini"), Mru$(), 8    ; register up to 8 filenames

...
AddMru CurrentFile$     ; add to recent files menu

In SmallEditor, the MRU looks exactly as RichMasm's MRU, see below. In order to ease navigation, the name of the current folder is being added (there is an option to add more levels, PM me for details).

Since I have always several projects running in parallel, I couldn't live without a decent MRU implementation. Actually, I struggle to keep it below the 25 files maximum

[jj2007]

jj,

Where we differ is in something very fundamental, the idea of automated actions combining a number of things together. While it is no big deal to auto-format in much the same way as the old GFABASIC editor, long ago I learnt that it comes with a multitude of evils. When it does something that you don't want, you have to try and undo it and with auto formatting, that is not always an easy task.

I wanted back then a pure ASCII editor which I eventually wrote that was entirely free of automated actions. My later editors all have the same brain, NO automated combined actions, each user choice is a separate action, not something the editor overrides. A liking for pure ASCII characteristics delivers a predictable and reliable means of writing code.

Now they do have a few tricks, block indent, tabs replaced with spacers and a reliable autoindent that does what it was designed to do, indent the following line with the same indent as the current one.

Dear Hutch,

Of course, I understand your KISS (Keep it simple, stupid) logic, and for a n00b who arrives here to write his first "Hello World", it's perfect. However, at currently over 6,000 source files in *.asc format, my needs are different. The n00b learns to drive, so a simple, small car is perfect for him; I need a Mercedes, a Bentley or a Tesla.

You are not a fan of MRU's, for example. Ok for n00bs, but I struggle with my 29 files limit.
Your Find & Replace dialog is Windows standard, mine is very advanced
Your F3 key makes the user jump to the next found item, I need to see the hundreds of matches in my 30k LOC source.
QEditor has no history, and that's ok. But I work on a source that, according to MS Word, has 634 pages. If I have to switch all the time between pages 9, 512 and 312, I appreciate that I can do it by simply pressing Alt arrow left/right, because RichMasm remembers the last 8 edit places.
QEditor has no shortcut keys, and that's ok for n00bs. But I appreciate that ism<space> expands to invoke SendMessage, - typing that a hundred times is tiresome. \Masm32\MasmBasic\Res\Keywords.ini has over a hundred shortcuts, and most of them I've never used. But I would go mad if I didn't have that feature.
Do I need over 30 entries in the Help menu? Not every day, and not all of them.
Do I need 15 AutoCode entries? Not every day, and not all of them, sure, but I need them, and I also need the tooltips in the menu explaining to me what each of them does.
Do I need manual colouring to understand a tricky sequence that I coded 10 years ago? Absolutely, I would be lost without that feature.
Could I live without WinAPI tooltips, see below in the lower left corner? Difficult.
Could I live without bookmarks, see below? NO.

You are a prolific coder, too, and I have a deep respect of your work for this site. That you can do that without a MRU list is, ehm, interesting. Maybe we just have very different coding styles: you work sequentially, i.e. you finish one library item at a time, while I have always a dozen projects running in parallel, and never finish them ;-)

Keep up the good work

[hutch--]

jj,

It has to do with the narrowness of focus that I undertake, I write editors essentially to write code and while they handle plain text documents as well, the primary focus is ASCII format code. I do have a RTF editor for making my current format help files but that is only for display purposes so the help files are easy to read.

You are doing a much wider range of things that I undertake with coding editors and I would imagine that has much to do with the difference in approach.

If I am guilty of anything, its austerity, a version of Occam's razor, do what you must do and make sure it works correctly but do nothing more. While its easy enough to do, my editors do not play music, show video, write WORD documents, Excel spreadsheets, they just write ASCII code for compilers and assemblers.

[jj2007]

The transition from RichEd20.dll to mfstedit.dll is done, and it was really tough - buggy monsters, both of them, but with different problems. It's a long story. Inter alia, I had to dive into COM, i.e. the dreaded TOM interfaces.

Attached a beta, grateful for feedback on bugs, handling glitches, etc

Among the changes:
- RichMasm is now over twice as fast in loading files, compared to the fast RichEd20.dll versions. The source, for example, loads its 24,000 lines in 0.4 seconds on my trusty old i5. Once upon a time I had inserted a complaint on Murray Sargent's blog, but they removed it
- a new function HexDump of selected text (that was useful for chasing bugs, so I added it)

There is much more, but I didn't keep a log



P.S.: RichMasm has a built-in profiling function. Press F9, hold Ctrl and click NO to see it.

Name              #called   total time   per call
FindBookmark           11       220 s    20057 ms
GetIncludeText      22340       210 s     9404 us
SubRE               65136       181 s     2783 us
SetLcBufferP          356       162 s      456 ms
DrawPics              353       161 s      457 ms
CbTimer             10477       132 s       12 ms
StartFind               4        95 s    23949 ms
MyTest                 14        65 s     4674 ms
WndProc             10426        20 s     2003 us

after adding tfHasINCLUDE and tfHasPics:
Name              #called   total time   per call
SubRE              102262        22 s      220 us
WndProc              8707        16 s     1840 us
CbTimer              1283        12 s     9703 us
ReOpenFile              1        11 s    11634 ms
SubList             52065        10 s      203 us
LbSel                 409      8580 ms      20 ms
SetSelFromB           411      8575 ms      20 ms
SetLcBufferP            3      8334 ms    2778 ms
ShowLineCol           103      7386 ms      71 ms

After discovering that the GetIncludeText and DrawPics functions cost an awful lot of cycles, I added two switches, and now it's at least a factor 20 faster with big files.

For example, my bible.txt*50 with over 200MB loads very smoothly, with really fast search results. However, it loads a factor 3 faster on my ten-year-old trusty old i5 on Win7, compared to my brand new Athlon Gold 3150. That could be the cpu (unlikely, it should be 50% faster then the old i5-2450), but it could also be the fault of Windows 10. A slow msftedit.dll maybe?

[jj2007]

The MasmBasic package has been updated. Here is a list of recent macros, most of which are documented in \Masm32\MasmBasic\MbGuide.rtf (PM me if not):

Code Select Expand

2022-07-28 GuiImageSet
2022-07-28 MbProfile
2022-07-28 SetIni$
2022-08-11 Json$
2022-10-02 Choose$
2022-10-02 FontExist
2022-10-27 ClipboardImageWH
2022-10-27 uBytes
2022-12-07 CenterWindow
2022-12-07 Guid$
2022-12-07 IntAsWords$
2022-12-07 xCall
2023-01-11 BitSort
2023-02-23 _dw
2023-02-23 VirtualPath$

RichMasm (included in the package) runs now with C:\Windows\System32\msftedit.dll, RichEdit50W. It is the buggiest RichEdit version so far, but I found workarounds for all problems. I've chosen this one because a) it's full Unicode and b) it's so far the fastest version I've found, at least on Win7. If you are running Win10, PM me for a faster version.

[jj2007]

Just for fun, a new simple editor - just 111 lines of code

Now it has 444 lines of source code, and it moved to the Simple editor thread.