The question is rather,
- are there special comments embedded that say "{%display-after-this-line img xyz.png}"?
- or is there an external map file "unit1.imgmap" that contains: "line=211;img=xyz.png"?
The original idea, what I suggested myself, was
not to touch the contents of the unit/file. The source code file
was not supposed to contain any information about embedded images (no comments or special directives).
Information about the images would be in an external file (in serialized form, such as
.lfm or
.lrs), this file would be loaded by the IDE, the images would be deserialized and passed (as objects) to
SynEdit along with information about where the image should be displayed (and other parameters).
Also the original idea was that the image should be visible all the time, like in PDF or Word documents. The image should be easily moveable (using the mouse + some keys) and also be rendered behind the text (in code editing mode, which is basic mode) or in front of the text (in image editing mode).
The latter meaning, that anyone who doesn't want the images, will not even be bothered by some cryptic comment.
Exactly. If handled images as I suggested, then someone who doesn't want to see images in code would never see them and wouldn't even know that images can be embedded. Also, would never deal with such a special image resource files, because if someone will not embed any image, then the IDE will not create an image resource file.
A few days ago I was looking at the
SynEdit source code and I was able to get the component to render the image pretty quickly. Quick test, ugly hack (see hinghlighted line) in the
TCustomSynEdit.Paint method:
Include(fStateFlags,sfPainting);
Exclude(fStateFlags, sfHasScrolled);
TSynPaintEventHandlerList(FPaintEventHandlerList).CallPaintEventHandlers(Self, peBeforePaint, rcClip);
FScreenCaret.BeginPaint(rcClip);
// Now paint everything while the caret is hidden.
try
FPaintArea.Paint(Canvas, rcClip);
DoOnPaint;
// paint images here
finally
UpdateCaret; // Todo: this is to call only ShowCaret() / do not create caret here / Issue 0021924
FScreenCaret.FinishPaint(rcClip); // after update caret
TSynPaintEventHandlerList(FPaintEventHandlerList).CallPaintEventHandlers(Self, peAfterPaint, rcClip);
{$IFDEF EnableDoubleBuf}
EndPaintBuffer(rcClip);
{$ENDIF}
Exclude(fStateFlags,sfPainting);
Include(fStateFlags, sfHasPainted);
end;
end;
The image was displayed nicely in the editor window in the right place and, interestingly, reacted to scrolling. However, the image was always rendered over the line content (over text, line selection, breakpoints, etc.) and the caret always over the image, which looked pretty funny (but at least the caret was always visible).
From my research, it turns out that my proposal can be implemented and act correctly, but the component code would have to be modified so that rendering the content of the line interacts with images. All the problems you raised,
@Martin_fr, have a solution, so all you need to do is simply modify the code of the component — either permanently change its code, or rework it in such a way that you can overwrite some things (methods) from the plugin level and thus have a complete control over content rendering and content modification handling (the plugin would need to know when lines are added and removed). You'd also need to override mouse and keyboard handling to allow for two
SynEdit modes — code editing and image editing.
The only problem that cannot be solved (taking into account my proposal) is the support for embedding images in conjunction with enabled word wrap. Therefore, to implement my proposal, word wrap would have to be disabled and locked in this state (which would be the only sensible solution). Anyway, I'm not going to use word wrap anyway, because I don't see any sense in wrapping source code lines, so disabling this function wouldn't bother me at all.