Support #911
CoCoA-5 prompt for incomplete input
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
History
#1
Updated by John Abbott almost 8 years ago
The relevant code seems to be in LineProviders.C:79--85
.
- 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 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.