R devel - Sep 2017 - patch: automatically adjust width option when terminal is resized

On Fri, 1 Sep 2017, Ralf Goertz wrote:
> Am Mon, 28 Aug 2017 09:33:31 +0200
> schrieb Ralf Goertz <r_goertz at web.de>:
>
>
> Hello, me again
>
>> Hi,
>>
>> I guess there have been discussions about this in the past and from
>> what I understood hooking an R-function to facilitate automatic
>> adjustment is problematic. So why not doing it like this:
>
> would anybody care to comment? I think it is quite important to have an
> automatic adjustment of R's idea of the width of its terminal window. I
> quite often find myself in the situation that I started R in its own
> (wide) xterm. Then I look at some data frame or vector like this (using
> small width here in order to stay within the ususal width of a text
> posting):
>
>> (r=rnorm(20))
> [1]  0.05672115  0.59047528  0.41337747  0.01737960 -0.78133482
> [6]  0.49218494 -0.78793312 -1.26125820  0.56748784  0.65725277
> [11] -0.04419487  0.14463142 -0.48613097  0.42789592  1.22424913
> [16]  0.43272842 -0.70089673  0.14313221 -0.97159181 -1.29164930
>
>
> Then I want to plot something
>
>> hist(r)
>
> Because the plot window and the xterm don't fit side by side I resize
> the xterm to be smaller. Then I want to see the data again:
>
>> r
> [1]  0.05672115  0.59047528  0.41337747  0.01737960 -
> 0.78133482
> [6]  0.49218494 -0.78793312 -1.26125820  0.56748784
> 0.65725277
> [11] -0.04419487  0.14463142 -0.48613097  0.42789592
> 1.22424913
> [16]  0.43272842 -0.70089673  0.14313221 -0.97159181 -
> 1.29164930
>
> This is ugly and hard to read. Many good programs like vim adjust their
> internal width representation automatically. Why shouldn't R do the
> same? It seems quite easy, at least when readline is used:
>
>
> --- R-3.4.1/src/unix/sys-std.c  2017-03-24 00:03:59.000000000 +0100
> +++ R-3.4.1/src/unix/sys-std.patched.c  2017-08-28 09:16:02.714204023
> +0200 @@ -1005,6 +1005,9 @@
>                // introduced in readline 4.0: only used for >= 6.3
> #ifdef HAVE_RL_RESIZE_TERMINAL
>                rl_resize_terminal();
> +               int rl_height, rl_width;
> +               rl_get_screen_size(&rl_height,&rl_width);
> +               R_SetOptionWidth(rl_width);
> #endif
>             }
> #endif
The 'width' option affects more than printing to the console; it also
affects, for example, printing to a file via sink() or
capture.output(). So doing this unconditionally would not be a good
idea.  Making it available as an option for those who want it seems
reasonable but still involves a lot more work than these three lines.
It requires designing a protocol for enabling this feature, ideally in
a way that can be made to work well on other interfaces (e.g. Windows,
Mac, RStudio) as well, and it requires documenting all this in a
sensible place. A more complete proposal might well be considered for
adoption.

Best,

luke
>
>> I tried it out and it works perfectly here. Of course there should be
>> an option to switch this on and off but you get the idea. What do you
>> think?
>
> It would be much appreciated if you considered it.
>
> Thanks Ralf
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   luke-tierney at uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu

Am Fri, 1 Sep 2017 07:20:58 -0500 (CDT)
schrieb luke-tierney at uiowa.edu:
> On Fri, 1 Sep 2017, Ralf Goertz wrote:
> 
> > Many good programs like vim adjust their internal width
> > representation automatically. Why shouldn't R do the same? It
seems
> > quite easy, at least when readline is used:
> >
> >
> > --- R-3.4.1/src/unix/sys-std.c  2017-03-24 00:03:59.000000000 +0100
> > +++ R-3.4.1/src/unix/sys-std.patched.c  2017-08-28
> > 09:16:02.714204023 +0200 @@ -1005,6 +1005,9 @@
> >                // introduced in readline 4.0: only used for >= 6.3
> > #ifdef HAVE_RL_RESIZE_TERMINAL
> >                rl_resize_terminal();
> > +               int rl_height, rl_width;
> > +               rl_get_screen_size(&rl_height,&rl_width);
> > +               R_SetOptionWidth(rl_width);
> > #endif
> >             }
> > #endif  
> 
> The 'width' option affects more than printing to the console; it
also
> affects, for example, printing to a file via sink() or
> capture.output(). So doing this unconditionally would not be a good
> idea.  Making it available as an option for those who want it seems
> reasonable but still involves a lot more work than these three lines.
> It requires designing a protocol for enabling this feature, ideally in
> a way that can be made to work well on other interfaces (e.g. Windows,
> Mac, RStudio) as well, and it requires documenting all this in a
> sensible place. A more complete proposal might well be considered for
> adoption.
Hi Luke,

thanks for your explanation. I am not at all familiar with the R source
code nor am I a professional programmer. I found the place to do that
simply by grepping for the signal SIGWINCH. I was, however, aware that
it would need more than those three lines.

As to the other uses of the width option, wouldn't it make sense to have
a separate option for output redirection? Or even have file output
always use the same fixed width, say 80? After all, if the output is
saved to a file this file is probably meant to be viewed in another
context than the R terminal. And even if the width of file output is
affected I don't see any real harm since that is the way it is now. If
one really needs a specific width in such a case s/he can request it by
setting the option manually before outputting to a file. On the other
hand, the documentation says

	 ?width?: controls the maximum number of columns on a line used in
		  ?
		  ?Print.h? and can be changed by re-compiling R.)  Some R
		  consoles automatically change the value when they are resized.

If *some* consoles already do automatically change the value when
resized why should an instance of R running in a pure terminal emulator
not be allowed to do so? In case there is a good reason, my idea for the
option is as follows. It stays as it is but it can also be negative
indicating that SIGWINCH will lead to an adjustment. That way nothing
changes for those users who do not bother at all. Also, this can easily
be documented, e.g. by appending the following line to the block quoted
above.

		  Others do so when 'width? is negative.

Interfaces which don't or can't use that feature or functions like print
merely have to call "abs(GetOptionWidth())" instead of
"GetOptionWidth()". Luckily, both "int GetOptionWidth()" and
"int
attribute_hidden R_SetOptionWidth(int w)" are defined in terms of int,
so it is possible to send and receive negative values. I don't know
about the Windows or Mac interface. But I would imagine that they can
also be made to swallow negative width values rather easily.

Digging a little more I found that there had been the setwidth package
which basically did what I am asking for. Here
<https://groups.google.com/forum/#!topic/vim-r-plugin/SeQCNWxEPwk> the
author of that package (Jakson Aquino) explains that it stopped working
because R started to catch SIGWINCH itself. He continues: ?Perhaps this
feature could be implemented directly in R if someone requested it to
the R Core Team.? There really seems to be a need for this.

Ralf

Accidentally dropped R-devel from this reply.

On Fri, 1 Sep 2017, luke-tierney at uiowa.edu wrote:
> On Fri, 1 Sep 2017, Ralf Goertz wrote:
>
>> Am Fri, 1 Sep 2017 07:20:58 -0500 (CDT)
>> schrieb luke-tierney at uiowa.edu:
>> 
>>> On Fri, 1 Sep 2017, Ralf Goertz wrote:
>>> 
>>>> Many good programs like vim adjust their internal width
>>>> representation automatically. Why shouldn't R do the same?
It seems
>>>> quite easy, at least when readline is used:
>>>> 
>>>> 
>>>> --- R-3.4.1/src/unix/sys-std.c  2017-03-24 00:03:59.000000000
+0100
>>>> +++ R-3.4.1/src/unix/sys-std.patched.c  2017-08-28
>>>> 09:16:02.714204023 +0200 @@ -1005,6 +1005,9 @@
>>>>                // introduced in readline 4.0: only used for
>= 6.3
>>>> #ifdef HAVE_RL_RESIZE_TERMINAL
>>>>                rl_resize_terminal();
>>>> +               int rl_height, rl_width;
>>>> +              
rl_get_screen_size(&rl_height,&rl_width);
>>>> +               R_SetOptionWidth(rl_width);
>>>> #endif
>>>>             }
>>>> #endif
>>> 
>>> The 'width' option affects more than printing to the
console; it also
>>> affects, for example, printing to a file via sink() or
>>> capture.output(). So doing this unconditionally would not be a good
>>> idea.  Making it available as an option for those who want it seems
>>> reasonable but still involves a lot more work than these three
lines.
>>> It requires designing a protocol for enabling this feature, ideally
in
>>> a way that can be made to work well on other interfaces (e.g.
Windows,
>>> Mac, RStudio) as well, and it requires documenting all this in a
>>> sensible place. A more complete proposal might well be considered
for
>>> adoption.
>> 
>> Hi Luke,
>> 
>> thanks for your explanation. I am not at all familiar with the R source
>> code nor am I a professional programmer. I found the place to do that
>> simply by grepping for the signal SIGWINCH. I was, however, aware that
>> it would need more than those three lines.
>> 
>> As to the other uses of the width option, wouldn't it make sense to
have
>> a separate option for output redirection? Or even have file output
>> always use the same fixed width, say 80? After all, if the output is
>> saved to a file this file is probably meant to be viewed in another
>> context than the R terminal. And even if the width of file output is
>> affected I don't see any real harm since that is the way it is now.
If
>> one really needs a specific width in such a case s/he can request it by
>> setting the option manually before outputting to a file.
>
> This could have been designed differently, but it wasn't and making
> chnages would cause code to break.
>
>> On the other
>> hand, the documentation says
>>
>> 	 ?width?: controls the maximum number of columns on a line used in
>> 		  ?
>> 		  ?Print.h? and can be changed by re-compiling R.)  Some R
>> 		  consoles automatically change the value when they are 
>> resized.
>
>
> Good point.
>
> The Windows R GUI does this if a preference option is set; I don't
> know what the default is from just a quick look at the sources.
>
> RStudio does this by default and there is no obvious way, to me at
> least, to turn it off, which is unfortunate given the
> sink/capture.output issues.
>
> I made changes to R-devel in r73180 to set width if the you set
> options(setWidthOnResize = TRUE). By default this option is not set
> and the width option is not changed. We'll see if it causes any
> problems.
>
> Best,
>
> luke
>
>
>> If *some* consoles already do automatically change the value when
>> resized why should an instance of R running in a pure terminal emulator
>> not be allowed to do so? In case there is a good reason, my idea for
the
>> option is as follows. It stays as it is but it can also be negative
>> indicating that SIGWINCH will lead to an adjustment. That way nothing
>> changes for those users who do not bother at all. Also, this can easily
>> be documented, e.g. by appending the following line to the block quoted
>> above.
>>
>> 		  Others do so when 'width? is negative.
>> 
>> Interfaces which don't or can't use that feature or functions
like print
>> merely have to call "abs(GetOptionWidth())" instead of
>> "GetOptionWidth()". Luckily, both "int
GetOptionWidth()" and "int
>> attribute_hidden R_SetOptionWidth(int w)" are defined in terms of
int,
>> so it is possible to send and receive negative values. I don't know
>> about the Windows or Mac interface. But I would imagine that they can
>> also be made to swallow negative width values rather easily.
>> 
>> Digging a little more I found that there had been the setwidth package
>> which basically did what I am asking for. Here
>>
<https://groups.google.com/forum/#!topic/vim-r-plugin/SeQCNWxEPwk> the
>> author of that package (Jakson Aquino) explains that it stopped working
>> because R started to catch SIGWINCH itself. He continues: ?Perhaps this
>> feature could be implemented directly in R if someone requested it to
>> the R Core Team.? There really seems to be a need for this.
>> 
>> Ralf
>> 
>
>
-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   luke-tierney at uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu

Am Fri, 1 Sep 2017 14:11:19 -0500 (CDT)
schrieb luke-tierney at uiowa.edu:
> On Fri, 1 Sep 2017, Ralf Goertz wrote:
> 
> 
> > On the other
> > hand, the documentation says
> >
> > 	 ?width?: controls the maximum number of columns on a line
> > used in ?
> > 		  ?Print.h? and can be changed by re-compiling R.)
> > Some R consoles automatically change the value when they are
> > resized.  
> 
> 
> Good point.
> 
> The Windows R GUI does this if a preference option is set; I don't
> know what the default is from just a quick look at the sources.
> 
> RStudio does this by default and there is no obvious way, to me at
> least, to turn it off, which is unfortunate given the
> sink/capture.output issues.
> 
> I made changes to R-devel in r73180 to set width if the you set
> options(setWidthOnResize = TRUE). By default this option is not set
> and the width option is not changed. We'll see if it causes any
> problems.
> 
> Best,
> 
> luke

Thanks Luke, appreciate it.

Ralf