Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUGZILLA #16604] R does not recognize when terminal size changes #5994

Open
MichaelChirico opened this issue May 18, 2020 · 7 comments
Open

Comments

@MichaelChirico
Copy link
Owner

I am running R 3.2.2 under Arch Linux.

When I use R on the command line and resize the terminal, R does not take note of the changed terminal size. This is apparent when running a command whose output is long enough to wrap onto multiple lines (e.g. "letters"). It is, however, most inconvenient when entering a long command line. When I make the terminal smaller, for instance to share screen space with a plot window, then editing such a multi-line command becomes impossible, because Readline is confused about where the cursor is. Ctrl-A no longer visually takes the cursor to the start of the command, and when I enter some text after pressing Ctrl-A, the terminal becomes a mess of diagonal words. Since my plot commands are often very long (e.g. "plot(...); lines(...); abline(...); ...") and wrap onto multiple lines, and since plotting is what causes me to want to shrink my R terminal window temporarily, this bug is particularly inconvenient during the many occasions when I am trying to fiddle with a plot. I guess since it hasn't been fixed, other people must not be experiencing it with their setup or their way of using R - maybe they have bigger screens - but I noticed some related discussion on Stackoverflow:

http://stackoverflow.com/questions/1172485/how-to-increase-the-number-of-columns-using-r-in-linux

I also saw this bug:

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16259

I, too, find that the COLUMNS environment variable is not updated when the window changes. But this is rather beside the point, because what I want is for R to e.g. trap SIGWINCH and update the width and alert Readline to the change as well. For what it's worth, other command-line programs like Octave and the Unix shells all have the desired behavior.

Thanks for reading...!


METADATA

  • Bug author - Frederick Eaton
  • Creation time - 2015-11-18 19:30:29 UTC
  • Bugzilla link
  • Status - ASSIGNED
  • Alias - None
  • Component - System-specific
  • Version - R 3.2.2
  • Hardware - Other Linux
  • Importance - P5 enhancement
  • Assignee - R-core
  • URL -
  • Modification time - 2016-11-12 15:54 UTC
@MichaelChirico
Copy link
Owner Author

I was looking into working on this bug and came across

https://bugs.python.org/issue23735

The above link documents (and fixes) the same problem in Python.
Apparently there was a change in signal handling behavior in Readline
6.3 due to a recognized need to conform with POSIX standards by not
calling certain functions from within signal handlers. The situation
seems to be well described at the above URL. Also, I believe that the
Python patch could be adapted fairly easily to apply to R.

One implication of the Python discussion is that R may have had the
correct SIGWINCH behavior prior to Readline 6.3. The same would apply
to proper SIGINT handling and Bug 16603. I did not start using R until
fairly recently, so I wouldn't know.


METADATA

  • Comment author - Frederick Eaton
  • Timestamp - 2016-04-25 17:43:44 UTC

@MichaelChirico
Copy link
Owner Author

(In reply to Frederick Eaton from comment #1)

One implication of the Python discussion is that R may have had the
correct SIGWINCH behavior prior to Readline 6.3. The same would apply

I no longer have a system with a pre-6.3 readline and R, but from memory, this did used to work correctly in the past.


METADATA

  • Comment author - Terran
  • Timestamp - 2016-04-28 15:51:44 UTC

@MichaelChirico
Copy link
Owner Author

Created attachment 2071 [details]
fix for Readline 6.3 ignoring-SIGWINCH bug

Let me know what needs to be changed before this can be accepted. Thanks.


METADATA

  • Comment author - Frederick Eaton
  • Timestamp - 2016-05-02 22:10:05 UTC

INCLUDED PATCH

@MichaelChirico
Copy link
Owner Author

Frederick, thank you for the patch. I rebuilt R with it and I can confirm that it fixed the very annoying terminal width issue for me. If I can be of any assistance somehow in getting it accepted into R please let me know.

(In reply to Frederick Eaton from comment #3)


METADATA

  • Comment author - Terran
  • Timestamp - 2016-11-11 23:03:00 UTC

@MichaelChirico
Copy link
Owner Author

(In reply to Terran from comment #4)

Frederick, thank you for the patch.  I rebuilt R with it and I can confirm
that it fixed the very annoying terminal width issue for me.  If I can be of
any assistance somehow in getting it accepted into R please let me know.

(In reply to Frederick Eaton from comment #3)

For some reason we forgot to say here, but this bug was fixed ... indeed (partly) thanks to Frederick's patch for R version R 3.3.2 (and newer) quite a while ago.

So, Terran, did you observe the bug in R 3.3.2 ???


METADATA

  • Comment author - Martin Maechler
  • Timestamp - 2016-11-12 15:50:33 UTC

@MichaelChirico
Copy link
Owner Author

Ah; I just built 3.3.1 (the latest version available as source package for Debian stable), so the patch here applied cleanly for me and fixed the problem. I'll try to verify on a newer version that it's fixed as released and let you know here.


METADATA

  • Comment author - Terran
  • Timestamp - 2016-11-12 15:54:59 UTC

@github-actions
Copy link

I think that the loss to follow-up here indicates that this bug was indeed fixed for R 3.3.2. Corresponding NEWS item:

Versions of the readline library >= 6.3 had been changed so that terminal
window resizes were not signalled to readline: code has been added using a
explicit signal handler to work around that (when R is compiled against
readline >= 6.3). (PR#16604)

METADATA

  • Comment author - Sebastian Meyer
  • Timestamp - 2020-07-09 17:56:03 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant