Does anybody have any suggestions for a component to display status or terminal text that will allow limited enhancement (colour, possibly underline etc.)?

Over the last few weeks I've been tinkering with an emulator for an obsolete mechanical terminal (IBM 2741), including support for the APL character set. I started off using a listbox for simple output, noting that this didn't have provision for multiple colours or marking the insertion point. I moved on to stuffing characters into a memo, this allowed me to force a current-position marker but still had no colour.

Looking at the CmdLine component, it appears OK as a command window (i.e. accepting keyboard input etc.) but isn't so hot when the principal requirement is to display text pushed into the underlying strings storage from elsewhere: in particular, there isn't a way to force the insertion point marker to the end of what's just been output.

I'm sure I'm not the only person who wants to do this sort of thing: does anybody have any recommendations?

TSynEdit? TSynPosSyn (position highlighter, see examples)

You can remove all the SynEdit.Keystrokes. And also set it to not react to mouse, if required (use MouseActions and make them empty) You can also set the caret shape, to be a block (full char width).

If you want to loose ballast, you can remove various of the "Markup" modules...

Do you mean that that can now colour arbitrary sequences of characters (i.e. what you'd expect from a terminal emulator), rather than having to define things in advance? As an example, see
http://wotho.ethz.ch/APL-1130/2741_APL_Demo.png where everything the user enters (which starts at the 7th column) is printed in red.

Being able to use a standard component would definitely be an advantage, since particularly for this project I am very keen on a user with limited (or no) Pascal experience simply being able to grab the sources and a copy of Lazarus and compile.

But I must also ask: how long has TSynedit done this? It does appear to be one of the more fluid parts of the LCL and I'm afraid I'm a bit wary...

Yes, though it may be a bit tedious to add.

The normal way (see example):
      // Line 0, from start of line to pos 3 (3 chars) highlighted as Attr1
      Highlighter.AddToken(0,3,Attr1);
but this will do a single char
      Highlighter.AddToken(0,3,Attr1);  // Attr1 from col 3
      Highlighter.AddToken(0,4,tkText);  // text from col 4

It may be easier to write a custom highlighter - there is a tutorial http://wiki.lazarus.freepascal.org/SynEdit_Highlighter#Creating_a_SynEdit_Highlighter

samples are also in the example folder (SVN).

I assume you have a fixed amount of lines and columns? It should be easy to have it an array of attributes matching each char in each line.

----
Whatever you do: make sure to switch off the removal of trailing spaces (or you can not highlight them...)

There is a property(IIRC Options)

The pos highlighter has always been there.

What do you mean more fluid? ... (btw: SynEdit is not part of the LCL. And in is MPL/GPL at your choice, as that is what the original SynEdit is)

SynEdit had a few changes (
http://wiki.lazarus.freepascal.org/Lazarus_0.99.0_release_notes#SynEdit ) I tried to get them in before 1.0, hence so many so sudden... But most of them should not need user changes.

folding highlighters, if you wrote your own, might still be subject to change (so I hope it will not be needed, the latest change should do). That is because folding still has a lot of changes... But the basic highlighter should not need to change.

The internal representation of the Textbuffer, and it's Views will change. But that should not affect any one...

I don't think any sort of pre-existing custom highlighter will work. The requirement here is that anything- completely context-free- that the user enters is red, anything that the host supplies (over telnet, serial line etc.) is black. Either of those can be complete garbage, but should still show up in the correct colour (and should stay correct, irrespective of scrolling etc.).

(btw: SynEdit is not part of the LCL. And in is MPL/GPL at your choice, as that is what the original SynEdit is)

OK, but in effect it comes as standard which makes it attractive.

In practice (in this particular project) I'm stuffing characters directly into the items/lines property (of whichever output component I'm using). In other words I'm not using any of the component's own keyboard handling, the reason is that there are several stages of translation in between the user pressing a key and it being printed.

Mark,

I don't have any recommendations but I'm following this message thread with much interest. Last fall I wrote a "serial debug terminal" with Free Pascal and fpGUI and that program has proved to be one of the most useful simple programs I've written in a long time. I've customized it a few times already for real work projects and I also have some other projects planned. If you want to see how simple the present code is see the "DbgTerm.pas" program at this page:
http://www.turbocontrol.com/easyfpgui.htm

Right now you can't put the cursor in the terminal and send characters by typing them, but rather there are separate SendEdit and SendButton components. I'd like to implement a more standard "terminal" operation so what you are discussing here applies to that.

I'd like to keep the present DbgTerm as a very simple example of serial communications code but I will consider having a more complex terminal program too. I've run into many people who need a replacement for HyperTerminal since it has been gone from Vista and later Windows editions.

The position highlighter refers to position in text. Scrolling via scrollbar is no problem.

But if you add/remove lines; or add/remove chars in a line, you must update the positions.

I assume you have a fixed amount of lines and columns? If so it should be very simple to write a pos-highlighter (part of your project, does not need to be registerred in IDE), that has

CharAttributes: Array[1..maxLine] of array [ 1..MaxColumn] of TAttribute

Of course that is not practical if you have thousands of lines, as it would require a lot of storage....

SynEdit has a read only property. But that still allows selection and moving the caret.

If needed it can be configured to ignore all user input (the previews in the IDE option do that). That is srollbars can always be scrolled...

Since it's emulating a mechanical terminal that printed to roll paper, the number of lines is indeterminate and increasing. I suppose that I could limit it to (say) 1000, but if other people started using it there'd be bound to be somebody complain.

I think that almost everybody who has to deal with non-modem equipment or who has demanding modem requirements (e.g. accommodate a mix of incoming and outgoing calls and/or obscure protocols) ends up doing the same. Something that's particularly badly handled in off-the-shelf software is control-line handling (DTR, CD etc.).

Right now you can't put the cursor in the terminal and send characters by typing them, but rather there are separate SendEdit and SendButton components. I'd like to implement a more standard "terminal" operation so what you are discussing here applies to that.

In my case, I'm collecting keydown events from whatever the visible control is, converting them to an internal code (derived from the mechanics of the original 2741 terminal), (local echo done here), converting that to characters for the serial interface, and finally sending those to a serial line or telnet connection. Received data (which might be coded differently from what was transmitted) is converted to the internal code, written to the same queue that got the local echo, the content of which is finally converted to Unicode using a table that mimics an IBM golfball and stuffed into the stringlist that underlies the listbox or memo control.

A listbox does not have a caret marking the insertion point. A memo does, and I can generally force that to indicate the position the next keypress will appear after each character is output. Obviously that can be confused by a mouse click, but since I'm not using the control's own keyboard handler the next output character will always appear in the right place.

I'm sure all this isn't very efficient, but I am, after all, emulating the terminal that gave the World 134.5 Baud operation :-)

I'd like to keep the present DbgTerm as a very simple example of serial communications code but I will consider having a more complex terminal program too. I've run into many people who need a replacement for HyperTerminal since it has been gone from Vista and later Windows editions.

For Windows I'd point you at Teraterm, of which v1 was Pascal if you think you need to tinker. For Linux gtkterm.

I see.

Still possible (at least I think)

Highlighter stores something called a range for each line (line as in textbuffer lines, so scrolling of display does not matter) They are automatically adjusted if lines are added/inserted/removed from/to the textbuffer

So you could write a HL, that stores a list of x-positions for each line, together with the attributes. (If you edit the line itself, you need to adjust the list)
The highlighter can then return the text, cut into "tokens" (in your case each continuous group of chars with the same attributes), and supply the attributes for each token.

By default the "Range" is not freed, when the line is dropped (e.g. if it is an enum or set, then just the memory is dropped). But the highlighter allows to override that code, so it can be added.

Depends how interested you are.
I can assist, and help put together the framework, but you'll have to implement the rest.

Also to get the memory to be freed (using dynamic array for ranges), it touches a few internal methods. I do not foresee that they will change, but ....

--------------
If you look at the 1st example from the tutorial ("SimpleHl").

As I said the ranges move with the lines. And I can make it possible that you can store a dynamic array (actually pointer to dyn array) as range, and that it will be freed, if a line is removed.

The array could be something like
   TLinePosArray = Array of record
     XPos, NumChar: Smallint; // assuming a max line length
     Attr: TSynHighlighterAttributes; // could alse be an enum, that you
map later
   end;
   PLinePosArray = ^TLinePosArray;

The rest should be self-explaining from the tutorial.

Same also applies to any onscreen display of scrolling status etc., except that it doesn't have the same insertion-point requirement.

It sounds like a lot of work, shoehorning something which isn't really its forte into Synedit.

Before anything more, I'll drop a note to Cmdline's author (if he's not in here already) and see if he's got any suggestions.

Otherwise, can anybody say whether are there any stringgrid derivatives etc. that will do this?

Do you mean that when typing a command the output of the command is overwriting part of the previous output added with TCmdBox.Write or TCmdBox.WriteStream? As long as data written with TCmdBox.Write or TCmdBox.WriteStream is terminated by a linefeed (TCmdBox.Writeln('') or a #10 as last character) that doesn't happen.

Ludo

No, what I mean is that I want to literally put the marker where a mechanical print head would put the next character. In addition I want to be able to (non-destructively) backspace, i.e. the insertion point (caret marker etc.) should be stepped back towards the start of the line, and a subsequent TCmdBox.Write will overwrite.

Very much like a mechanical typewriter, since that was how terminals of that vintage behaved. There's example output at
http://wotho.ethz.ch/APL-1130/2741_APL_Demo.png (it's ETH, but I don't think there's a Pascal connection), I've got most of a standalone terminal emulator that behaves in the same way but haven't got the colour aspect working due to lack of a suitable component (and lack os sufficient skill/experience to write my own).

Have you ever seen a roll of paper, of indeterminate length? ;-)

And a mechanical terminal with multi-color ribbon? [Well, I've seen a black/red ribbon many years ago...]

DoDi

It probably will not help you but MSEgui has "tterminal" for the purpose. It is based on the "tcustomtextedit" widget. "tcustomtextedit" and its descendents (ttextedit, tundotextedit, tsyntaxedit, tterminal...) should be placed into a "twidgetgrid" and builds a text editor column in the grid. The underlying cell datatype is "richstringty", a UnicodeString with per character font style and color info. tterminal can start processes and read and write pipes.

Martin

When you got already that far with Tmemo, try the TRichMemo which is a TCustomMemo descendant which allows changing font attributes in the text. It has also a LoadRichText and SaveRichText so that you can save the colored text to file.

Ludo

Doesn't help but is worth knowing ;-)

Yes. I've also seen all sort of printer problems which can cause the number of lines that will fit on a piece- let alone a roll- of paper by 100%.

And a mechanical terminal with multi-color ribbon? [Well, I've seen a black/red ribbon many years ago...]

Yes. And more to the point, the terminal that I'm emulating /specifically/ has a black/red ribbon which is used in a definite way- as shown on the link I posted.

Thanks for that, I'm on it.

I should have been referring to this as CmdBox rather than CmdLine, but I think we're talking about the same thing. For the benefit of Paul and anybody else following this, here's what its author (Julian) has to say:

I'll probably be coming back to this at some point. I'm not entirely convinced that for full-duplex operation a localised modification to StartRead() will do the job, needs experimentation.

Mark, please trim your quoted text in future posts! It is ridiculous to scroll three pages just to find a 2 line reply.

Graeme Geldenhuys wrote

Mark, please trim your quoted text in future posts! It is ridiculousto scroll three pages just to find a 2 line reply. -- Regards, - Graeme - --_______________________________________________Lazarus mailing ://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Graeme, if you'd been paying attention you'd have seen that my last posting was a summary of discussion with CmdBox's developer, and had not otherwise been posted in this mailing list.

Mark Morgan Lloyd wrote

Graeme, if you'd been paying attention you'd have seen that my last posting was a summary of discussion with CmdBox's developer,

All communications are archived and searchable, so there is no need to quote 3 levels deep and pages and pages of duplicate [quoted] information. That is very inconsiderate to others.

Graeme Geldenhuys wrote

On 18 May 2012 10:36, Mark Morgan Lloyd wrote:> Graeme, if you'd been paying attention you'd have seen that my last posting> was a summary of discussion with CmdBox's developer, All communications are archived and searchable, so there is no need toquote 3 levels deep and pages and pages of duplicate [quoted]information. That is very inconsiderate to others.

Graeme, you, of all people, don't get to search my personal machine for discussion I've had directly with a developer which does not appear elsewhere in a mailing list, usenet group, Facebook, Twitter or whatever degenerate dives you are wont to frequent.

:-)

2012/5/18 Graeme Geldenhuys :

for simulating a terminal with SynEdit you might also find this helpful: https://github.com/prof7bit/HaskellTool/tree/master/src

in console.pas there is a TConsole that you just create and give it a reference to the synedit. It currently has the ghci executable hardcoded into it but this could also be a shell or some other interactive command interpreter. In main.pas I just create an instance of it and pass a reference to the right hand side synedit to it and then it takes full control over this synedit and works pretty much on its own.

This does NOT solve the coloring problem (the highlighter that is also contained in these sources is attached only to the edits on the left side and is a conventional very simple highlighter for haskell syntax).

What it does do is demonstrating that simulating an interactive command prompt with TSynEdit is not so difficult at all.

2012/5/16 Mark Morgan Lloyd :

Does anybody have any suggestions for a component to display status or terminal text

for simulating a terminal with SynEdit you might also find this helpful: https://github.com/prof7bit/HaskellTool/tree/master/src

in console.pas there is a TConsole that you just create and give it a reference to the synedit. It currently has the ghci executable hardcoded into it but this could also be a shell or some other interactive command interpreter. In main.pas I just create an instance of it and pass a reference to the right hand side synedit to it and then it takes full control over this synedit and works pretty much on its own.

This does NOT solve the coloring problem (the highlighter that is also contained in these sources is attached only to the edits on the left side and is a conventional very simple highlighter for haskell syntax).

What it does do is demonstrating that simulating an interactive command prompt with TSynEdit is not so difficult at all.

Mark Morgan Lloyd wrote

Graeme, you, of all people, don't get to search my personal machine for discussion I've had directly with a developer which does not appear

What are you talking about!!!! I was replying to your messages that are PUBLIC in the Lazarus Mailing List.

"Graeme Geldenhuys" wrote

On 18 May 2012 11:04, Mark Morgan Lloyd

And he wrote that he had inserted the contents of a private discussion in the mail you answered to.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120518/703ef17f/attachment.html>

Graeme Geldenhuys wrote

On 18 May 2012 11:04, Mark Morgan Lloyd wrote:>> Graeme, you, of all people, don't get to search my personal machine for> discussion I've had directly with a developer which does not appear What are you talking about!!!! I was replying to your messages thatare PUBLIC in the Lazarus Mailing List.

Graeme, I am going to spell this out in short words, and I hope that my irritation doesn't offend anybody. My apologies in particular to the list managers if they feel I am out of order.

You are objecting to a message I posted at around 16:00 yesterday. The bulk of that message derives from a discussion I had with the CmdBox developer via email plus a bit at the top for context so it shows up sensibly in Google.

The bulk of the message HAD NOT previously been published, it WOULD NOT show up on Google or any comparable service, and I went to the trouble of posting it since I knew that there was at least one other person in this list watching the thread with interest.

Now, since you've not been able to contribute anything useful would you be so kind as to withhold further comment?

Graeme, I am going to spell this out in short words,

Hey Mark,

Let me spelling it out to you... No wait, maybe you only understand pictures. Attached is a screenshot showing three of your "over quoted" replies! I WASN'T referring to a single message (that would be wasting my time), but to the whole thread in general.

In the screenshot, the text in purple is quoted text by you. Text in black in new content you provided!

You idiot! Next time, check your own messages before you make idiotic comments like you just did.

Anyway, where is the mailing list moderator when you need one!

Graeme Geldenhuys wrote

Let me spelling it out to you... No wait, maybe you only understand pictures. Attached is a screenshot showing three of your "over quoted" replies! I WASN'T referring to a single message (that would be wasting my time), but to the whole thread in general.

So why did you not specify that in your message? Or why didn't you reply to the message that offended you?

In the screenshot, the text in purple is quoted text by you. Text in black in new content you provided!

In none of the messages in your screenshot you would need to scroll. In only one of Mark's emails in this thread I had to scroll to start reading his reply, and that's probably because I only use half a screen to view messages. He could have trimmed more, but probably felt that he needed to provide context for his reply.

You idiot! Next time, check your own messages before you make idiotic comments like you just did.

While Mark's reply has been civil, you sound like a screaming teenager now.

Henry

Henry Vermaak wrote

So why did you not specify that in your message? ?Or why didn't you reply to the message that offended you?

OK, now this is becoming ridiculous. Should I have replied to every of Mark's 20 odd messages (in this thread alone) saying that he over quotes to much! NO, I just replied to the last message he sent at that time.

In none of the messages in your screenshot you would need to scroll.

FFS I had to reduce my Chrome browser's zoom factor to 33% (100% is normal text size) to take that screenshot. In this message thread and in others, I need to scroll 99% of the time when Mark replies (using my Chrome browser at the normal 100% zoom level). I simply got sick and tired of this, and seeing that the mailing list moderator is not doing his job, I thought I would say something. Simple netiquette is known by most people - especially developers that partake in mailing lists or news group discussions.

I hate scrolling, just to see what somebody said in their reply. So often I wouldn't even bother following that thread after a few messages like that. Other people, for example the visually impaired - that use screen readers, would find it infinitely more annoying that I!!

So a little bit of common decency (netiquette) goes a long way.

Yes, I realise that. Which is why I reviewed all his messages in the thread, finding that I only needed to scroll once (using half a screen in icedove). This was in my reply to you, but you failed to quote that part, which I find more irritating than failing to trim messages.

So a little bit of common decency (netiquette) goes a long way.

That's incredibly ironic coming from you, having just called Mark an "idiot".

Other people seem to have (wisely) refrained from replying to your vitriol. I'll do the same.

Henry

Graeme Geldenhuys wrote

On 18 May 2012 15:14, Henry Vermaak wrote:>> So why did you not specify that in your message? Or why didn't you> reply to the message that offended you? OK, now this is becoming ridiculous. Should I have replied to every ofMark's 20 odd messages (in this thread alone) saying that he overquotes to much! NO, I just replied to the last message he you boer of little brain, I'm a fairly frequent user of this list

and if anybody- particularly a list manager- wishes to point out that a particular message goes against "house style" I'll do my best to conform- or apologise. As it is, I do make a point of chopping lines from the top of messages but not to the point that an individual message is devoid of context (RFC 1855 page 7).

For you to append your criticism to the one message I've posted recently that couldn't be drastically pruned because the bulk of it was "private correspondence", as we used to say in academia, doesn't exactly help make your point.

And has it occurred to you that this is a mailing list, and that Chrome might not be the most appropriate client?

Cordially,

Mark Morgan Lloyd wrote

I'm a fairly frequent user of this list and

Yes, that makes your over quoting even more annoying.

particular message goes against "house style" I'll do my best to conform- or apologise.

Yeah the list manager is Lazarus seems rather slack - I guess he has more important things to worry about. Maybe I should just mention the G*t work to get his attention.

For you to append your criticism to the one message I've posted recently

As I stated, my original message was just a reply on your latest message, but applies to ALL your messages in this mailing list. THERE IS NO NEED TO QUOTE 3 LEVELS DEEP FOR A ONE LINE REPLY!

And has it occurred to you that this is a mailing list, and that Chrome might not be the most appropriate client?

Oh, since when is there a restriction on what email clients we may use to read our emails!

[Graeme signing off because Mark is wasting his time]

The good news is that TRichMemo is a painless replacement for TMemo, despite my various hacks and admitted inexperience. However, when I'm using SetTextAttributes() or SetRangeColor(), should the position parameter be based on the number of bytes or the number of characters of existing text? I'm having problems getting this right, which I suspect are due to the high proportion of non-ASCII characters.

Or put another way, in the simplest case where I want to change the colour of the most-recently-added character, what parameters should I be using?

Don't know what function you are using to add the characters but here is a routine that will paste from the clipboard in red at the cursor position:

procedure TForm1.Button1Click(Sender: TObject);
var
  selbegin,sellen:integer;
begin
  selbegin:=RichMemo1.SelStart;
  RichMemo1.PasteFromClipboard;
  sellen:=RichMemo1.SelStart-selbegin;
  RichMemo1.SetRangeColor(selbegin,sellen,clred);
end;

Tried this on windows by pasting chinese characters with the cursor in the middle of an existing text: only the pasted characters are colored red. So the trick is to get the cursor position before and after the insertion and take these values to define the range, then color that range. Whatever the characters inserted, single byte or multibyte, the cursor position reflects this correctly.

Ludo

Thanks. I didn't get this working reliably but I'm fairly sure that's self-inflicted: I'm dropping it for the moment but will go into a bit more detail in case it's relevant to anybody else considering terminal emulators etc.

I started this off by outputting to a TListBox, appending text directly to the underlying strings. This worked, but line-spacing was a bit unnatural and there was no cursor support. I then added output via a TMemo- reusing as much of the existing code as possible, the result of this is that I'm not going via any of the "obvious" ways of adding text so had to fudge cursor handling- which I suspect I have done imperfectly.

Revisiting this to look at adding colour was originally done because I wanted to familiarise myself with TCmdBox for another job, however while it's obviously good for handling local commands etc. I don't think it's appropriate for character-by-character terminal operation. For the latter, in cases where "paper roll" operation is required (as distinct from a terminal with cursor positioning etc.) I think that TMemo/TRichMemo are probably the tools for the job, in particular my code to intercept keydown events works well enough that I can simulate an APL keyboard. I suspect that the "correct" way of displaying received characters is by pushing them through simulated keypress events- I've certainly been able to force UTF8 into a SynEdit in the past by using IntfUTF8KeyPress() but I believe that LCLSendUTF8KeyPress() may be preferred (albeit a recent addition).

I don't know what the best choice would be for writing a terminal emulator that required accurate cursor positioning, i.e. a VT-52/100 emulation with "go to X,Y" capability rather than simply stepping between adjacent cells. As things stand at present, I suspect that it would require a purpose-built component- which is something that I have neither the skills nor time to contemplate. Fortunately, I rarely need that sort of thing for the equipment I need to talk to, and when I do using Teraterm (Windows) or gtkterm (Linux) or a Lazarus hack based on a DrawGrid is generally adequate.