> Support for @ignore could be added, but changing @menu to @@menu is > just one of many ways of disabling @menu: there is no reason for Leo > to treat as special case.
In the "About this file" section of leoSettings.leo, there's a headline with "\...@ignore comment" and the body says, "Leo ignores subtrees of @settings trees whose headline starts with @ignore." So I'm confused by the statement, "support for @ignore could be added" when "Leo ignores..." seems to be saying support is already there. I'm obviously not understanding because to me there's a contradiction here. Does @ignore work on subtrees everywhere in @settings EXCEPT for @menu trees? The @ignore worked on the @menu headline, just not child @items. Maybe I'm just not understanding the difference between child items and subtrees that @ignore is supposed to include in its processing? Or is it a case where @ignore functionality was removed long ago from @settings, and thus "support for @ignore could be added [back]" and the "About this file" was just not updated? Can you let me know one or two alternates of the "many ways of disabling @menu"? And my question remains: why didn't @@menu cause the child @items to also be disabled? If there are only certain scenarios where @@ can be used to disable something, (like, an exception is that child nodes of @@menu headlines in @setting trees are not affected) that would be helpful for me to know. When I look at the various @settings, the @@ method seems to be a common way of disabling functionality, so that's why I tried using it. > > 3. What exactly is/are the differences between the import-derived-file > > and import-at-file commands? > > I don't know myself. You would have to look at the code. I think as a newbie it is reasonable for me to want to understand the differences between the multitude of file import/read choices Leo has so I can use the most appropriate one for whatever task I have at hand. If it was explained in the documentation, there would be no need to expect a newbie like myself, who programs but not in Python, to look at the code. I thought the place to ask these kinds of questions about the inner workings of Leo was in this leo-editor Google group. If it is better asked in leo-editor-users, then that's fine, but tell me that's the case. >From this recent thread: http://preview.tinyurl.com/284gnhk I read this: >1. I can't/wont' improve documentation in general. I have to know >what it is you want to know. Why not just ask? I typically answer >question in a timely fashion, and my answers could form the basis of >documentation that targets just your concerns. I believe my question was specific and clear, but if it was not, then I obviously do not know what/how to ask in a way to get an answer. I've seen threads in this forum that end with, "if not, please feel free to ask more questions". Well I =am= asking questions, and "look at the code" =is= an answer -- and a timely one -- but not a =helpful= one. So from my perspective, "why not just ask?" =is NOT working.= If the expectation is that Leo users need to have a background in Python so that the documentation doesn't need to explain such things as the difference between import-derived-file and import-at-file commands, then please let users know this upfront. It will save the helpful people here (including yourself!) a lot of time, and will establish proper and reasonable expectations for newbies if they have questions and come here seeking support, like I'm trying to do now. I hope it goes without saying that responses like, "You would have to look at the code" doesn't give me much hope that, "my answers could form the basis of documentation that targets just your concerns." To me the message I'm getting is that the docs won't be updated to explain the difference between the import functions I'm asking about. I =do= realize that multiple people have contributed to Leo over the years, so perhaps whoever did the original code for these two functions (import-derived-file and import-at-file) will chime in here. >Would it be possible to configure an "expert" menu mode, which shows >all of the options as it does now--and then a "beginner" mode which >shows only those menu items useful to beginners? I like this idea a lot. >Of course, as a Leo user become more proficient, they would probably >like to choose which items are shown in the menus. Yep, choosing what's shown is exactly what I'm attempting to do. I want to do this even though I'm =not= very proficient yet. :D >So the ultimate solution would seem to be configuration options that >allow certain menu items to be visible or non-visible to the individual >user's liking. This sounds like it's being introduced as a new concept, so maybe the @ignore method for @settings =was= removed long ago and has since been forgotten? >- File ->Tangle(archaic) >- File -> Import -> Import to @root(deprecated) I like this idea. It would avoid the problem where newbies like me and others who go to use some feature in Leo, trying to follow the documentation, stop in frustration to ask about it in leo-editor or leo-editor-users, only to be told, "it's hardly used" (which still doesn't answer the question, "why isn't this working?"), or "it's a known fact that it's broken." At least by seeing "(archaic)" and "(deprecated)" we'd have a heads-up that it might no longer be supported or actively tested as Leo development moves forward. (And there's nothing wrong with dropping support or testing, the point is to inform the user.) At this point, I'm still hoping Leo is going to be right for me. When I first read about the cloning (primarily) and @shadow functionality (to a lesser extent, but still valuable), a light bulb went off and I thought, "This is EXACTLY what I need!" If I hadn't thought Leo was going to work for me, I would have given up weeks ago when I first realized the learning curve was so steep. I'm still hoping the hours and hours I'm spending is going to pay off. When chapter 14 was recently revised and feedback was explicitly welcomed, I poured over it with a fairly fine-toothed comb. I spent hours reading it through several times, even though it is extremely unlikely I'll use the capabilities at all. So why did I put in all that time? For two reasons: 1) I thought it would be a way to contribute to Leo's documentation since I've been "hearing" tailoring the docs to newbies is recognized as being important -- I can definitely bring a newbie's eyes to the task, and 2) well, it was just fascinating to read! :D -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
