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
On Saturday, August 8, 2020 at 3:15:48 PM UTC-4, Edward K. Ream wrote: > > 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 <https://github.com/leo-editor/leo-editor/issues/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 > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/06a2abc7-2ed3-43e2-be2e-9eb42799019bo%40googlegroups.com.
