SemWare's TSE mentioned on HackaDay

[S.E. Mitchell]

In an article about WordTsar - a WordStar clone - TSE was mentioned in
the comments:
https://hackaday.com/2023/05/09/wordstar-reborn/

Cool :)
--

[knud van eeden]

WordStar seems to have been very important text editor at the time

https://en.wikipedia.org/wiki/WordStar

TSE has thus in its <TSE> ui directory the ws.ui file, which if burned in lets TSE

behave similar to WordStar (key strokes, ...).

I have never used ws.ui though yet.

When I worked at Borland (now Embarcadero) Brief was the editor of choice (they bought it).

https://en.wikipedia.org/wiki/Brief_(text_editor)

First they used the original Brief later it was integrated as their native editor in their

products (like Borland C++, Delphi, ...) and stopped being sold as a standalone product.

When software developing using TSE instead though, e.g. to easy automate tasks.

What I see around me is that quite a few people use Notepad++ as their text editor nowadays.

Very rarely I work with it.

Rarely e.g. UltraEdit.

Developers use often use Visual Studio Code nowadays, because it is a free Visual Studio like environment.

In Visual Studio one can use CoPilot now (I have a paid subscription but never used it yet), which seems to behave a bit like ChatGPT when generating and editing source code.

But I only used ChatGPT (paid subscription) for source code questions until now and that was very impressive. E.g. asking it to generate hello world programs in until now about 70 different programming language in order to install these compilers / interpreters on TSE, ChatGPT basically never failed.

On Linux systems vi (vim) is by default installed on most distributions, but really intuitive it is not really. Used when no other choice available.

Otherwise e.g. Emacs, but also not really intuitive. Rarely used.

Most keyboard emulators should be available in SlickEdit, that includes even Emacs

(e.g. BBEdit, Brief, CodeWarrior, CodeWright, CUA, Eclipse, Epsilon, Emacs, ISPF, macOS, Vim, Visual C++ 6, Visual Studio default, Xcode, ...).

TSE is still the (only) main choice and that will stay like that.

with friendly greetings

Knud van Eeden

--

TSEPro Mailing List

List Maintenance: www.semware.com/html/newsgroup.php

[knud van eeden]

Further Eclipse (not very intuitive either) and IntelliJ are also very often used by (software) developers nowadays.

[zhao4zhong1]

TSEPro has the only compressed view function, but other editors do not.

---- Replied Message ----

From	tsepro...@freelists.org
Date	05/11/2023 01:53
To	TSEPro Support<sem...@googlegroups.com>、TSEPro Support<tse...@freelists.org>
Cc
Subject	[TSEPro] Re: SemWare's TSE mentioned on HackaDay

[Harald Mezger]

On Thursday, May 11, 2023 at 1:04:41 AM UTC+2 zhao4zhong1 wrote:

TSEPro has the only compressed view function, but other editors do not.

While Tessie was, if I remember correctly,  among the very first editors to offer a browseable overview of 

all search results in a document, some of its competitors have eventually caught up.

Two examples: 

- for NotePad++ , a comparable function is called Find All in Current Document.

- in MS Visual Studio Code, there is Find All References. 

BTW: a true open source variant of Microsoft's VS Code exists that doesn't spy on its users via telemetry: VSCodium.  

Available for Windows and Linux.

[zhong zhao]

But “Find All in Current Document” and “Find All References” in other code editor do not maintain syntax highlighting like "Compressed View" in TSE Pro, and can modify and distribute back to the original lines of code.

[zhong zhao]

To maintain syntax highlighting in CompressView, press<Alt-E> on CompressView, and then<Alt-O>rename the current file name from “*ViewFinds buffer 1*” to something like "cv1. c"

To modify and distribute back to the original lines of code，refer to

https://groups.google.com/g/semware/c/KEqEgyVoUjA/m/2L9b2Jm_AwAJ

[Carlo Hogeveen]

zhong zhao wrote over two messages:

But “Find All in Current Document” and “Find All References” in other code editor do not maintain syntax highlighting like "Compressed View" in TSE Pro, and can modify and distribute back to the original lines of code.

To maintain syntax highlighting in CompressView, press<Alt-E> on CompressView, and then<Alt-O>rename the current file name from “*ViewFinds buffer 1*” to something like "cv1. c"

I would love to take this one step further, and directly syntax highlight the View Finds list.
A TSE extension should be able to do this.
The biggest hurdle would be multi-line comments.
That hurts, because seeing which View Finds lines are commented and which are not would be a huge improvement!
But accounting for them is a mountain of extra work, so I might just do a simple version that does not syntax-highlight multi-line comments correctly, and maybe do a full version later.
I have added a "ViewFindsHi" extension to my possible future projects list, so hopefully one day I will get to it.

Aside, the idea is not new. Someone proposed it in the past, but back then I was less experienced and did not know how it could be done.

Carlo

[zhong zhao]

Marking lines that have been commented out by multiple lines comment in compressed view.

[Carlo Hogeveen]

zhong zhao,

About your ComLnCV macro.

It expects the user to first have done <Alt E> to edit a compressed "View
Finds" window, and, if your macro was (auto)loaded, then <AltShift 8>
intends to prefix commented lines with "//", included multi-line commented
lines, and to prefix not-commented lines with "..".

This is a good solution for your coding style and your TSE color settings!

A display imperfection is, that it prefixes a "//" at position 1 with "//",
but does not prefix a "//" that starts at an indented position.
Since the source code's original "//" is still shown, this is only a display
imperfection, misaligning the displayed line.

Your macro detects multi-line commented lines by checking the original
line's color in its original source file.
Which is great, that would be my approach.
However, your macro only checks for comments based on your TSE color
settings.
It will not work for other comment colors that other people might have set.
To get other users' comment colors your macro could Query() the values of
MultiLnDlmn1Attr, MultiLnDlmn2Attr, MultiLnDlmn3Attr, SingleLnDlmn1Attr,
SingleLnDlmn2Attr, SingleLnDlmn3Attr, ToEOL1Attr, ToEOL2Attr, and
ToEOL3Attr.
For ultimate robustness only if GetSynMultiLnDlmt(), GetSynSingleLnDlmt()
and GetSynToEOL() return a non-empty string for each corresponding comment
type.

Carlo

[zhong zhao]

Carlo Hogeveen，Agree with what you said. (^_^)

[zhong zhao]

But personally, I always believe that an irreplaceable classic color scheme is better than the N available color schemes:

[S.E. Mitchell]

If you will export your personal configuration via "Write Settings to Ascii file", I'll be glad to add your color scheme to the list of those available.

--

Sammy Mitchell

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/semware/56d8e8b9-43ac-432d-9695-b5e373b94bc4n%40googlegroups.com.

[zhong zhao]

Not only tse.cfg,but also 

proc TSE_default()
  SetColorTableValue(_BACKGROUND_, 0,0x000000 )    // black          0x000000
  SetColorTableValue(_BACKGROUND_, 1,0x000080 )    // blue           0x000080
  SetColorTableValue(_BACKGROUND_, 2,0x548c54 )    // green          0x008000
  SetColorTableValue(_BACKGROUND_, 3,0x548c87 )    // cyan           0x008080
  SetColorTableValue(_BACKGROUND_, 4,0x800000 )    // red            0x800000
  SetColorTableValue(_BACKGROUND_, 5,0x800080 )    // magenta        0x800080
  SetColorTableValue(_BACKGROUND_, 6,0x4c8065 )    // brown          0x808000
  SetColorTableValue(_BACKGROUND_, 7,0xa0a0a0 )    // light gray     0xc0c0c0
  SetColorTableValue(_BACKGROUND_, 8,0x808080 )    // dark gray      0x808080
  SetColorTableValue(_BACKGROUND_, 9,0x0000ff )    // light blue     0x0000ff
  SetColorTableValue(_BACKGROUND_,10,0x00ff00 )    // light green    0x00ff00
  SetColorTableValue(_BACKGROUND_,11,0x00ffff )    // light cyan     0x00ffff
  SetColorTableValue(_BACKGROUND_,12,0xff0000 )    // light red      0xff0000
  SetColorTableValue(_BACKGROUND_,13,0xff00ff )    // light magenta  0xff00ff
  SetColorTableValue(_BACKGROUND_,14,0xffff00 )    // yellow         0xffff00
  SetColorTableValue(_BACKGROUND_,15,0xffffff )    // white          0xffffff

  SetColorTableValue(_FOREGROUND_, 0,0x000000 )    // black          0x000000
  SetColorTableValue(_FOREGROUND_, 1,0x000080 )    // blue           0x000080
  SetColorTableValue(_FOREGROUND_, 2,0x004000 )    // green          0x008000
  SetColorTableValue(_FOREGROUND_, 3,0x004040 )    // cyan           0x008080
  SetColorTableValue(_FOREGROUND_, 4,0x800000 )    // red            0x800000
  SetColorTableValue(_FOREGROUND_, 5,0x800080 )    // magenta        0x800080
  SetColorTableValue(_FOREGROUND_, 6,0x804000 )    // brown          0x808000
  SetColorTableValue(_FOREGROUND_, 7,0xfeddbc )    // light gray     0xc0c0c0
  SetColorTableValue(_FOREGROUND_, 8,0x404040 )    // dark gray      0x808080
  SetColorTableValue(_FOREGROUND_, 9,0x0000ff )    // light blue     0x0000ff
  SetColorTableValue(_FOREGROUND_,10,0x86fc86 )    // light green    0x00ff00
  SetColorTableValue(_FOREGROUND_,11,0x9ffafa )    // light cyan     0x00ffff
  SetColorTableValue(_FOREGROUND_,12,0xffbfbf )    // light red      0xff0000
  SetColorTableValue(_FOREGROUND_,13,0xfecbfe )    // light magenta  0xff00ff
  SetColorTableValue(_FOREGROUND_,14,0xffffa0 )    // yellow         0xffff00
  SetColorTableValue(_FOREGROUND_,15,0xffffff )    // white          0xffffff
end

and

asm patch _memset in g32.exe to transparent marked text color:

...

.text:00408B03 568 E8 F8 A5 02 00                   call    _memset                  ;~update marked text color
.text:00408B08 568 83 C4 0C                         add     esp, 0Ch                 ;~0x08 is lo byte of return address

...

.text:00433100                                      _memset proc near
.text:00433100
.text:00433100                                      s= dword ptr  8
.text:00433100                                      c= dword ptr  0Ch
.text:00433100                                      n= dword ptr  10h
.text:00433100
.text:00433100 000 55                               push    ebp
.text:00433101 004 8B EC                            mov     ebp, esp
.text:00433103 004 57                               push    edi
.text:00433104 008 8A 45 0C                         mov     al, byte ptr [ebp+c]     ;  .text:00433104 008 8A 45 0C                mov     al, [ebp+arg_4]   ;get attr of to set,0x21 is green background and blue foreground
.text:00433107 008 8B 55 10                         mov     edx, [ebp+n]             ;~ .text:00433107 008 8B 7D 08                mov     edi, [ebp+arg_0]  ;Transparent Mark Patch begin here. edi is address of old attrs
.text:0043310A 008 8B 7D 08                         mov     edi, [ebp+s]             ;~ .text:0043310A 008 56                      push    esi
.text:0043310D 008 8A E0                            mov     ah, al                   ;~ .text:0043310B 00C 89 FE                   mov     esi, edi          ;esi is address of old attrs
.text:0043310F 008 F7 C2 FC FF FF FF                test    edx, 0FFFFFFFCh          ;~ .text:0043310D 00C 8B 4D 10                mov     ecx, [ebp+arg_8]  ;n bytes to set
.text:00433115 008 74 5D                            jz      short loc_433174         ;~ .text:00433110 00C 8A 65 04                mov     ah, [ebp+4]       ;lo byte of return address
.text:00433117 008 66 89 07                         mov     [edi], ax                ;~ .text:00433113 00C 66 3D 21 08             cmp     ax, 00821h        ;is called from update marked text color and attr of to set,0x21
.text:0043311A 008 8D 4C 17 FC                      lea     ecx, [edi+edx-4]         ;~ .text:00433117 00C 74 04                   jz      short loc_43311D  ;yes, patch it!
.text:0043311E 008 66 89 47 02                      mov     [edi+2], ax              ;~ .text:00433119 00C F3 AA                   rep stosb                 ;no, set ecx(n bytes) new attr
.text:00433122 008 8B 07                            mov     eax, [edi]               ;~ .text:0043311B 00C EB 09                   jmp     short loc_433126
.text:00433124 008 C1 EA 03                         shr     edx, 3                   ;~ .text:0043311D
.text:00433127 008 74 43                            jz      short loc_43316C         ;~ .text:0043311D                             loc_43311D:
.text:00433129                                                                       ;~ .text:0043311D 00C AC                      lodsb                     ;get old attr
.text:00433129                                      loc_433129:                      ;~ .text:0043311E 00C 24 0F                   and     al, 0Fh           ;get foreground color of old attr
.text:00433129 008 89 07                            mov     [edi], eax               ;~ .text:00433120 00C 0C 20                   or      al, 20h           ;set background to green
.text:0043312B 008 89 47 04                         mov     [edi+4], eax             ;~ .text:00433122 00C AA                      stosb                     ;save new attr
.text:0043312E 008 4A                               dec     edx                      ;~ .text:00433123 00C 49                      dec     ecx               ;next byte
.text:0043312F 008 74 30                            jz      short loc_433161         ;~ .text:00433124 00C 7F F7                   jg      short loc_43311D  ;loop
.text:00433131 008 89 47 08                         mov     [edi+8], eax             ;~ .text:00433126
.text:00433134 008 89 47 0C                         mov     [edi+0Ch], eax           ;~ .text:00433126                             loc_433126:
.text:00433137 008 4A                               dec     edx                      ;~ .text:00433126 00C 8B 45 08                mov     eax, [ebp+arg_0]
.text:00433138 008 74 27                            jz      short loc_433161         ;~ .text:00433129
.text:0043313A 008 89 47 10                         mov     [edi+10h], eax           ;~ .text:00433129
.text:0043313D 008 89 47 14                         mov     [edi+14h], eax           ;~ .text:00433129 00C 5E                      pop     esi
.text:00433140 008 4A                               dec     edx                      ;~ .text:0043312A 008 5F                      pop     edi
.text:00433141 008 74 1E                            jz      short loc_433161         ;~ .text:0043312B 004 5D                      pop     ebp
.text:00433143 008 89 47 18                         mov     [edi+18h], eax           ;~ .text:0043312C 000 C3                      retn
.text:00433146 008 89 47 1C                         mov     [edi+1Ch], eax           ;  .text:0043312C                             _memset    endp
.text:00433149 008 4A                               dec     edx
.text:0043314A 008 74 15                            jz      short loc_433161
.text:0043314C 008 89 47 20                         mov     [edi+20h], eax
.text:0043314F 008 89 47 24                         mov     [edi+24h], eax
.text:00433152 008 4A                               dec     edx
.text:00433153 008 74 0C                            jz      short loc_433161
.text:00433155 008 89 47 28                         mov     [edi+28h], eax
.text:00433158 008 89 47 2C                         mov     [edi+2Ch], eax
.text:0043315B 008 8D 7F 30                         lea     edi, [edi+30h]
.text:0043315E 008 4A                               dec     edx
.text:0043315F 008 75 C8                            jnz     short loc_433129
.text:00433161
.text:00433161                                      loc_433161:
.text:00433161 008 89 01                            mov     [ecx], eax
.text:00433163 008 89 41 FC                         mov     [ecx-4], eax
.text:00433166 008 8B 45 08                         mov     eax, [ebp+s]
.text:00433169 008 5F                               pop     edi
.text:0043316A 004 5D                               pop     ebp
.text:0043316B 000 C3                               retn
.text:0043316C
.text:0043316C                                      loc_43316C:
.text:0043316C 008 89 01                            mov     [ecx], eax
.text:0043316E 008 8B 45 08                         mov     eax, [ebp+s]
.text:00433171 008 5F                               pop     edi
.text:00433172 004 5D                               pop     ebp
.text:00433173 000 C3                               retn
.text:00433174
.text:00433174                                      loc_433174:
.text:00433174 008 83 E2 03                         and     edx, 3
.text:00433177 008 74 0B                            jz      short loc_433184
.text:00433179 008 88 07                            mov     [edi], al
.text:0043317B 008 FE CA                            dec     dl
.text:0043317D 008 74 05                            jz      short loc_433184
.text:0043317F 008 66 89 44 17 FF                   mov     [edi+edx-1], ax
.text:00433184
.text:00433184                                      loc_433184:
.text:00433184 008 8B 45 08                         mov     eax, [ebp+s]
.text:00433187 008 5F                               pop     edi
.text:00433188 004 5D                               pop     ebp
.text:00433189 000 C3                               retn
.text:00433189                                      _memset endp

[zhong zhao]

asm patch_memset reallized transparent marker blocks.

I strongly recommend that TSE Pro 4.60 natively supports transparent marker blocks.

[zhong zhao]

[S.E. Mitchell]

This is something that should have been in the editor a long time ago.

I have added it.

Question:  Should this be an option, or should it always work this way?

For now, this is the new behavior.

--

Sammy Mitchell

To view this discussion on the web visit https://groups.google.com/d/msgid/semware/1f082e94-bb0a-4f1e-b617-db7f407346c4n%40googlegroups.com.

[knud van eeden]

> On Friday, June 9, 2023 at 01:43:29 PM GMT+2, S.E. Mitchell wrote:

> This is something that should have been in the editor a long time ago.

> I have added it.

> Question:  Should this be an option, or should it always work this way?

> For now, this is the new behavior.

Not sure at this moment what this is going to change (e.g. (my) (SAL, ...) syntax highlight colors, ...).

But in my opinion 

it should always be optional, so as leaving the choice to the TSE user

to use and incorporate it or not, so to keep backwards compatibility

and possibly not breaking what the TSE user expects and is used to.

As these colors are something the user sees all the time when editing a computer language.

Thanks

[Carlo Hogeveen]

>> I strongly recommend that TSE Pro 4.60 natively supports transparent
marker blocks.

> This is something that should have been in the editor a long time ago.
> I have added it.
> Question:  Should this be an option, or should it always work this way?
> For now, this is the new behavior.

My assumption is, that what Zhong Zhao and Sammy Mitchell are alluding to
is, that from the next TSE version onwards block marking will only use the
configured block background color, and ignore the configured block
foreground color.

The affected TSE configuration variables would be BlockAttr and
CursorInBlockAttr.

The benefit would be, that typically(*) block marking would no longer
overwrite TSE's foreground/text syntax highlighting.
My BlockHilite extension would become superfluous.

For myself I would be in favor of that simplification.

I notice that block marking's future property already has a counterpart in
"cursor line highlighting" (CursorAttr).

If a macro source .s file is current, "cursor line vs syntax highlighting
precedence" is configurable in Options -> Full Configuration ->
Display/Color Options -> Configure SyntaxHilite Mapping Sets -> Current ->
CursorLine Precedence.
I suspect this would be a logical place for a new option for "block vs
syntax highlighting precedence", if such an option were to be added.

(*)
I see one possible downside to the new transparent block marking feature,
namely if someone has defined syntax highlighting as a change in background
color. Depending on its implementation, transparent block marking might
negate syntax highlighting with a background color. For example, the first
TSE Color Scheme "Black by Brad" heavily uses syntax highlighting with
background colors.

For an existing comparable example with "cursor line vs syntax highlighting
precedence", in a fresh unchanged TSE installation an incomplete quote is
highlighted with a background color, but not for the current line. With its
precedence option a user can change this.

So based on that, there theoretically could be users who would like a
"block vs syntax hiliting precedence" option like there already exists one
for "cursor line vs syntax highlighting precedence".

If my assumption is correct and my explanation is sufficient, then they can
now voice an informed opinion on whether they want such a "block vs syntax
hiliting precedence" option.

Carlo

[Guy Rouillier]

I just read through the whole discussion on groups.google.com.  I'm not completely following the suggestion, but I've developed my preferred color scheme over the last 20+ years of using Semware editors, which includes block marking.  I'd prefer that my editor background color and block marking background color not be changed by any macros or extensions.  Thanks.

--

Guy Rouillier

To view this discussion on the web visit https://groups.google.com/d/msgid/semware/CA%2BgEvkbYnv9NMWXHsb5XQwLtjYP8EGsLR8z7RC52vAcRn8UFGw%40mail.gmail.com.

[H P]

I think like Carlo. Give the possibility to use it or not.

But at the the end you can request something but it is Sammy's editor and we may use it.

Met vriendelijke groet,
With kind regards,

Muy atentamente,
Mit Freundliche Gruß,

Sinceramente,


H. Pikaar
Henri...@gmail.com

Op za 10 jun 2023 om 09:26 schreef Guy Rouillier <guy.ro...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/semware/emddb67398-fe7f-40c9-be80-19d7454d3714%40d96f6462.com.

[Carlo Hogeveen]

> I think like Carlo. Give the possibility to use it or not.

Uh, I did not state that.
I am not for or against making "block marking vs syntax highlighting precedence" configurable, and leave such statements to people who think they have a stake in the upcoming change.

Carlo

[zhong zhao]

Below is some demostration for Cyan background color for current line, Green background color for marked block, and (Cyan+Green)/2 background color for current line in marked block.

[zhong zhao]

After change some palette of foregroud color and background color , we got all 16 kind of forecolor combine with 5 kind of backcolor [litgray for normal+green for marked+cyan for currline+(cyan+green)/2 for currline and marked)+darkgray for just compressed view] could be visible: