Project

General

Profile

Bug #748

Emacs UI: return inside a block of output sends several lines (not just the one I'm on)

Added by John Abbott over 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
EmacsUI
Start date:
27 Jul 2015
Due date:
% Done:

100%

Estimated time:
3.01 h
Spent time:

Description

I have recently upgraded to Emacs 24.5.1. The problem is exhibited by doing ?package inside a CoCoA-5 buffer. This produces a list of matches; now I move the cursor to the match I want, and press "enter". This now sends all output from the line the cursor was on, to the following prompt (including the line containing the prompt!) as the new input. Previously it sent just the line the cursor was on.

History

#1 Updated by John Abbott over 8 years ago

The relevant Emacs function is(should be?) comint-get-old-input-default. The documentation says the fn should indeed do what I'm accustomed to (with my older Emacs-23).

Currently no further ideas.

#2 Updated by John Abbott about 8 years ago

  • Target version changed from CoCoA-5.1.3/4 Jan 2016 to CoCoA-5.2.0 spring 2017

Since I've no heard of many other users having the same problem, I'll postpone this issue to the next version of CoCoA-5. It really seems to be an Emacs "curiosity".

#3 Updated by John Abbott almost 8 years ago

This continues to bother me; it seems to be a "feature" of emacs 24.5 (on several machines).
Strangely I looked on internet for other with the same problem (and hopefully a solution/work-around) but have not found anything. Odd!

I hope to find a solution soon.

#4 Updated by John Abbott almost 8 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

A possible work-around seems to be to set comint-use-prompt-regexp to t.

The implementation of comint-get-old-input-default is hard to follow (as I'm not expert on char properties). As far as I can see, the function does two different things depending on whether comint-use-prompt-regexp is set.

Supposedly, if comint-use-prompt-regexp is not set then the buffer contents is split into fields of two types (input fields and output fields). A user input could span several physical lines, so when RTN is pressed in user input it sends the whole "field" (i.e. all lines comprising the input). From the observed behaviour the output is also regarded as a single field (whereas one field per line would be more convenient for our purposes).

I have no idea how to fix this properly; any Emacs gurus willing to help here?

#5 Updated by John Abbott almost 8 years ago

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

I have a possible solution: I have copied comint-get-old-input-default into cocoa5.el then edited it so that it always sends just 1 line unless point is in an old input region (assuming comint-use-prompt-regexp is not set, which it usually is not). I have called this modified function cocoa5-get-old-input.

So that my fn is called, I have made cocoa5-comint-mode set the value of comint-get-old-input to cocoa5-get-old-input; unfortunately, this appears to be a global assignment, so it will probably affect any buffer which is in comint mode.

I'll try experimenting with my hacked version for a while; if I encounter no nasty surprises, I'll check in.

NOTE one thing my fix does not do is let the user select a region in a cocoa5 buffer and send the whole region as input just by pressing RTN; instead you must copy-and-paste the region to the bottom of the buffer, then use RTN to send it as input.

#6 Updated by John Abbott almost 8 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 20 to 90

Anna says it seems to work mostly OK for her (on emacs 22 or 23). She did report a problem with sending only part of a line if she edits some output (in the cocoa5 execution buffer) before pressing RTN.

An alternative approach could be to have a key sequence (Shift+RTN?) which copies the current line to the last line, and moves the cursor there too.

I'll check whether her problem exists for me (on emacs 24.5).

NOTE I could not reproduce the problem Anna reported.

#7 Updated by John Abbott almost 7 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

This has been in feedback for 10 months. I've not noticed any "nasty surprises" using Emacs, so it is probably OK now.
Closing.

#8 Updated by Anna Maria Bigatti almost 7 years ago

Great thanks!! I realized only now this was the problem I had!
Teasted: it works on old emacs too.

#9 Updated by Anna Maria Bigatti almost 7 years ago

  • Estimated time set to 3.01 h

Also available in: Atom PDF