From @endo64: https://github.com/red/docs/blob/master/en/vid.adoc#3-container-settings has a link that goes nowhere.

Temporarily rename rgba to rgbt until Red Team makes a final decision.

Per discussion in red/redfrom @dockimbel :

"In Redbol, we rely on the notion of transparency (you ask: "how transparent it is?", not "how opaque it is?"), which is more human-friendly than opacity (which is an alpha channel mask), so we should maybe rather call our pixel format RGBT, rather than RGBA."

In View reference docs, some of the face types have tables with descriptions of supported event types and their respective handlers, but some do not:

• base
• text
• progress
• slider
• camera
• window
• screen
• group-box

I'd like the images and text of VID docs to reflect that origin affects not only top left, but also bottom right margin.

Or otherwise
> That should be added to docs, as it is by design. Though origin could do what the name says, and margin could be a new word that provides symmetry.

>> ? call
....
     /show        => Force the display of system's shell window (Windows only).
....

Two problems:

1. "of shell window" wording is misleading
2. it is reflected nowhere that without this flag the window will be forcefully hidden

Because, as seen from https://github.com/red/red/blob/8d712e4ba1b16e1b7a339006d1154aebc9cb7ce4/runtime/call.reds#L324
in the absence of /show it uses the wShowWindow field of STARTUPINFO structure, which is never initialized explicitly and thus defaults to 0 = SW_HIDE. As a consequence, any GUI program called without /show cannot be interacted with (try call {notepad.exe}). (Although due to a bug some Red GUI programs are still visible partly on W7 - only those parts that are emulated using layered windows mechanics, but it's another topic)

amreus @amreus 08:57 found this for me on 12/29/2018

I found myself having to click on a text box each time I entered text because the control lost focus.

The set-focus worked beautifully but neither amreus or myself found it in the documentation.

amreus provided the following example and it worked like a charm!

Red [
needs: 'view
]

view [
f1: field focus
f2: field
f3: field
b: button "Set Focus" [set-focus f3]
]

Since some time the View engine became DPI-aware. Every pair! is expressed in some logical screen units, not pixels. Documentation should clearly state that in a separate paragraph and use word "screen unit" instead of "pixel" everywhere.

https://dockimbel.gitbooks.io/red/content/v/v0.6.0/gui/Draw.html#image

I think this is wrong:

"If the image has positioning information provided,
then the image is painted at 0x0 coordinates."

Must be:

"If the image has positioning information provided,
then the image is painted at the given coordinates."

or

"If the image has no positioning information provided,
then the image is painted at 0x0 coordinates."

From Gitter chat: https://gitter.im/red/bugs?at=5ec5643626d26710bba95dbf

If we think of it as "The value is first coerced to a type compatible with the series, then the part is taken." we get what we have now. Easy to understand. This is similar:

>> append/part {} 'a/b/c 2
== "a/"

Where the path is first formed, then part of that taken. Knowing this behavior, we can add a doc note that shows how to work around it if you want to append full chars to binaries. e.g.

>> append #{} copy/part "^(2190)XYZ" 1
== #{E28690}

It is not necessary to put below example in the end of section 3 (Creation) in error! datatype doc: page: https://doc.red-lang.org/en/datatypes/error.html#_creation

Arg values in the block are reduced.

>> cause-error 'syntax 'missing [foo bar]
*** Script Error: foo has no value
*** Where: reduce
*** Stack: cause-error

It is obvious that foo has no value and the error is not related to usage of cause-error function.

It can be removed or changed to

Arg values in the block are reduced.

>> foo: "foo" bar: "bar"
>> cause-error 'syntax 'missing [foo bar]
*** Syntax Error: missing "foo" at "bar"
*** Where: reduce
*** Stack: cause-error

@meijeru commented on Thu Apr 27 2017

The section on map! type in the Gitbook leaves this out. The allowed key values may be summarized as scalar! all-word! and any-string!.

@dockimbel commented on Fri Jul 28 2017

You should submit tickets about red/docs repository to its own issue tracker.

There are 2 Abstract section in error! datatype doc page, they should be merged: https://doc.red-lang.org/en/datatypes/error.html#_abstract_2

e.g. extend and skip. Need to check all of them.

Too many subsections under "datatypes"

Part 1 of red/red#3789 was never solved

1. Contrary to the docs, qcurv accepts 1 or more points.
2. The docs don't say that it continues what qcurve or other qcurvs might have started (using the latest pair of points from these directives)

Here are some suggestions about the formatting of documentation which came up while I was working on the translation. The goal is to make the documentation look less confusing and more compatible with different translations in terms of formatting.

Document Header

Suggestion: Add an attribute :toc-title: Table of Contents.

Reason: This attribute represents the TOC label. The translator only need to change "Table of Contents" to the translated language without adding a new attribute manually.

Bold and Italic

Suggestion: Always using __text__ and **text** instead of _text_ and *text*.

Reason: Like in Chinese and Japanese, there is no spacing between words, so single _ or * will be treated as normal texts instead of formatting instructions. It is better to avoid translators changing the formatting manually.

Link and Anchor

Suggestion: Always use link:url[text] syntax. Note the link: prefix must be added.

Reason: This can work without spacing around the link. Maybe just I can't figure out how to make << xxx >> work.

Suggestion: Always using link:#a-anchor[text] for links within the document and add an explicit anchor ID [#a-anchor] right above the section title to link.

Reason: The anchor for a section is dependent on the text of that section, which can be messed up after translation. This works across different translations.

Suggestion: Use link:another-document.adoc[text] for links between documents. Note the extension of the link is adoc.

Reason: This makes the link works both on github and gitbook. Gitbook will automatically change .adoc to .html.

Admonition

Suggestion: Always using the syntax described below (NOTE can be other type):

[NOTE, caption=Note]
====
Something to note.
====

Reason: That "Note" of the caption attribute is the label displayed in the left of the admonition block. The translator only need to change into translated language without changing the formatting. The label of inline admonitions (NOTE: ) can't be changed (or maybe I couldn't figure it out).

Word Name

Suggestion: Always surround the word which means Red word with ` (also in section titles, without uppercase).

Reason: Red word (keyword in DSL, or function name) is not that distinguishable from normal English words (in my opinion). If it is used in section titles without surrounded in a code span, it can be hard for translators to decide whether to translate it or not, and also may be confusing for normal readers. I have tried to make it a code span in the section title and it renders good.

Suggestion: Maybe avoid using red-words like normal English words in sentences.

Reason: Like the example below from the description of check in view.adoc, It sounds stupid if I keep left and right as is after translating. Or wrap left and right into a parenthesis and annotate after translating left and right, which also doesn't looks so good.

para: The align field controls if the text is displayed on the left or on the right side.

para: align 字段控制该文本是靠 left 边显示还是靠 right 边显示。

para: align 字段控制该文本是靠左边（left）显示还是靠右边（right）显示。

Type Annotation

Suggestion: Unify the type annotation over all documentation.

Reason: It is good to do so. Currently it can appear in two different kind of contents (see below), function syntax code blocks and some tables. It is not always at the end of a paragraph.

From macro of preprocessor:

#macro <name> func <spec> <body>
#macro <pattern> func <spec> <body>

<name>    : name of the macro function (set-word!).
<pattern> : matching rule for triggering the macro (block!, word!, lit-word!).
<spec>    : specification block for the macro function.
<body>    : body block of the macro function.

From Event! datatype of view:

|`offset`| Offset of mouse cursor relative to the face object when the event occurred (`pair!`). For gestures events, returns the center point coordinates.

Suggestion: Don't use "," to separate multiple types, nor "or" needed.

Reason: Removing these won't cause confusion. The datatype won't lose coloring as the example of #macro above.

Spacing

Suggestion: Always add a separate line between the actual content.

Reason: This can avoid content format corruption in some languages.

@meijeru commented on Tue Apr 18 2017

1. charset is shorthand for make bitset! except it does not cover make bitset! <binary>. This does make sense since charset suggests we deal with code point numbers, but it is useful to point out.
2. charset 5 makes a single-byte empty bitset, charset #"^E" makes #{04}, BUT both charset [5] and charset [#"^E"] make #{04}. In other words, make bitset! <integer> is treated as storage reservation, as with all series! values, although bitset! does not belong to series!. It is questionable which kind of (in)consistency is less confusing for the user. In any case, the chosen solution has to be documented...
3. charset [32 - #"Z"] is allowed, in other words, integers and code points may be freely mixed in the spec block.

@meijeru commented on Wed Apr 19 2017

Point 3 is solved by the fixes to #2587

The title says it all.

There is possibily an error in the second note of the Runtime creation. Maybe good to change to "only if its value is >= 100 and greater than the value of the third field". Also I think it is better to put it in the Block to date section.

See the discussion in gitter.

Right now our documentation is written casually and a bit messy. IMO it's worth to set up a ROADMAP how we document Red. So I leave this issue as an entry.

How about, firstly, follow the structure like (http://www.rebol.com/docs/core23/rebolcore.html) and build an overviews of Red Core.

Also https://doc.red-lang.org/en/view.html#_event_names should contain on-detect mentioned in other parts

Right now there's no documentation present for the #system directive introduced with this commit: red/red@c9cfa3f

It's only mentioned in an example for the #call directive in the red/system spec: https://static.red-lang.org/red-system-specs.html#section-16.8

Having it added to the directives of the red docs would help in making people aware that it's possible to call red/system code from red using this directive. Otherwise it's kind of hidden and might only be found by accident or a long search.

Also not sure if i'm the right person to make a pull request for that as, I'm still learning and getting familiar with red and its environment. But I guess the commit message provides enough information (at least for me) about what it is and how to use it. So maybe only one or two examples are missing for a proper doc entry.

Thank you very much!

Version 0.6.0 does not have a version selector, but 0.6.1 does, and it allows selection of 0.6.0, 0.6.1 and 0.6.2. However, 0.6.2 is not (yet) available. Moreover, the default value shown in the version selector is 0.6.2, so the impression is created that this version is selectable. I propose that in each version, the version selector shows THAT version as default. This is a better way of finding out which version one is in, than to look at the URL in the address box.

Every time I append to the area that it scrolls the who way back up to the top even if I had i scrolled all the way down to the bottom. For things like logging and chat session and chat bots like I'm doing the information being added to the bottom is usually what the user is most interested in.

When I append text to an area, at some point the text is hidden from the user because it is scrolled off the screen. Is there a Red word I can use to tell the scroll bar on the area to scroll down so the user knows the new text has been appended. Otherwise I would have to inform the user to manually scroll to the bottom if he does not see a response in the area.

See red/red#3337 (comment)
It should be noted in the reactivity docs that deep-reactor! tracks changes not only in series but also in composite scalars (pairs, tuples, date, time). In contrast to reactor! that does not.

See chat at https://gitter.im/red/help?at=5d978a58fcf7602cc52fbcd6

in this code https://gist.github.com/tinulac-leinad/00a0e9a85e13782858eab2a71bc2ac59
there is a problem with I: here :

tune: object [
  tA: tB: tC: tD: tE: tF: tG: tH: I: tK: tL: tM: tN: tO: tP: tQ: tR: tS: tT: tX: tZ: ""
                                             

in the REPL the code work fine....
when I compile with -c it's ok
when I compile with -r -> error

Compiling /home/daniel/Apps/red/red_projets/dn-abc-tools/test.red ...
...compilation time : 1875 ms

Target: Linux 

Compiling to native code...
*** Compilation Error: argument type mismatch on calling: red/natives/repeat-init* 
*** expected: [struct! [
        header [integer!] 
        data1 [integer!] 
        data2 [integer!] 
        data3 [integer!]
    ]], found: [struct! [
        header [integer!] 
        ctx [pointer! [integer!]] 
        symbol [integer!] 
        index [integer!]
    ]] 
*** in file: %/home/daniel/Apps/red/red_projets/dn-abc-tools/test.red 
*** in function: exec/f_ctx||394~value-path?
*** at line: 1 
*** near: [
    r3: 0 
    stack/reset integer/push 0 
    stack/mark-loop ~repeat 
    while
]

and just this simple code cause the same error :

Red[]
I: none

Section 6.3.5 shows vprint as an example of variadic typed function. This function uses form-type conversion which was removed from Red/System runtime quite a while ago, so the code needs to be updated.

https://doc.red-lang.org/en/typesets.html

>> ? internal!
INTERNAL! is a typeset! value: make typeset! [unset!]

@meijeru commented on Tue Apr 18 2017

1. charset is shorthand for make bitset! except it does not cover make bitset! <binary>. This does make sense since charset suggests we deal with code point numbers, but it is useful to point out.
2. charset 5 makes a single-byte empty bitset, charset #"^E" makes #{04}, BUT both charset [5] and charset [#"^E"] make #{04}. In other words, make bitset! <integer> is treated as storage reservation, as with all series! values, although bitset! does not belong to series!. It is questionable which kind of (in)consistency is less confusing for the user. In any case, the chosen solution has to be documented...
3. charset [32 - #"Z"] is allowed, in other words, integers and code points may be freely mixed in the spec block.

@meijeru commented on Wed Apr 19 2017

Point 3 is solved by the fixes to #2587

Section 6.1 Keywords breaks off on draw keyword description, and after that wrap becomes a top level header, wrapping all subsequent keyword definitions.

On closer examination, this happens because draw section contains ragged code fences caused by this.

@JenniferLee520 commented on Sat Jun 10 2017

According to the "Draw" documentation

6. Source position

Set-words can be used in the Draw code in-between commands to record the current position in Draw block and be able to easily access it later.
Note:
If the Draw block length preceding a set-word is changed, the recorded position will not be updated.

But somehow, the position can be updated.

view [ 
    origin 0x0
    base 800x400 draw [
        fill-pen green
        pos: box 400x0 450x100
    ] on-down [
        probe pos
        insert face/draw [pen red]
    ]
]

Run the code. "pen red" will be inserted into the draw block every time you click on the face. But as you will see: it's updated. In the following result, I clicked 4 times.

>> do %pos-test.red
[box 400x0 450x100]
[box 400x0 450x100]
[box 400x0 450x100]
[box 400x0 450x100]

@dockimbel commented on Sat Jul 29 2017

It's a wording issue in the note, the "recorded position" refers to the initial position.

I'm changing it to:

NOTE: If the Draw block length preceeding a set-word is changed, the original position will be changed accordingly, so the set-word will not point to the same reference anymore.

Documentation (https://doc.red-lang.org/en/draw.html#_arc_2) says:

<angle> : angle between the starting and ending points of the arc in degrees (integer! float!).

Should be: <angle> : rotation angle of the underlying ellipse in degrees (integer! float!).

Explanation: In following code angle between start and end points is 0 but rotation angle of ellipse is 45:

view [box 100x100 draw [shape [move 30x50 arc 70x50 30 20 45 large]]]

e.g. pick and take

I would fix/improve problems below,

view.html

• "オプションファセット" should be "Options ファセット".
  gitter talk about it: 2018年2月2日 15:28
• "追加の関数" is too literally translated. "その他の関数" might be better.
• The sentence below should be deleted(original English sentence left).

A vertical scroll-bar can appear if all lines of text cannot be visible in the area (might be controlled by a flags option in the future).

red/red#4480

To string! none behaves differently than Rebol 2

to-string none

provokes an error in RED (compliant with the conversion matrix and Rebol 3) but returns "none" in Rebol 2.

Maybe a difference to be added to :
https://github.com/red/red/wiki/%5BDOC%5D-Differences-between-Red-and-Rebol#make-with-none

in the same section as Make with none.

After last update, datatype page inaccessible for English and Cesky.

See: https://gitter.im/red/docs?at=5cfe6e31e41fe15e7544d0ae

My suggestions:

The any-list part could remove some prose.

An any-list! value must contain two numbers. The result will be the first number multiplied with the value of 10 to the power of the truncated second number. first-number * (power 10 second-number)

Could be

An any-list! value must contain two numbers. The result will be first-number * (10 ** second-number)

The binary example is backwards from the text. It described to float!. And your new text seems better. Beyond that, an example of what happens with truncated data (less than 8 bytes) should either be included, or we should say that's not supported.

1

s/c: declare struct! [d [integer!] e [float!]] it should be

2

And just below:

12 + 4 (integer) + 8 (float) = 24 in my book, not 20 bytes

3

The returned value of DECLARE STRUCT! is the memory address of the newly created struct! value.

It is never stated that structure is static (only allocated once), so is dangerous to use inside functions (see red/red@069f335 commit)

I am working on Chinese translation of the documents. I find if only changing the text(no line added), the contents in github will be corrupted(like that original Japanese translation). After I add lines seperating elements(eg, header, code blocks), it will renders correctly. It seems seperated lines are need for some languages.

I can add lines needed while translating the documents. If permitted(needed), I will be happy to help.

In view.adoc:

|`type`| `'check`
|`text`| Label text.
|`para`|	The `align` field controls if the text is displayed on the `left` or on the `right` side.
`data`, `true`: checked; `false`: unchecked (default).

I assume that the last line needs a | in front of it , and another | in place of the ,

https://doc.red-lang.org/en/view.html

There's a mention of on-create (with single face argument). But not a word about on-created and that it also accepts a single argument only.

@meijeru commented on Sun May 14 2017

In the example code of rebBlockVB(), there is an extra hi in the block of the comment.

redProbe redBlockVB(42, "hello")   ' Creates the [42 "hello" hi] block

unit indicates the size of the vector element type size: 1, 2, 4 or 8 bytes.

"size" repeats in the Vector! section.

Looks like just the I/O section.

☝️ January 30, 2020 2:16 PM