How do you make SAS toolbar available to ALL windows? - toolbar

I am using SAS 9.1 and wish to make my toolbar available regardless of which window is in 'focus' (eg log, editor, output).
My code looks like this:
libname temp678 "\\MyDrive\Team Autoexec";
dm "toolload bar temp678.profile.MycustomToolbar";
libname temp678 clear;
However when I run it, it only gets applied to the Log window! I've read somewhere that SWITCHING needs to be turned off, but this seems like it may have been a V6.1 option and can't find it in Base SAS windowing environment...

There's a TOOLSWITCH command in 9.1 but I don't think that will do what you want here. Unless someone is aware of a specific option to do what you want, I'd suggest just duplicating your additional buttons on both the log and editor toolbars.

Related

Indenting VSCode like RStudio

I'm using VS Code and i miss RStudio's ctrl+i to indent lines.
I've read stuff online about LSP and other extensions and formatting with shift+alt+F but all i get is linter.
So, whats the equivalent if is there at all?
Found a solution but there a few things to take note.
First, VSCode notive options are language-agnostic, meaning it can't indent R code 'cause it doesn't understand it. You got to download extensions to make i work.
Extensions required are
Yuki Ueda's R for language support
REditorSupport's R LSP Client
Also, in order to R LSP Client to work, CRAN package {languageserver} is required.
Then, usage. If you're working functions, differently from RStudio in which one can hit ctrl+i and that'd indent that specifically line or selection, this solution works only if one selects the entire function. If you have functions inside another, you gotta indent everything (won't work for just a foo inside another).

how to change line length on Rterm.exe

I am using R 2.15.2 on windows XP.
I was used to use Rgui.exe but it was lacking the UNIX standards I like to use like CTRL+R <=>backward research and CTRL+U <=>erase line ...
If I missed something please tell me !
Then I tried Rterm.exe (which looks identical to R.exe to me) which has all those nice features. I found how to tune it right clicking on the top of the window to set height-width (it is like tuning the window you get from cmd.exe).
The problem is that now I cannot see on the window more than 75 characters, with a $ at the end: like this:
R) ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp$
Not sure if it is a R option of a windows one, but if I set options("width"=180) I can see data.frame on the full width of the window...
Not sure what is happening, can I modify this?
We still do not know the answer to that one, so I guess 50 pts goes to Oscar de León... good for him to bad for me...
Sadly, it appears to be built in.
There used to be a problem with R when trying to print long strings. Apparently it was fixed first in Rterm and other versions of R before being fixed in Rgui.
When Rgui was fixed, possibly it was by a different means, since this issue can be fixed in Rgui but not other windows versions of R. You can change the width of the console for output both in Rgui and (later) Rterm.
The prompt is another story. It is actually not the same as the output space, and thus is controlled with a different option; but, this only works for Rgui. To do it, set pgcolumns=180 in the Rconsole file under [R HOME]\etc\. This modifies the width of the internal pager of the Rgui console, and effectively enables you to type up to 180 characters per input prompt.
Possibly there is a way to integrate that behavior into Rterm, and maybe Duncan Murdoch can point you in the correct direction (or prove me completely wrong).
I'm not really sure what is being requested. If what is needed in RTerm.exe is to display the end of a long line (and position the cursor there), then use CTRL-E. You can go back to the beginning of a line with CTRL-A. One can go back and forth repeatedly as needed until the line is use ENTER.
The control character of readline seem to be active, for instance CTRL-P scrolls back one command and CTRL-N brings up the "next" command from history if you hit CTRL-P too many times. (These are the same behavior as the up/down arrow keys.) See link for other expected readline behaviors.
On my machine alt-f and alt-b (which should have been meta-f and meta-b) did not natively move forward or backward by words, but ESC-b and ESC-f did so on a line that exceeded the console width and had the $'s marking either the right or left extents as having further material to look consider.
If you want to wrap display lines, then you need to consider alternatives or additions to readline: link, but that is an untested suggestion and merely the results of a search for: "readline wrap display".
The command should be options(width = 180) (without the quotes around width), but when you run Rterm in the Windows shell, it doesn't respect changes to this value; it just prints output as wide as the console.
The best way of working with R is (almost always) to use an IDE. Try emacs + ESS or one of the many vim plugins (R.vim, vim-R, VIM:r-plugin) if you want something UNIXy.

Is there a hack to be able to run the current line or selection in RStudio without moving the cursor?

UPDATE (April 2013): As per answer below, RStudio no longer jumps cursor on selection.
I'm running RStudio 0.97.168.
I like to use the script editor in RStudio like a console. Thus, I run a line of code and then edit it a little bit and re-run it. I often also explore objects by selecting some of the code and running the selection and then progressively altering the selection. At present RStudio always moves the cursor after running a line of code. The cursor can move to a variety of places. Typically the cursor moves to the next line of R code, but depending on the context, it could move to the end of the code block or the next line. It's really frustrating having to constantly move the cursor back to where I want it.
While I often appreciate the default cursor movement behaviour, I'd like to have the option to run the selection or the current line without the cursor moving.
I've raised this as a suggestion on RStudio support.
I'd like to be able to have a shortcut key like "Cmd+Alt+Enter" that runs the current line or selection and does not move the cursor in the script editor.
I realise that this is not currently supported, but I was wondering whether there might be some creative hack that could enable the cursor not to move after running a command or even a patch or perhaps some sort of external macro.
For anyone who ends up here in 2020:
Ctrl(or Cmd) + Enter: Will run current line and jump to the next one. If a code portion is selected, run the selected code without jumping further.
Alt + Enter: – Will run the current line of code without moving the cursor to the next line, useful if you want to run it multiple times.
(Source)
For this kind of flexibility, I suggest you use the editor Sublime Text 2, add in the package installer by Will Bond and then install the SublimeREPL package which will allow you to use an R interpreter within ST2 (or BASH prompt, Python / Ruby / whatever interpeter, concurrently if you wish).
You can then alternate between your code and the interpreter without lifting your fingers from the keyboard and your cursor will be at the same point every time when you want to switch back.
Sublime Text will also allow you to write a custom keybinding to automate this task.
I cannot recommend using Sublime Text 2 highly enough when coding for R. You can even pass files directly from ST2 into RStudio very easily if you like using the plot panes (very easy to do with the SidebarEnhancements package in ST2).
RStudio is awesome for many things -- especially now with Knitr, builds etc etc. But ST2 with an R REPL is many orders of magnitude more powerful for general code writing / editing than RStudio.
Sorry it's not RStudio specific, but it is a nice workaround!
I updated to version 0.98.83 of RStudio using the daily build section.
It appears that at some point in recent versions of RStudio, the cursor no longer jumps when code is run from a selection in the script window.
That's great news.

R unix terminal pager

I'm using R on OS X 10.6 and I prefer the unix console to the R.app for my work. If I issue a help command eg ?print the help content opens through a pager (i tried most and less), which however then hides out the content if I exit it bringing me back to the R input line.
What I really want is that the pager output stays on the screen even after I exit it back to R (hitting q).
I get this desired behaviour on other Readline-based Cli like psql for example, but not on R. Any hints on how this gets configured would be greatly appreciated.
The console pager that R uses can be set with the options function. With less, the -X option suppresses the terminal clearing at exit. So, if the less binary is located in "/bin" (not sure where it's located in OS X), this should work:
> options(pager="/bin/less -X")
If you want this to be the default behavior every time you start R, you can place the above command in your ~/.Rprofile file, which is run automatically at startup.
Alternatively, you can set a export LESS=-XF in ~/.bashrc and this will have an effect across all programs that use less as a pager. The F option would further exit straight away if the content is less than a page, which I find quite useful.

Preventing what was/were previously copied on to my clipboard from appearing on R Console when using R

I am having some problems with my clipboard contents when using R. When I run my scripts/commands in tinn-r, very often I would get something that I had ran earlier pasted onto my R Console instead of the command that I have just selected.
To get over this, I would go to my clipboard and delete its content(text/syntax). However, the same text/syntax that I had just deleted would re-appear on my clipboard and would again appear on my R Console when trying to run a different syntax from my tinn-r.
Good luck. Tinn-R seems to be a particularly buggy way of interacting with R. Though it takes some effort to set up, the StatET plugin interface from Eclipse has been working way better for me than Tinn-R ever did.

Resources