#226 Remove Required Backslashes for Line Breaks in Gnuplot Command Blocks

[Artur Tarassow]

Description:

Currently, when using the gnuplot command with multiple settings separated by semicolons, backslashes are required at the end of each line when line breaks are used:

gnuplot yhat median_house_value --output="yhat_vs_actual.png" \
  { set xlabel "Predicted Value";\
    set ylabel "Actual Value";\
    set grid;}

However, in bundle definitions where items are separated by commas, no backslashes are required for line breaks:

bundle B = _(a=2,
             b="abc")

Request

Please make the syntax for gnuplot command blocks consistent with bundle definitions by eliminating the need for backslashes after semicolons when breaking lines. This would improve code readability and reduce a common source of syntax errors.

Benefit:

This change would make script writing more efficient and align the syntax rules across different parts of the Gretl codebase, creating a more consistent user experience.

Best,
Artur

[Sven Schreiber]

It seems to me the issue is commas versus semicolons. Consider these examples:

matrix m = { 1, 
  2}  # but fails with semicolon 

matrix m = { 1; \ 
  2} # explicit workaround with line contin.

bundle B = _(a=2,
  b="abc") # Artur's example

A = defarray("a",
  "b")

m = mnormal(2,
3)

Same with functions definitions (line breaks in the argument-definition part). So it's not only about the gnuplot command. The semicolon is a little special in gretl's syntax, not sure how difficult it would be to allow line breaks there.

[Allin Cottrell]

In today's git semicolon is recognized as calling for line continuation, in all contexts. So far as I can tell that shouldn't cause any problems. Semicolon serves as a list separator, and as a row separator for matrices, but I can't think of a case where it would legitimately appear at the end of a hansl statement.

While I was at it, I fixed line continuation in the GUI console. There was already code intended to handle backslash continuation (only) but it was not working at all. Now it handles backslash, comma and semicolon correctly.

[Artur Tarassow]

Thank you, @allin. It works nicely: I've tested my as well as Sven's examples above. All work as expected!

Artur

[Sven Schreiber]

Thanks, Allink, that sounds great.
But what about stuff like this:
<hansl>
open denmark
smpl ; ;
a = "aha"
</hansl>

[Allin Cottrell]

Oof, yes. But I'm pretty sure that's the single exception. It's now handled in git.

[Sven Schreiber]

OK, excellent. @atecon, are you still in the business of unit-testing? I think that the code snippet (repeated below) might be a nice addition, because it's a bit unusual but officially valid.
<hansl>
open denmark
smpl ; ;
a = "aha"
</hansl>

[Artur Tarassow]

Hi @svetosch, I can do so. But I do not understand exactly what's tested here. When I run the script I get the error:

? smpl ; ;a = "aha"
Parse error at unexpected token ';'

Error executing script: halting
> smpl ; ;a = "aha"

Is the test about whether Gretl allows the syntax smpl ; ; as a valid way to specify the full sample?

Does the error suggest that Gretl's parser does not accept this syntax, possibly due to the way semicolons are handled or expected in the command?

I would like to add a brief description to the unit-test script.

[Sven Schreiber]

Could it be that you're running a not-fully-up-to-date git version? AFAIK, the snippet above should work, and that's the point of the test. It only failed during a short period of time, after the original change and before the fix.

[Artur Tarassow]

That's not my point -- sorry for not being more clear. I know that it fails due to an not-up-to-date gretl version here.

I just try to understand what actually happens here smpl ; ;. I think I am asking what the double semicolon actually means?

Thanks

[Sven Schreiber]

Ah, OK, the semicolon in the sample command means "no change", either for the starting or for the final obs, depending on the position. Not sure where it's documented, however. I guess that it normally should be equivalent to "+0", but not 100% sure.

[Artur Tarassow]

I was aware of the single semicolon case but not about the double semicolon one.

Thanks, I am going to add this as a note.

[Sven Schreiber]

Yeah, of course it's kind of useless. The point here was the trailing semicolon at the end in any case.

[Artur Tarassow]

I've added a unit-test to the gretl repo. This ticket can be closed as the original problem (and some others) are resolved.