Project

General

Profile

Support #911

CoCoA-5 prompt for incomplete input

Added by John Abbott almost 8 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Parser/Interpreter
Target version:
Start date:
27 Jul 2016
Due date:
% Done:

100%

Estimated time:
2.22 h
Spent time:

Description

Werner reported a strange problem with CoCoA-5 saying that a result was too large to be printed.

It turns out that he had interpreted the "incomplete input" prompt as an indication of suppressed long output.
The prompt is ... ; followed by the user's chosen prompt. Perhaps this is a bit too cryptic?


Related issues

Related to CoCoA-5 - Feature #500: Interpreter: is it possible to avoid useless prompts?Closed2014-03-28

Related to CoCoA-5 - Feature #133: Qt GUI: Make better distinction between input and output in the output windowNew2012-04-19

History

#1 Updated by John Abbott almost 8 years ago

The relevant code seems to be in LineProviders.C:79--85.

There are separate "continuation prompts" for 3 contexts:
  • incomplete statement (or forgotten semicolon)
  • incomplete multi-line comment
  • incomplete multi-line string [can this ever happen?]

If we do change the "continuation prompts", we should define all three.

#2 Updated by John Abbott almost 8 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
The printed prompt is actually made of 3 parts:
  • the type of the last unclosed block (or empty if none)
  • the continuation prompt (something with triple-dot in it)
  • the user's chosen standard prompt

Appending the user's standard prompt makes it relatively easy to spot lines of input; however it can make the combined prompt quite long. For instance in an incomplete function definition I get

Define ... ; >>>

where the >>> is my chosen prompt.

I note that bash has a primary prompt, and a secondary one (which it uses for continuations).

#3 Updated by John Abbott over 3 years ago

  • Target version changed from CoCoA-5.?.? to CoCoA-5.4.2

#4 Updated by John Abbott over 3 years ago

  • Related to Feature #500: Interpreter: is it possible to avoid useless prompts? added

#5 Updated by John Abbott over 3 years ago

I am wondering about enclosing the prompt prefix in square brackets.
I also wonder whether the case of a prefix containing only dot-dot-dot should be handled specially e.g. waiting for semicolon (or something shorter?)

#6 Updated by John Abbott over 3 years ago

  • % Done changed from 10 to 20

Here is what my personal CoCoA does currently:

/**/ 1+2
[[waiting for semicolon]] /**/ ;
3
/**/ define john(x)
[[define ... ]] /**/ return x+1;
[[define ]] /**/ enddefine
/**/ 

What do you think of putting the supplementary prompt parts inside double-square-brackets?

#7 Updated by John Abbott over 3 years ago

The supplementary part of the prompt comes from openBlocks.
I have no idea how the value of openBlocks is updated: grepping through the code seems to find nothing helpful.
I'm puzzled! Advice welcome!

#8 Updated by John Abbott over 3 years ago

I am not convinced of the utility of the dot-dot-dot when the supplementary prompt is non-empty.
It is hard to explain exactly when dot-dot-dot is appended... an approximate explanation is when a semicolon could/should be input... maybe?

To me it seems that dot-dot-dot occupies space while not really being helpful.
So I am inclined to propose removing it (when there is already something in the supplementary part).

What do you think?

#9 Updated by John Abbott over 3 years ago

  • Assignee set to John Abbott
  • % Done changed from 20 to 50

I have now removed dot-dot-dot from the prompt prefix.
Also when inside a multi-line comment, the prompt now says [[multi-line comment]] which is probably easier to comprehend than the former /* ...
Similarly when inside a multi-line string literal (though this is currently commented out)

#10 Updated by John Abbott over 3 years ago

  • Status changed from In Progress to Resolved
  • Target version changed from CoCoA-5.4.2 to CoCoA-5.4.0
  • % Done changed from 50 to 80

I have now revised the impl after designing a simple test, and seeing that the behaviour was "sub-optimal"...
The test is:

1/* comment
*/
;
define fn(a)
  /* comment
  */
  return a+1;
enddefine

And CoCoA responds like this:

>>> 1/* comment
[[in multi-line comment]] >>> */
[[waiting for semicolon]] >>> ;
1
>>> define fn(a)
[[define]] >>>   /* comment
[[define >> in multi-line comment]] >>>   */
[[define]] >>>   return a+1;
[[define]] >>> enddefine
>>> 

#11 Updated by John Abbott over 3 years ago

  • Related to Feature #133: Qt GUI: Make better distinction between input and output in the output window added

#12 Updated by John Abbott about 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 80 to 100
  • Estimated time set to 2.22 h

Anna and John are happy. Closing.

Also available in: Atom PDF