bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Transitional work on no-readline?


From: Elias Mårtenson
Subject: Re: [Bug-apl] Transitional work on no-readline?
Date: Fri, 5 Sep 2014 23:57:21 +0800

It seems as though it does. When I enable --rawCIN, I'm not getting a prompt anymore.

What is the solution for that?

Regards,
Elias


On 5 September 2014 20:34, Juergen Sauermann <address@hidden> wrote:
Hi Elias,

it should not affect emacs mode. The only thing I have removed is the push-back of the prompt into stdin. This
has previously cause the -prompt to be displayed twice: on stdout (as ⍞← output) and on stderr (as ←⍞ prompt).
And the removed push-back (using ungetc()) was not portable because ungetc() guarantees only one character
push-back and not 6 as a normal APL prompt.

You can check if the latest SVN  version still works - there should be no more changes in the --rawCIN mode.

/// Jürgen


On 09/05/2014 12:29 PM, Elias Mårtenson wrote:
Does any of this affect the Emacs mode? Today it's using --rawCIN when communicating with the backend.

Regards,
Elias


On 5 September 2014 18:27, Juergen Sauermann <address@hidden> wrote:
Hi,

I have restored the previous behavior of --rawCIN, except for ungetc() of the prompt (which was a non-portable feature).
SVN 453.

The new interactive non-readline code can now be tried out with --noRL (this command line option will go away soon
when the readline replacement is finished.

I am actually grateful for feedback at an early state because without David's comment the old 
--rawCIN would have gone
forever.
Now it will survive readline.

/// Jürgen


On 09/04/2014 11:32 PM, David Lamkins wrote:
Of course. But it helps to know what's changing in order to anticipate the consequences and to be able to raise concerns and propose solutions.


On Thu, Sep 4, 2014 at 1:16 PM, Blake McBride <address@hidden> wrote:
Shouldn't we just wait for the transition to be completed before we worry about the other interfaces?  I'd just use an old copy of GNU APL for now.  Trying to keep pace with a moving target and trying to keep everything in sync during all these changes seems like a huge waste of time and a pain for everyone.


On Thu, Sep 4, 2014 at 3:00 PM, David Lamkins <address@hidden> wrote:
I tried setting up a profile to zero the *-SEQUENCE settings. It didn't seem to have any effect. I'll revisit this later when I have more time.

That said, the control sequences don't match anything in the preferences file.

This is typical of what I see:

 <esc>[30;8H<esc>[99B <esc>[30;9H<esc>[99B <esc>[30;10H<esc>[99B <esc>[30;11H<esc>[99B <esc>[30;12H<esc>[99B <esc>[30;13H<esc>[99B1<esc>[30;14H<esc>[99B




On Thu, Sep 4, 2014 at 11:43 AM, David Lamkins <address@hidden> wrote:
Thanks. I'll experiment tonight with setting up a profile for aplwrap.


On Thu, Sep 4, 2014 at 11:23 AM, Juergen Sauermann <address@hidden> wrote:
Hi David,

yes, this is work in progress. I have committed it together with the ⎕SVQ fix.
Normally the ANSI sequences should only be visible with --rawCIN which will become
the standard mode after libreadline has been removed (soon).

A way to get rid of the color sequences in the meantime might be to define their
ANSI sequences as 0 in your preferences file.

I guess updating APserver.cc alone should fix the ⎕SVQ problem.

/// Jürgen


On 09/04/2014 07:29 PM, David Lamkins wrote:
Juergen,

In SVN 450 through 452, GNU APL emits a lot of ANSI terminal controls to a piped stderr (i.e. in aplwrap) even in the case where --noColor is passed on the command line.

Is this a consequence of work-in-progress on removing readline? If so, I'll hold at SVN 449 until the work is done.




--



--




--





reply via email to

[Prev in Thread] Current Thread [Next in Thread]