Bug #433
EMACS UI: trouble with sending a long line
Description
Sending a long line to CoCoA-5 inside Emacs does not work: CoCoA gets stuck and simply prints out lots of ^G. I believe the problem actually arises from the shell running underneath Emacs.
Perhaps we should arrange for long lines to be sent using SourceRegion rather than copying the line across. I suggest using SourceRegion for lines longer than 2000 chars
(I believe the shell has a limit of 4095)
The long line contained a slightly edited polynomial printed out by CoCoA; so it's not such an unreasonable scenario!
Related issues
History
#1
Updated by John Abbott about 10 years ago
Updated by My idea to use SourceRegion has a (minor?) technical problem: it implies that the buffer be saved to the associated file, something the user may not want to happen.
Another solution could simply be to refuse to send a long line to CoCoA, perhaps with a message suggesting that the file be saved and that the user use SourceRegion.
Still another solution could be to save the line in a temporary file (in /tmp/ presumably) and then source the temporary file...but who will delete the temporary file and when?
I had also thought of automatically breaking the line into several shorter lines, but I do not believe this is currently possible in every case (e.g. what if the line contains a very long string?). It could be done if the parser recognized an escaped newline (equivalent to nothing) in every context (inside strings, inside identifiers, inside keywords, inside integer literals, inside escape sequences...)
#2
Updated by Anna Maria Bigatti about 10 years ago
Updated by - Target version set to CoCoA-5.1.0 Easter14
#3
Updated by John Abbott about 10 years ago
- Status changed from New to In Progress
- Target version changed from CoCoA-5.1.0 Easter14 to CoCoA-5.1.1 Seoul14
- % Done changed from 0 to 10
The problem arises in my more recent Emacs (24.3) but not in my older installation (23.1).
In any case, there could surely be problems with very long input lines (e.g. more than 1Mbyte), so the issue still needs to be addressed.
#4
Updated by John Abbott over 9 years ago
- Priority changed from Normal to High
I suggest adopting the SourceRegion solution; it seems fairly unlikely that saving the file could really be a problem.
Normally sending a line to CoCoA-5 echoes the line in the CoCoA-5 output buffer; using SourceRegion would echo the SourceRegion command -- this might actually be a feature, rather than echoing many kilobytes of C5 code!
I'll have a look at the emacs code to see how easy such a change would be.
There is also the question of what threshold to use for switching between "send a line" and "source region"; I'm inclined to start with a threshold of about 1000 chars.
#5
Updated by John Abbott over 9 years ago
- % Done changed from 10 to 20
I have an ugly solution that appears to work fine in Emacs 23.2 and 24.1.
Now I'll try to make it neater.
#6
Updated by John Abbott over 9 years ago
- Assignee set to John Abbott
- % Done changed from 20 to 70
- Estimated time set to 4.40 h
I now have a cleaned solution -- our Emacs code is very "evolutionary" (rather than "intelligent design").
I'll check in, so that we can test it for a few days before releasing it.
It is a bit slower than I had expected for long lines (about 0.5Mbytes, just 1 test), but still acceptable.
#7
Updated by John Abbott over 9 years ago
- Status changed from In Progress to Closed
- % Done changed from 70 to 100
- lines longer than 999 chars are sent using
SourceRegion - do not worry about
SourceRegionsaving the buffer
#8
Updated by John Abbott over 7 years ago
- Related to Bug #945: Emacs UI: comint buffer silently truncates(?) long lines when sending added