Colored or shaded sections of code in the SE

[bogs]

Hmmm, I think I see what you mean...

Trim and tuck and...

[[-hh]]

Craig.
Scripts are saved as plain text and newly colorized when reformatting what first removes all styles.

But there is a simple remedy:

1. Insert markers #BC start and #BC end into the script where the "custom backColor" should occur. For example:

Code: Select all

on updateImage x, modus
  put the height of grp x into hg; put the width of grp x into wg
  put the formattedHeight of img x into hi
  put the formattedWidth of img x into wi
  #BC start #<------------------------- START
  if modus is "height" then
    set height of img x to hg; set width of img x to (wi*hg div hi)
  else
    set width of img x to wg; set height of img x to (hi*wg div wi)
  end if
  #BC end #<--------------------------- END
  set loc of img x to the loc of grp x
 end updateImage

2. Add the following handler to your card or stack script (marks the text between all such markers).

Code: Select all

on markScript pC
  lock screen; lock messages
  if pC is empty then put "204,204,204" into pC -- light gray
  put the short name of this stack into sn
  put "Editor" into tE
  set linedel to "#BC"
  set itemdel to CR
  repeat for each item L in the openstacks
    if L begins with "RevNewScriptEditor" then
      go card "MAIN" of stack L
      repeat with f=1 to the num of flds of grp tE
        if not (the short name of fld f of grp tE begins with "Script")
        then next repeat
        if "#BC" is not in fld f of grp tE then next repeat
        set backcolor of item 1 to -1 of fld f of grp tE to empty -- reset
        repeat with i=1 to the num of lines of fld f of grp tE
          if word 1 of item 1 of line i of fld f of grp tE is "start" then
            set backcolor of item 2 to -2 of line i of fld f of grp tE to pC
          end if
        end repeat
      end repeat
    end if
  end repeat
  go stack sn
  unlock messages; unlock screen
end markScript

Now you can use this handler from the message box or, as I do, using different colors from a menu button.

Works here, as you want, for all open script editor windows and all their script tabs.
Of course this is lost/has to be redone whenever one reformats (using tab key in the SE) the handler containing a "custom backColor" part.

To comfort beginner readers here the script of the popup button I use and hide/delete afterwards.

Code: Select all

on mouseDown
  put "White,Gray,Black,Blue,Brown,Cyan,Green,Magenta,Orange,Purple,Red,Yellow" into m
  replace comma with cr in m
  put m into me
end mouseDown

on mouseUp -- use mouseup because menupick doesn't act without change
  markScript the label of me
end mouseUp

[dunbarx]

I have just started to colorize the SE to see how I like it. I can make a plug-in to colorize the selectedChunk.

The issue is saving

Craig

[mwieder]

Craig-

You can't "save" the selection as such.
The script editor is a weird beastie: it's generated from a template each time you launch it. If you launch two separate instances or spawn one tab into a separate window you'll end up with "revNewScriptEditor 1" and "revNewScriptEditor 2", etc. The next time you start editing a script you'll get a new SE from the template. And the template is part of the IDE, so it's in a protected space and can't be "edited" normally without a lot of effort.

So I think if you want to save the selection you'd have to save the htmlText as a custom property of the object whose script is being edited (that leaves out script-only stacks), then patch the "editScript" handler of the SE to retrieve the htmlText property when you start editing a script and set the htmlText of the script field to that. And also patch the SE to save the htmlText on saving the script. That's a lot of work for little ROI, especially considering you'd have to patch each new release to do the same.

[dunbarx]

Hermann.

Interesting take on the colorizing issue, but does not address the saving part.

BUT, along the lines of your thinking, why not save the (perhaps several different blocks) of backColored lines in a custom property, updated every time the handler is called? Then you can reload those saved lines in a new session. In other words, even if the SE cannot remember its colors, we can. I will try to play around with that when I get back to my office.

On another note here is something I did not know, and had thought might be a problem. When one adds a line inside a previously "backColored" block of text, the backColor of the newly added line inherits the backColor of the whole. I would have thought it would come out with no backColor at all.

Feature or bug? But it makes using the colorized SE easier to work with.

Craig

[[-hh]]

Interesting take on the colorizing issue, but does not address the saving part.

Of course it does. The markers are part of the script, thus saved with the script.

The backcolor of my marked parts is changed without changing the script:
My handler doesn't make the script "dirty" because its plain text isn't changed.

[dunbarx]

Hermann.

Of course, the markers. I forgot. And you can always move the markers.

Still, all these are kluges. What I really want is a button in the SE to colorize the selectedChunk. That way, I can modify each section easily and quickly. And I want it saved.

Anyway, I have just started to use colorized blocks. Have you already done so?

Craig

[dunbarx]

Mark.

So I think if you want to save the selection you'd have to save the htmlText as a custom property of the object whose script is being edited

Right.I thought of something similar before I read your post. See the thread at:

Code: Select all

https://forums.livecode.com/viewtopic.php?f=9&t=33581

And Hermann has proposed another interesting way, to hard code markers within the text itself, and then use those markers to "remember" the lines to be recolored.

But I like our idea of using the colored text itself, though, since one can change it and retrieve it without having to relocate hardcoded lines as your script changes. Since you can set the backColor of the selectedChunk directly, and then, when done fooling around (pseudo)

Code: Select all

get the script of the SE
repeat with y = 1 to the number of lines  of it
if the backColor of line y of it = "yellow" then put y & return after tColoredLines
save tColoredLines in a custom property

And then of course you can get the property and run a similar loop in reverse to recolor. This uses the colored lines themselves as the "markers", which is, I think, more compact and robust.

But each method essentially is the same, that is, to store the extents of possibly several blocks of interest "externally", and reload between sessions.

Craig

[[-hh]]

Craig.

I have just started to use colorized blocks. Have you already done so?

This is after all a fine idea, thanks for that.

If a block is such complicated that I can't recall it for 5 minutes I use marks (to jump to, as most code editors allow).

Following your idea, I just now rewrote the handler to use such marks optionally also for colorizing blocks. With different colors, for having differently highlighted blocks in the same script.

[dunbarx]

Mark.

It turns out that there is, at least using tabs, which I always do, only one stack "revNewScriptEditor 1". But that stack now has multiple fields:

Code: Select all

 set the backColor of line 3 of fld 1 of stack "revNewScriptEditor 1" to "yellow"
  set the backColor of line 3 of fld 2 of stack "revNewScriptEditor 1" to "red"

I have not checked when using two window instances but there, as you said, you are likely to have "revNewScriptEditor 1" and "revNewScriptEditor 2".

The two threads that speak of this should be combined, but I would need Klaus or Richard to do that.

Guys?

Craig

[dunbarx]

Hermann.

Please read what is going on at:
https://forums.livecode.com/viewtopic.php?f=6&t=33578

I would like these two threads to be combined. Richard? Klaus?

Anyway, I spoke there about the advantages of using the colored lines themselves instead of hard coded markers. I want to hear your thoughts about that.

Craig

[FourthWorld]

Topics merged. Going forward please start only one thread for a given subject, do everyone knows where to post replies and read updates.

[[-hh]]

Craig.

I you wish to save the htmltext of the scripts then you have to follow the laborious way that Mark Wieder describes.

Compare that to the markers-method:

• That doesn't change the scripts (except of the markers),
• it doesn't blow up the stack with the html-version of the scripts,
• it applies to every kind of script in every kind of stack,
• it works also for unsaved scripts.

Also you can use these markers additionally or alternatively for
other purposes, for example use them as jumping targets:

Code: Select all

-- script of a pullDown button, jumps to the markers
-- (=lines beginning with "#BC ") of the *active* SE tab
-- which may be in *any* of several SE windows.

local activeEditor

on mouseDown
  put the openstacks into tOS
  put line lineOffset("RevNewScriptEditor",tOS) \
        of tOS into activeEditor
  put getMarks() into me
end mouseDown

function getMarks
  put empty into s0; put 0 into z
  put "#BC" into M; set itemdel to M
  put fld "Script" of grp "Editor" of card "Main" \
        of stack activeEditor into tU
  if M&space is not in tU then return empty
  repeat for each line L in tU
    add 1 to z
    if word 1 of L is M then put cr&z&item 2 of L after s0
  end repeat
  return char 2 to -1 of s0
end getMarks

on mouseUp
  put word 1 of the hilitedText of me into w
  go stack activeEditor
  select line w of fld "Script" of grp "Editor" of card "Main"
end mouseUp

[dunbarx]

Hermann.

There is one clear advantage of embedding markers in the script itself. Because the SE creates new fields in stack "revNewScriptEditor 1" for each new tab in each new session, what may have once been field 1 may no longer be, depending on the order in which one opens those new tabs.

Craig

[FourthWorld]

There is one clear advantage of embedding markers in the script itself. Because the SE creates new fields in stack "revNewScriptEditor 1" for each new tab in each new session, what may have once been field 1 may no longer be, depending on the order in which one opens those new tabs.

Another equally clear advantage is that it's achievable.

For all the reasons Hermann outlined above, attempting to store position-specific metadata in any plain-text content will require either adding the metadata directly to the text (as with tags), or completely rewriting significant portions of everything that handles scripts so that they're working with styled representations rather than plain text.

Tagging is not only easy to implement (and many orders of magnitude simpler than attempting to replace plain-text scripts with anything that contains style info), but also extensible: once you get the basic setup in place, you could define your own tags for all sorts of purposes, and your plugin can do real-time changes to the appearance of scripts however you like.