Single line hotkeys

[just me]

Code: Select all

^+a::If (Z := !Z)
   ToolTip, Z = %Z%
Return

should not do what it does (though one might call it 'kind of documented behaviour'). It should raise an error.

Related

[Helgef]

The behaviour is undefined. I'm pretty sure this is known though.

Cheers.

Edit, perhaps I was mistaken.

[swagfag]

so the implicit return gets inserted after the if-statement to, effectively, produce:

Code: Select all

^+a::
	If (Z := !Z)
		Return ; the implicit
	else
		ToolTip, Z = %Z%
Return

ListLines reports the return on the same line:

Code: Select all

^+a::If (Z := !Z) Return ; the implicit
	 else
		 ToolTip, Z = %Z%
Return

[joefiesta]

When written thusly, an error is produced:

Code: Select all

z = %1%
return
^+a::
  If (Z := !Z)
     msgbox true  Z = %Z%
  else
   msgbox  false  z = %z%
  return
^+b::   If (Z := !Z)
     msgbox true  Z = %Z%
  else                                          ; error shown for this "hanging" else
   msgbox  false  z = %z%
  Return

I fail to understand how this can not be considered an error.

[gregster]

I understand it this way:
The implicit return gets inserted by the interpreter at runtime as an extra line, not on the same line as the hotkey one-liner.

Then If reclaims it as its second line. That is very unfortunate, but perhaps not technically a bug.
Although I would also prefer that one-liner hotkeys wouldn't allow two-liner If-statements at all. On the other hand, I would have never tried it, because the docs say:

However, if a hotkey needs to execute only a single line, that line can be listed to the right of the double-colon.

For me, that means implicitly, that two-line constructions like non-traditional If cannot be used with it.
Turns out, it can be used, but not really in a useful way.
(What happens if you still do it, is not explicitly defined in the docs)

ListLines reports the return on the same line:

As I understand it, Listlines and error messages report implicit returns on the line number that causes this return to be inserted.
But the implicit return line is de facto handled as an extra line.

If Listlines would report the implicit return with an additional line number, all others line number after it would shift and that would create problems for the user while debugging - the line numbers wouldn't match anymore with the actual source code in the editor.
As I've shown in the german thread, the implicit return at the end of an auto-execute section also gets reported on the line number of the hotkey that is responsible for it, although syntactically it wouldn't make sense to have a return and a hotkey label/defintion on the same line.

If you run this code and then press first 1 and then 2:

Code: Select all

x := ""			; 001

1::MsgBox				; 003
2::Listlines			; 004

you will get this result in the ListLines window:

Code: Select all

001: x := ""
003: Return (1.47)
003: MsgBox (0.91)
003: Return (0.38)
004: ListLines

The first return that is reported on line 003 is the implicit return of the auto-execute section (only at script start). It for sure gets treated as a single line by the interpreter. Otherwise, the hotkey defintion on the same line would throw an error message.
The second implicit return gets also reported on the line that caused it (again 003), allowing to keep the original line numbers for all following lines.

I think if you report line numbers for implicit returns at all, this is probably still the best way to do it. (I think, it's helpful.)

[joefiesta]

Sorry, about my entry. I misunderstood the issue.

Now that I know now what it is, I think the second line of the if claused should simply be flagged as an error by the interpreter or compiler. Why not? It would make debugging so much simpler. Why make the user trudge through the documentation to find something that may still lead him questioning?