Here are some recent thoughts about "different colored threads." 1. The discussion about attributes is interesting and valuable. It will be good to continue it. It's already stimulated my thinking. However, it clearly is a solvable implementation issue.
2. Imo, the crucial questions relate to use cases. How will this work? What will it look like? To reprise the refrain, "I love clones, I hate clones": Clones can be great for unit testing: I put them under @test nodes. This makes it possible to run tests on the *latest* code without running tests externally. Very convenient, and super fast. Alas, I am fed up with with searches finding clones *over and over again*. This was almost intolerable when I cloned much of the make_stub_files code under each of the 10 @test nodes in the make_stub_files project. Yes, there are alternatives to searching the whole tree, but I typically don't use what already exists! Just one or two keystrokes can make a huge difference to work flow. Ideally, I'd like a work flow that "just works" without any additional setup. When I'm deep in the mood of programming, I don't want *anything* to be a distraction. I want a work flow that I can *always* use. It's kinda like dwim (do what I mean). Maybe I could call it smwiw (show me what I want). All this fancy switcheroo technology (switching from one set of colored threads to a set of differently colored threads) might just add complexity and confusion. Otoh, it looks perfect for switching between chapters or hoists. Hmm. As a thought experiment, perhaps even a prototype, consider that switching colors of threads is much like switching tabs. Searches only can match what is visible in the selected tab. Changing hoists or chapters switches tabs. Changing what attributes are visible also changes tab. *Note*: I think it's best to think of attributes in this sense as *arbitrary predicates* that return True/False for every node. In this discussion, we don't care much how the predicates are defined. Naturally, though, it makes a big practical difference. This is as far as my thinking goes. We'll see where this switching tabs analogy bears any fruit. As part of thought experiment I'm going to assume that there are an *unlimited supply* of available key bindings. Equivalently, we can assume that Leo will *read our minds* about what we want, especially what panes have focus, what they show and how to switch effortlessly between them. This may be the most general way of thinking about user interfaces. Your comments, please. 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
