similar to: A bug understanding F relative to FALSE?

But if I type > "?" the output is [1] "?" so seemingly it can be represented. Or, am I wrong? Best Iago ________________________________ De: Tomas Kalibera <tomas.kalibera at gmail.com> Enviat el: divendres, 13 de setembre de 2019 11:24 Per a: IAGO GIN? V?ZQUEZ <i.gine at pssjd.org>; r-devel at r-project.org <r-devel at r-project.org> Tema: Re: [Rd]

On Fri, Sep 13, 2019 at 11:53 AM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > On 9/13/19 11:37 AM, IAGO GIN? V?ZQUEZ wrote: > > But if I type > > >"?" > > the output is > > [1] "?" > > so seemingly it can be represented. Or, am I wrong? > > In RGui you can print the string, because RGui is a Windows Unicode >

I have a chinese character on a data frame, but the output of printing it is its UTF-8 code. Concretely, the character is ? and the code is U+6703. Following the code I arrive to the instruction > base::format.default("?") which prints [1] "<U+6703>" I do not know which is the extent of this behaviour either if it follows on most recent versions of R. Is it

Dear all, I have just detected what seems a minor inconsistence with data types. If one unlists a POSIXlt time with GMT zone gets a numeric vector, since the POSIXlt list has no `zone` element, while if one unlists a POSIXlt time with a non GMT zone (also non specifying tz if the Sys.timezone is not GMT) gets a character vector due to including the `zone` element. > x <-

As others have pointed out, this is expected behaviour. Let me get on that hill I'll die on: it is absolutely not suitable. It is way beyond time to remove T and F as unprotected kind-of-synonyms for TRUE and FALSE, given the amount of times I had to point out that: T <- t(matrix(0:3,nrow=2)) isTRUE(T) was the reason the code didn't do what it's supposed to do. (Also don't use

On 2/9/24 21:39, Iago Gin? V?zquez wrote: > Duncan, do you think it's worth to comment this in R-devel list? Duncan filed a bug report via R bugzilla (thanks). There is no way to disable this functionality and it has existed for very long time, I tested that at least in R 3.0. Optionally ending the session was I believe intentional with Ctrl+D, when the input is empty, and it is also

Duncan, do you think it's worth to comment this in R-devel list? Iago ________________________________ De: CALUM POLWART <polc1410 at gmail.com> Enviat el: divendres, 9 de febrer de 2024 18:28 Per a: Duncan Murdoch <murdoch.duncan at gmail.com> A/c: Iago Gin? V?zquez <iago.gine at sjd.es>; r-help at r-project.org <r-help at r-project.org> Tema: Re: [R] Avoiding Delete

I don't use term, but I've just tested it and this is reproducable. Is it a bug? Not sure. If you hit c after getting the message it will cancel the q() request. On Fri, 9 Feb 2024, 17:21 Duncan Murdoch, <murdoch.duncan at gmail.com> wrote: > That looks to me like a bug, but I don't use Windows any more, so I > won't offer to try to fix it for you. In fact I

Hi, With R-3.1.0 I get: > getParseData(parse(text = "{1}", keep.source = TRUE)) line1 col1 line2 col2 id parent token terminal text 7 1 1 1 3 7 9 expr FALSE 1 1 1 1 1 1 7 '{' TRUE { 2 1 2 1 2 2 3 NUM_CONST TRUE 1 3 1 2 1 2 3 5 expr FALSE 4 1 3 1

About the decisions: Actually, the same way dataedittext modifies the text colour not only of data, but also of row and column names, and dataedituser modifies the colour of all the borders, I think dataeditbg should modify the background of all the window, at least that "inside" those borders. Otherwise, any other option for the background colour on row and column headers would allow

? Fri, 12 Apr 2024 12:15:07 +0000 Iago Gin? V?zquez <iago.gine at sjd.es> ?????: > f <- function(whatever){ > ... > g <- function(whatever2){ > ... > } > ... > } > > If I wanted to debug some thing directly inside f I would do > debug(f). But this does not go inside g code. On the other hand, > debug(g) does not work as g is not a

I would like to map the parsed tokens obtained from utils::getParseData() to the parse tree and elements obtained by base::parse(). It looks like back when this code was in the parser package the parse() function annotated the elements in the tree with their id, which would allow you to perform this mapping. However when the code was included in R this functionality was removed. ?getParseData

Yes, indeed, I am talking about Rterm in Windows. Iago ________________________________ De: Duncan Murdoch <murdoch.duncan at gmail.com> Enviat el: divendres, 9 de febrer de 2024 13:50 Per a: Iago Gin? V?zquez <iago.gine at sjd.es> Tema: Re: [R] Avoiding Delete key function as 'Quit R' in Rterm when there are no characters in cursor line On 09/02/2024 6:25 a.m., Iago Gin?

This seems like something that should be fairly easily doable. Why don't you work out a patch? Some decisions to make: - What colours are we talking about? Would you want the labels to have their colour set independent of the dialog colours? If so, would you also want to configure the dialog colours? - What names should be used for the colours? - Where should all of these definitions

Here's another *incorrect* way to do it -- incorrect because it will not always work, unlike Iris's correct solution. But it does not require PERL type matching. The idea: separate the two vowels in the regex by a character that you know cannot appear (if there is such) and match it optionally, e.g. with '*" repetition specifier. I used "?" for the optional character

Hi Iris, Thank you. Further, very nice solution. Best, Iago On 01/03/2024 12:49, Iris Simmons wrote: > Hi Iago, > > > This is not a bug. It is expected. Patterns may not overlap. However, there > is a way to get the result you want using perl: > > ```R > gsub("([aeiouAEIOU])(?=[aeiouAEIOU])", "\\1_", "aerioue", perl = TRUE) > ``` >

That looks to me like a bug, but I don't use Windows any more, so I won't offer to try to fix it for you. In fact I don't think Rterm has many users at all: most Windows users probably use RStudio or one of the other graphical front ends (Visual Studio, Emacs, Rgui, etc.) So maybe you can track down the issue, or someone else will try. Or maybe you'll just have to avoid

Probably need a generic tree based on "ParseNode" objects that associate the line information with the symbol (for leaf nodes). As Duncan notes, it should be possible to gather that from the table. But it would be nice if there was an "expr" column in the parse data column in addition to "text". It would contain the parsed object. Otherwise, to use the table, one is

Hi all, I've just could test your suggestions on using dataedit... entries now, and indeed they work... partially. See, please, the next screenshot: https://ibb.co/Dkn2pVs dataedituser modifies the red borders dataedittext the yellow text dataeditfg... I do not know, specified to green the output of View(mtcars) does not change from that of the screenshot dataeditbg is the (almost) black

Hi all, I am trying to debug an error of a function g defined and used inside another function f of a package. So I have f <- function(whatever){ ... g <- function(whatever2){ ... } ... } If I wanted to debug some thing directly inside f I would do debug(f). But this does not go inside g code. On the other hand, debug(g) does not work as g is not a defined function in the