I'm kind of dipping into the documentation which is probably not the best way to do this. However, it is how I tend to read documentation, I'm afraid. In the section on the linguistics library, I'm getting a bit confused. At the start of 4.1, it says that children's edges will meet under the (their parent's?) node. But the trees shown here don't seem to do that.

If the libraries are intended to illustrate the use of forest and maybe encourage the development of similar libraries, I think some concession needs to be made to non-linguists by briefly explaining what a c-command is or does. I know there is something in a footnote but (1) it is in a footnote and (2) it relies on the concept of a generative syntax. I can more-or-less guess what that means by analogy with the idea of a generative grammar, but that is not an everyday term.

@cfr I think the "Edges of the children will “meet” under the node:" at the beginning of §4.1 is a description of sn edges. Not a characterization of the what the linguistics library does by default. Further down: "In linguistics, most people want" (emphasis mine). So sn edges is defined by linguistics but not set as a default. Example 81 on p. 62 does exemplify sn edges.

But it's true that this could probably be made clearer.

Tree (c) is referred to on page 62 as 'above' but is below on page 63.

@AdamLiter Then what good does defining a default preamble containing sn edges do? That seems to be the first thing this section says. Also examples earlier in the manual also suggests sn edges is default if linguistics is loaded. Anyway, I tested it and loading the library definitely sets sn edges as default for me ;).

@cfr Ah, okay. I haven't tested it yet. :p So then yes, that should probably be changed.

@AdamLiter ^^ Apologies for the loss of formatting.

@cfr Fair enough. :)

Here's an example of why c-command seems to be a necessary grammatical relation to explain stuff. Linear precedence is incapable of explaining when reflexives are licensed. So (1) is an acceptable sentence because Mary c-commands herself. However, (2) is unacceptable because Mary does not c-command herself (even though Mary precedes herself). In (2), Mary only c-commands father.

I'm not sure what you had in mind for further explaining c-command. That's an actual example, but that may or may not be more confusing for folks?

It might be good to just leave it at something like "c-command is a structural relation that appears to be necessary for explaining a variety of linguistic phenomenon".

?

I'm not sure. It's hard for me to say, being a linguist. :p

@AdamLiter No. I think the documentation should say something like 'Linguistics trees need to illustrate a special relationship, c-commands (or c-commanded or whatever) between a node and its siblings and siblings' sub-trees.' That way, it is easy for somebody to figure out if this is similar or not to some concept which they need their trees to illustrate. The manual doesn't need to explain the linguistic concept - just what it means for the tree.

@AdamLiter Quicker, too!

Indeed. :)

That is, it isn't clear that the macros on 20 \useforestlibrary{} and \forestlibraryloaddefaults{} go together, and the example on 21 doesn't make this clear either. The docs need to say that the package option loads the library and enables the defaults, whereas \useforestlibrary{} loads the library without enabling the defaults but makes \forestlibraryloaddefaults{}available for use in the document.

It would be nice if \useforestlibrary{linguistics,edges} worked as it does with TikZ libraries ;). If not, it might be worth explicitly saying that this is not allowed as it seemed the 'natural' syntax for me, being used to both \usepackage{A,B} and \usetikzlibrary{A,B}. Also, the error message is not helpful in this case as it complains that it cannot find edges.sty.

@SašoŽivanović Er... I hope you really wanted this kind of feedback, by the way. The new stuff looks great and I really mean this to be helpful ;).

This is precisely the kind of feedback I like. Keep on banging! ;-)

I'll get back to you guys soon!

@AdamLiter Yeah. Natural language lacks parentheses, that's the problem. Hence, you end up with all those lovely ambiguities.

I guess that 'The person' is effectively a name in (ii)... At least, logically....

@cfr Good question about what definite descriptions are ... :p But I'm not sure that natural language really 'lacks parentheses'. (i) and (ii) aren't ambiguous, and speakers know this. The things in natural language that are ambiguous have very tightly constrained ambiguity. Usually there are two possible structural analyses that give rise to the ambiguity. So the meaning is constrained by the underlying structure of a sentence.

(But I don't mean to turn Sašo's chat room about forest into a linguistics fest. :p ... )

@AdamLiter I only meant that lack of parentheses is the source of ambiguities. I agree that your examples are not ambiguous. But, anyway, I was not entirely serious ;).