Re: Space removal from the user input

[Ilya Zakharevich <ilya@math.ohio-state.edu>]

On Sat, Sep 15, 2001 at 12:19:39PM +0000, Karim Belabas wrote:
> On Wed, 5 Sep 2001, Ilya Zakharevich wrote:
> 
> > a1) When GP/PARI reads something, the output is echoed *after* the
> >     whitespace is removed.  Is this intentional, or "it just happens
> >     this way"?
> > 
> > a2) Similarly for the readline's history.  (It contains your's input
> >     with whitespace removed.)
> 
> It was just easier that way.

Hmm, I think that most probably it was me who implemented this, and
most probably I just missed the fact that addhistory() does not copy,
but keeps the pointer, and the space-removal algorithm does it by
modifying the string.

> The one important point was that multiline input
> should be remembered as a single line (much easier to modify user functions
> this way).

Wrong.  It is much easier to modify things when the whitespace you
inserted is preserved.  Especially the newlines which you take care to
insert...

[While writing this, I tried for the first time having {} when
 inputing from the keyboard (as opposed to having explicit newlines
 entered via C-v C-j).  I see that what you input is not added to
 readline history until you finish.  This is a no-no-no.  I think the
 correct strategy when you enter

  { bar;
    baz;
    foo; }

 is to have "{ bar;" and "baz;" available in the history when the
 final line is being entered.  When the final line is entered, these
 "uncomplete" lines should be removed from the history, and a
 "3-line-long" entry should "replace them in history".]

The only drawback of the multiline editing (I mean
readline-with-embedded-new-lines) is that mouse editing (which I
implemented in xterm last week) is currently restricted to
one-wrapped-line mode.  [With my patches to xterm mouse clicks (may)
act as in Emacs, so with ReadLine+XTerm you get all the bests of both
cmdtool and ReadLine.]

> For memory efficiency reasons (not such a concern nowadays of
> course...),

It never was - at least, for readline-in-GP.

> It is not trivial though: the catch is to determine whether input is complete
> or not, and this is hard to do without running the filter (e.g nice things
> like { "}" /* } */ } and so on...). One would have to separate the
> "preprocessor" (removing comments, block delimiters) from the "filter"
> (removing spaces).

I think this is exactly what the *current* implementation does
(witness what happes when you enter { }.)

> > b)  When processing multiline-input from readline, \n is removed too
> >     agressively.  Example: type 
> > 
> > 		  print(1)  ^V  ^J  print(2)  ENTER
> > 
> >     (here ^V and ^J are control-chars).  I see:
> > 
> >   ? print(1)
> >   print(2)
> >     ***   unused characters: print(1)print(2)
> > 
> >     i.e., \n in the input is removed, resulting in a "wrong error".
> > 
> >     Should not filtre() replace '\n' with ';' when in f_READL mode?
> 
> I don't know. 1 ^V^J 2 is definitely not the same as 1; 2 [the former
> should store the results "1" and "2" in the history, and output them both;
> the latter will disregard "1"].

Both should disregard "1".  The history should contain the input in
units specified by the *the user*.  If the user enters ^V^J, he
clearly wants these two lines to be considered as a unit.

When these bugs are fixed, I would think of binding ^J to denote ^V^J
by default.  It is *very convenient* not to fight with the
"long-wrapped-line" mess.

Ilya