Re: update 2.0.2.alpha

[Gerhard Niklasch <nikl@mathematik.tu-muenchen.de>]

In reply to
 Message-Id: <3750.199712181351@mordell.ex.ac.uk.maths.exeter.ac.uk>
 from John Cremona (Maths) <cremona@noether.ex.ac.uk>:

> Dear Karim,

He's away on well-earned Christmas holidays!

> I think I have discovered the problem with gp under emacs under linux
> which Kevin Buzzard had.

I've just reproduced it under Solaris.  It may be specific to some versions
of emacs, and to some versions of readline, but it's not O/S specific.

[...]
> The macros RL_PROMPT_START_IGNORE and  RL_PROMPT_END_IGNORE are
> defined in readline.h.  They are inserted before and after the escape
> sequences which switch colors.  Under emacs (under linux) these
> display in the emacs buffer as ^A and ^B (I think they are '\001' and
> '\002').

Right.

> This stops the code in pari.el from finding the prompt
> properly.

(Unfortunately, omitting them stops readline from finding the prompt
properly.)

> I suggest that the color setting is turned
> off altogether when gp is called with the -emacs switch, probably by
> patching the function setdcolors.

I think this was the intention of setting disable_colors = 1 when the
-emacs option is seen.  Unfortunately, setdcolors seems capable of ondoing
this... but I'm not sure whether this is what causes the problem.


<digression1>
However... when asked nicely, newer (X-)emacses will happily do wonderful
things with colours.  Presumably this would need (considerable?) support
from pari.el to implement.  (I'm aware at least of a Perl mode which paints
all sorts of things each in its own pastel shade, and gets mightily confused
each time a double quote appears inside a comment. ;^)

<digression2>
Waitaminute, this is weird.

When I run a 2.0.2.alpha `gp -emacs' from the command line of a
color_xterm (under linux), and do an strace on it for good measure,
I notice that *no escape or control codes at all are being output
along with the prompt*, and indeed none of the colour settings in
my .gprc are taking effect.  The prompt _is_ a plain unadorned "? ".

When, from emacs with pari.el[c] loaded, I do `C-u M-x gp' and
specify `strace -s51 -o /some/suitable/logfile /path/to/gp' as
the gp executable, however, I can see that the `\1\2' control
thingies *are* being output before and after the "? ".  (No colour
escape sequences, though.)

When I do the same thing but specify `/bin/echo Version 2.0.2'
as the gp executable (admittedly it takes a weird imagination
to come up with these things ;^), I can see that the -emacs option
is being passed correctly to whatever emacs tries to execute as `gp'.

Apparently some of the enquire-about-the-terminal-we're-connected-to
wizardry in gp is coming up with an inappropriate answer when the
`terminal' is an emacs buffer...

Changing the gp-prompt-pattern's initialization string (in pari.el[.in]) to

  "^---- (type return to continue) ----\\|^[\C-a\C-b]*\\?[\C-a\C-b\C-j\t ]*"

resolves the deadlock, but causes the ^A^B pairs to be displayed in the
*PARI* buffer, which isn't nice either.
</digressions>


Other than that, try changing line 469 of src/gp/gp.c to read

    promptbuf = (test_mode || under_emacs) ? prompt: do_prompt();

and again line 505:

	promptbuf = under_emacs ? prompt : do_prompt();

(Seems to do the trick here, unless I've missed another occurrence outside
the main loop.)

And probably, unless and until something more appropriate happens, gp's
prompt-morphing capabilities should not be used when running under emacs.
(M-x gp-set-prompt doesn't work for me anyway;  not even its own prompt
comes out right.)


Joyeuses fetes de Noel a tous,
Gerhard