Syntax-Colouring: the end of a string isn't recognized reliably

[ReinhardHahn]

In this Issue I describe the some circumstances, which causes EMACS not to recognize switch the colouring back ot normal at the end of a string.

Prelimary Remarks

Test

In my examples I use the expression write(1+1) as a test. When the colouring works correct, the word write should by coloured as a single word. If the colouring is still in the string mode, it will be in the same colour as the other characters in the same line. So if you test, you will see it very clearly

Workaound

One of the following inline comments end up the wrong colouring, described in this issue:

• #" in case the wrong colouring is due to a " limited string
• #' in case the wrong colouring is due to a ' limited string (with PR Support for Strings with single quote delimiters #22 re-activated)
• #' #" or #" #' in every case

This comment may be written in a single line, at the end of any line, even in the line, where the problem occurs. For example in the follwoing line, the wrong colouring is finshed just at the end of the line:

write("%MY_ENV_VAR")#"

In my examples I do not correct the error in the same line, to have the possibility to add a the a. m. test expression write(1+1) in single line before the correction

Single-Quote-(')-support in EMACS

Strings delimited with single quotes right now are not supported by EMACS (c.f. issue #25 and PRs #22 and #23)

SW 5 crashes with uneven number of "-characters in write arguments

If the argument list of the write procedure written to the magik prompt contains an uneven number of "-characters a SW 5.x session crashes. (The same holds for the write_string procedure or or the write() method on text_output_streams; This issue has already been reported to the GE support). To avoid problems with that issue, the tests are done with SW 4 (MagikSF>). If you test with SW 5, in some cases you might replace %" by %u0022

magik-mode

%-character at the end of a string constant in magik-mode

In Magik mode a %-character as last Element of a string constant causes problems, as in the following examples:

_block
	# % as last char within a String constant supresses the correct
	# colouring switch at the end of the string
	write("%MY_ENV_VAR%")
	write(1+1) # this line is in string colouring (wrong)
	#" # (correct the behaviour)
	write(1+1)

	# this works correct:
	write("%MY_ENV_VAR",%%)
	write("an object: ",object,%")
	write(1+1)
_endblock

# the same with '...' strings (with PR #22 re-activated)
_block
	# % as last char within a String constant supresses the correct
	# colouring switch at the end of the string
	write('%MY_ENV_VAR%')
	write(1+1) # this line is in string colouring (wrong)
	#' # (correct the behaviour)
	write(1+1)

	# this works correct:
	write('%MY_ENV_VAR',%%)
	write('an object: ',object,%')

	# and the combinations work, too:
	write('a double quote: "') # NB: without #22 the following lines are in string colour (wrong!)
	write("a single quote: '")
_endblock

, which looks in EMACS like the following screenshot:

magik-session-mode

%-character at the end of a string constant in magik-session-mode

The same bug you can see also in magik-session-mode, if you input the following lines at the magik prompt, one after the other:

write("%h%")
write(1+1) # still in string colouring (wrong)
#" # (correct the behaviour)
write(1+1) # now correct

And with #22 re-activated also with single quotes:

write('%h%')
write(1+1) # still in string colouring (wrong)
#' # (correct the behaviour)
write(1+1) # now correct

, which results in:

String delimiters in Magik output

In magik session mode string delimiters are recognised in the magik-output as well. And it's an interesting question, whether or not this has to be regarded as a bug.

On the one hand it is quite useful to have syntax colouring in the output, especially if you think of the output of show statments like

show(:hello, 3, "world", object)

, where the coloring helps recognizing the different object types.

On the other hand it is not useful if the output is plain text, where might occur ' rather than ", for example with the follwoing input (with #22 re-activated)

write("It's ugly")
write(1+1) # now in string colouring (wrong)
#' # correction
write(1+1) # correct again

But of course a similar situation is with " possible as well (independent of #22):

write(%")
write(1+1) # now in string colouring (wrong)
#" # correction
write(1+1) # correct again

These examples look in EMACS like that:

Rating discussion

Some personal remarks of the Author about the severity

• Both issues described here have an influence on syntax colouring, only. I dont's see any other side effects
• In every case, there is an easy workaround by writing #' #" (or even less) , to correct the colouring

In detail:

%-character at the end of a string constant (in magik-mode and magik-session-mode)

I think it would be quite useful to fix this bug, but I regard it as minor.

String delimiters in Magik output

As there are use cases, where the behaviour is useful as it is, I don't see any valuable possibility to change the behavour. And the workaround of just inputting #" #' at the Magik Prompt makes the the impact of cases, where the behaviour is unwanted, quite limited. A solution for even better usability could be, to automatically end up any string-colouring in the magik-session-mode, if a line starts with Magik> or MagikSF>