Am Fri, 1 Sep 2017 07:20:58 -0500 (CDT)
schrieb luke-tier...@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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
