World: r3wp
[RAMBO] The REBOL bug and enhancement database
older newer | first last |
Anton 19-Jun-2007 [3071x3] | Advantages: - middle and right aligned text is now usable and works as one would expect, with the caret appearing in the correct position. - you can render the caret how you like - you can render the highlighting how you like (I didn't show the above options clearly in the demos yet, you must still get your programming fingers dirty) Disadvantages: - lots of code to achieve the above - probably slow performance with large areas, because images are being created on every redraw |
I should have announced that in the View group, sorry. | |
(oh well, I guess it's one big bug workaround) | |
PeterD 20-Jun-2007 [3074] | Thanks Anton |
Anton 20-Jun-2007 [3075x2] | Cool, let me know any problems. |
To maybe fit in better with other styles, the caret colour can be changed. eg: area with [append init [named-colours: make named-colours [caret: black]]] | |
Graham 28-Jun-2007 [3077] | rambo'd https posting bug. |
btiffin 29-Jun-2007 [3078] | Can I get someone to try this before I report it. foreach [e s] to block! {thing 'word} [compose [e (get s)]] segfaults 1.3.2.4.2 and 2.7.5.4.2 |
Graham 29-Jun-2007 [3079] | linux version |
btiffin 29-Jun-2007 [3080] | yep |
Graham 29-Jun-2007 [3081] | crashes windows as well |
Frank 29-Jun-2007 [3082] | +1 1.3.2.4.2 and 2.7.5.4.2 Linux |
Graham 29-Jun-2007 [3083] | is it recursive? |
btiffin 29-Jun-2007 [3084x2] | I'll check RAMBO add if not in there then...thanks Graham...I just reduced it to this so far...more experimenting to come. |
How about this on your end...just trying to reduce the code for the RAMBO report. foreach a to block! {'word} [print get a] - this segfaults on Linux. too. | |
Frank 29-Jun-2007 [3086] | Got the same result... 1.3.2.4.2 and 2.7.5.4.2 |
btiffin 29-Jun-2007 [3087] | get first to block! {'thing} returns an error message ** Script Error: thing word has no context b: first to block! {'thing} == 'thing get b segfaults. |
Tomc 29-Jun-2007 [3088] | windows REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3 goes boom |
btiffin 29-Jun-2007 [3089] | reported. |
Volker 29-Jun-2007 [3090] | to block! does not bind. word is not included in system/words. sometimes that results in an error-mesage and sometimes in a crash. |
Anton 29-Jun-2007 [3091] | Good one. |
Steeve 30-Jun-2007 [3092] | yeah , it's the normal behaviour for to block! , use load instead for binding |
Graham 30-Jun-2007 [3093] | what happened to my https rambo report ?? :( |
Gabriele 30-Jun-2007 [3094] | i haven't seen it. worst case it was deleted with the spam (i check them carefully, but i may have missed it) |
Graham 30-Jun-2007 [3095] | yeah ... I think you nuked it :( |
Gabriele 1-Jul-2007 [3096] | did you re-enter it? |
Graham 1-Jul-2007 [3097] | No .. did you want me to ?? |
Gabriele 1-Jul-2007 [3098] | if it has been deleted, there's no way to recover it. |
Dockimbel 2-Jul-2007 [3099] | 2.6.2 and 2.7.5, Windows and Linux (probably others too) : Encmd crashes if 'title keyword is used in 'encap header. It works correctly with enpro and enface. |
Sunanda 3-Jul-2007 [3100] | Is rhis a bug, or just undocumented behavior? trim " a ^/ ^/ a " == "a^/^/a" The help says "Removes whitespace from a string. Default removes from head and tail." But in this case it seems to treat the string as a set of strings (separated by newline) and trims them all. Compare with the expected behavior here: trim " a b a " == "a b a" |
Rebolek 3-Jul-2007 [3101] | TRIM behaviour is strange. Sometimes it removes too much as in your case, sometimes it removes too little as in (trim "^/a^/" == "a^/") . I would say it's a bug. |
Sunanda 3-Jul-2007 [3102] | I'm beginning to think so too, especially as (from my reading of the function), these two should be equivalent trim/head/trail " a ^/ ^/ a " trim" a ^/ ^/ a " |
Izkata 4-Jul-2007 [3103] | Hence why I always use trim/head/tail... I didn't think it was a bug, though, since your first example - trim " a ^/ ^/ a " - could be a shortcut for data files.. Trimming each line. |
Anton 6-Jul-2007 [3104] | Sunanda, I think, from memory of old conversation, that the default TRIM behaviour is particular and just insufficiently documented. It's annoying, chuck it in RAMBO to specify exact behaviour in doc string. |
Pekr 12-Jul-2007 [3105] | On windows platforms, you'll get the infamous DOS window flashing when executing an external CGI ! It's just a matter of 1 flag to correctly set in 'call C source code, if you're really annoyed by that, ask RT to fix it asap (for 2.7.6 that would be good)! ;-) I may reimplement completely call command in REBOL, but it would be a big waste of time and energy...it should be a 10 minutes fix for RT. Addind a time limit to 'call would be a good thing too, it would also avoid me the reimplementation of 'call to add such feature.... - DocKimbel Anx chance of getting above fixed? Should we rambo it? |
Henrik 12-Jul-2007 [3106] | wouldn't hurt :-) |
Dockimbel 12-Jul-2007 [3107] | I think that it's already in RAMBO |
Henrik 12-Jul-2007 [3108] | then it's probably been forgotten in Gabriele's priority list for 2.7.6. |
Dockimbel 12-Jul-2007 [3109] | RAMBO lacks a free commenting support... |
Sunanda 12-Jul-2007 [3110] | Re my trim question of a week or so ago.... Thanks for the responses. From RAMBO it seems this is deliberate (if unexpected) behavior: http://www.rebol.net/cgi-bin/rambo.r?id=3681 This is intentional and not a bug. TRIM was designed that way to work well for trimming LINES of text. [my emphasis of lineS, plural] |
Henrik 16-Jul-2007 [3111x2] | DocKimbel, #4288 looks to me like it inserts a molded object into the path. |
or perhaps form | |
Dockimbel 16-Jul-2007 [3113] | Yes, it returns the object source and the point is is this useful to anyone ? I was hoping the behaviour of :b in a path! could be changed to something more useful, like acting as a pass-thru to /c, so that, in the ticket example, a/:b/c would results in %path/target. |
Henrik 16-Jul-2007 [3114x2] | slipping objects into a path... |
>> a: %path == %path >> b: context [c: %target] >> a/:b/c == %path/c: %target%0A/c >> a/(:b/c) == %path/target | |
Dockimbel 16-Jul-2007 [3116x2] | Great! I've forgot paren! evaluation in paths. |
btw, a/(:b/c) is quite heavy => 3 series instead of 1. | |
Gabriele 17-Jul-2007 [3118] | yes, but semantically a/:b/c is a/(b)/c not a/(b/c) which is what you want. |
btiffin 20-Sep-2007 [3119] | Do we still bother reporting to RAMBO? Is there any expecations for a production 2.7.6? I'd vote; please please please. |
NormanDep 5-Apr-2008 [3120] | [ 4322 ] can be closed |
older newer | first last |