bug#21162: changing terminal size

bug#21162: changing terminal size

[Francesco Potortì]

>Hi Francesco, thanks for sticking with this despite resistance / lack
>of interest.
>
>Is there a reason you omitted the Octave mailing list on this reply?

I think it is of interest only to a tiny minority of people on that
list, but if you think otherwise please add it back when answering.

By the way, I put in copy the bug reporting address and interested Emacs
people.

>On Thu, Aug 6, 2015 at 9:26 AM, Francesco Potortì wrote:
>> 1) --no-line-editing is used to prevent the Emacs inferior Octave from
>>    intepreting tabs.  That was the original intention.  In fact, this
>>    just happened to me while copying and pasting column of numbers from
>>    another buffer to the inferior Octave buffer and having Octave trying
>>    to autocomplete.
>
>Ok, that makes sense.

Note that this is the only reason why --no-line-editing is used at all:
all other control sequences are intercepted by Emacs adn are not passed
to the inferior Octave at all.  This is true for tabs also, but if you
copy-paste from somewhere else into an inferior Octave buffer, you get
strange results without --no-line-editing if what you paste contains
tabs.

>> 2) --no-line-editing prevents the Emacs inferior Octave from adapting to
>>    the buffer width (height is not relevant in this context)
>
>Agreed, this should be fixed in one way or another.
>
>> 3) --no-line-editing disables some functions used by Octave for FLTK.
>>
>> Adding support for COLUMNS solves problem 2.
>>
>> At this point, finding the right solution requires knowing what is the
>> purpose of the --no-line-editing: is it possible / desirable to change
>> its behaviour?
>
>If you mean conceptually, I think the meaning is literally "do not use
>the readline library for input". IOW, Octave takes its input from
>either fgets() or readline(). No line editing means the user's text is
>read directly by Octave as provided on the standard input stream. Line
>editing allows the user to edit the current line, recall previous
>lines in the saved history, kill and yank text, etc, before submitting
>it to Octave.
>
>This is the concept that I think Emacs (correctly) wants to disable.
>In this case the user is using Emacs to edit text in a buffer and
>submitting it to Octave for evaluation on a line-by-line basis.

As I explained above, while this is true conceptually, it is not true in
practice.  If there was an Octave option --disable-tab-expansion, that
would pefectly do as far as Emacs is concerned.  So, if
--no-line-editing was in fact devised for Emacs' sake, then it is
definitely overkill, and one possibility is to simply change its
behaviour.  If it was intended for some other purpose, then changing its
behaviour is out of question.

>Your other points are side effects not tied to the main purpose of
>using readline for input line editing. I think we all agree #2 is
>relatively easy to fix in multiple ways.
>
>Problem 3 is bug #37795 [1] that has no progress and no suggestions
>for how to continue. If we don't use readline to get input from the
>user, then we currently have no way to perform asynchronous event
>execution while the input is idle and FLTK does not behave correctly.
>I think that the Qt toolkit does not suffer from this limitation
>because it is multithreaded and does not rely on readline's idle input
>callback feature.
>
>[1]: https://savannah.gnu.org/bugs/?37795

As a conclusion of my observations above:

A. if --no-line-editing was introduce because of the Emacs inferior
   Octave mode

B. if it is reasonable to assume that --no-line-editing is not used by
   any other application

C. if there is a way to leave readline enabled, but disable tab expansion

then one can change the --no-line-editing behaviour to just disable tab
expansion.

Or, if only C is certainly true, one can deprecate and undocument
--no-line-editing and add a separate option --disable-tab-expansion for
use in Emacs inferior Octave mode.

-- 
Francesco Potortì (ricercatore)        Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
(entrance 20, 1st floor, room C71)     Web:    http://fly.isti.cnr.it