^M in compilation buffers

^M in compilation buffers

[Sam Steingold]

Hi,
omake prints progress bar using the usual ^M terminal trick.
last week it was parsed nicely by emacs, i.e., the progress bar was updated 
in-place and, eventually, overwritten (by the last omake message).
today, the freshly compiled cvs head emacs does not do that: the ^M character 
is inserted into the *compilation* buffer as is (instead of being interpreted 
as C-a C-k):
[===                   ] 01358 / 11812^M [======                ] 02995 / 
11837^M [======                ] 03039 / 11837^M [======                ] 03244 
/ 11849^M [======                ] 03337 / 11849^M [======                ] 
03428 / 11849^M [======                ] 03502 / 11849^M [======= 
  ] 03598 / 11849^M [=======               ] 03659 / 11849^M [======= 
      ] 03692 / ....
any advice?
Thanks
Sam.

Re: ^M in compilation buffers

[Sam Steingold]

Sam Steingold wrote:
> omake prints progress bar using the usual ^M terminal trick.
> last week it was parsed nicely by emacs, i.e., the progress bar was 
> updated in-place and, eventually, overwritten (by the last omake message).
> today, the freshly compiled cvs head emacs does not do that: the ^M 
> character is inserted into the *compilation* buffer as is (instead of 
> being interpreted as C-a C-k):
> [===                   ] 01358 / 11812^M [======                ] 02995 
> / 11837^M [======                ] 03039 / 11837^M 
> [======                ] 03244 / 11849^M [======                ] 03337 
> / 11849^M [======                ] 03428 / 11849^M 
> [======                ] 03502 / 11849^M [=======  ] 03598 / 11849^M 
> [=======               ] 03659 / 11849^M [=======      ] 03692 / ....

this patch fixes *compilation*:



--- compile.el.~1.485.~	2009-01-05 16:47:34.000000000 -0500
+++ compile.el	2009-02-17 11:31:48.001949000 -0500
@@ -1739,6 +1739,8 @@ Just inserts the text, and runs `compila
                ;; point at `process-mark' scroll along with the output, but we
                ;; now use window-point-insertion-type instead.
                (insert string)
+              (unless comint-inhibit-carriage-motion
+                (comint-carriage-motion (process-mark proc) (point)))
                (set-marker (process-mark proc) (point))
                (run-hooks 'compilation-filter-hook))
            (goto-char pos))))))


alas, this cannot be done from within compilation-filter-hook because 
(process-mark proc) is overwritten before compilation-filter-hook is called.
(also, comint.el calls comint-carriage-motion from comint-output-filter, not a 
hook).

Re: ^M in compilation buffers

[Stefan Monnier]

> omake prints progress bar using the usual ^M terminal trick.
> last week it was parsed nicely by emacs, i.e., the progress bar was updated
> in-place and, eventually, overwritten (by the last omake message).

Are you sure it was parsed nicely last week in compilation-mode?
I see no related changes to compile.el.
AFAIK this has never worked in compilation mode, only in comint-mode.


        Stefan

Re: ^M in compilation buffers

[Sam Steingold]

On Tue, Feb 17, 2009 at 1:33 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> omake prints progress bar using the usual ^M terminal trick.
>> last week it was parsed nicely by emacs, i.e., the progress bar was updated
>> in-place and, eventually, overwritten (by the last omake message).
>
> Are you sure it was parsed nicely last week in compilation-mode?

I think so.

> I see no related changes to compile.el.

me neither.

> AFAIK this has never worked in compilation mode, only in comint-mode.

well, now that I fixed that, it works for me in compilation mode too.

-- 
Sam Steingold <http://sds.podval.org>

Re: ^M in compilation buffers

[Stefan Monnier]

>>> omake prints progress bar using the usual ^M terminal trick.
>>> last week it was parsed nicely by emacs, i.e., the progress bar was updated
>>> in-place and, eventually, overwritten (by the last omake message).
>> Are you sure it was parsed nicely last week in compilation-mode?
> I think so.
>> I see no related changes to compile.el.
> me neither.
>> AFAIK this has never worked in compilation mode, only in comint-mode.
> well, now that I fixed that, it works for me in compilation mode too.

Yes, I think the change is good, but I just want to make sure we
understand what's going on.


        Stefan

Re: ^M in compilation buffers

[Glenn Morris]

Sam Steingold wrote:

> well, now that I fixed that, it works for me in compilation mode too.

In compilation-filter:
compile.el:1744:23:Warning: reference to free variable
    `comint-inhibit-carriage-motion'

In end of data:
compile.el:2352:1:Warning: the function `comint-carriage-motion' is
not known to be defined.


cd etc/refcards

emacs -Q

M-x compile make -k cs-dired-ref.pdf RET   ; without using tab completion

error in process filter: unless: Symbol's value as variable is void: comint-inhibit-carriage-motion

Re: ^M in compilation buffers

[Sam Steingold]

On Wed, Feb 18, 2009 at 12:13 AM, Glenn Morris <rgm@gnu.org> wrote:
> Sam Steingold wrote:
>
>> well, now that I fixed that, it works for me in compilation mode too.
>
> In compilation-filter:
> compile.el:1744:23:Warning: reference to free variable
>    `comint-inhibit-carriage-motion'
>
> In end of data:
> compile.el:2352:1:Warning: the function `comint-carriage-motion' is
> not known to be defined.
>
>
> cd etc/refcards
>
> emacs -Q
>
> M-x compile make -k cs-dired-ref.pdf RET   ; without using tab completion
>
> error in process filter: unless: Symbol's value as variable is void: comint-inhibit-carriage-motion
>

fixed in the cvs.
thanks.

-- 
Sam Steingold <http://sds.podval.org>