#1625: clones now retain the proper language

[Edward K. Ream]

Hard to believe I never saw this before.

Previously, creating a clone and moving it out from under an @<file> node caused the node to be colored using the @string target-language setting. To compensate, one is tempted to insert an @language directive into the node, or try other workarounds.

Instead, #1625 expands the search, looking for ancestor @<file> nodes for the other clones. This should just work. If the original node was colored correctly, all clones of that node should now also be colored correctly.

This is a big deal. No more having to add @language directives to cloned nodes. In turn, this makes it easier to use clones to study code.

The new code is now live in the devel branch.

Edward

[Félix]

I'm guessing this indirectly fixes similar behavior that would have been felt by software that uses leo through leoBridge? (querying for the language of a cloned+moved node that falls under the criteria you described) ? 

--

Félix

[Edward K. Ream]

On Sat, Aug 8, 2020 at 3:43 PM Félix <felix...@gmail.com> wrote:

I'm guessing this indirectly fixes similar behavior that would have been felt by software that uses leo through leoBridge? (querying for the language of a cloned+moved node that falls under the criteria you described) ? 

Yes, I think that is correct.

Edward