> Let's let newbies speak for themselves. >
I think it's time to speak! Regarding the Leo settings "world": for a Leo newbie like me, settings in Leo are a complicated issue for sure. So it's something I try to avoid touching as much as I can... but just because the UX is really poor. Some of the problems I find: 1) It's difficult to know what settings do I have "available" to tweak. As an example, I have just opened my myLeoSettings.leo file to take a look (after more than a year of not doing so) and I've found there a node with just this: @bool minibuffer_find_mode = False But the node body is empty, so I don't know what that setting is about at all. So I've tried the "obvious" thing (though probably that's not what we can expect a newbie to do... so I'm probably moving away from the newbie "hat" here...): I've opened the leoSettings.leo file and did a search for "minibuffer_find_mode" to see what's this setting all about. Result: I've found nothing. Then I've done something a newbie would (more) probably do: a search in leodeditor.com: https://leoeditor.com/search.html?q=minibuffer_find_mode&check_keywords=yes&area=default Result: no results. So I've "guessed" that I probably got that setting from someone else making a comment in this forum. And I've done the search: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!searchin/leo-editor/minibuffer_find_mode$20%7Csort:date With success! There are several posts from Edward and others which include the setting, the most relevant one being this one from Edward <https://groups.google.com/d/msg/leo-editor/tA5Q2YrEu-w/gMMQF6YWxkEJ> stating that: P.S. I recommend minibuffer-find mode for experts. Enable with @bool > minibuffer_find_mode = True. After a lot mooore digging into the issue, I've finally found within leoSettings.leo a node with header "Find/replace options" and as a child I've found a node with, guess what...: @bool minibuffer-find-mode = False So well: this story had a nice ending... but I would not call this a good UX for newbies (or anyone). And all the above is just for one only setting! 2) It's difficult to know what settings are really "in effect" at any moment. Yes, there's the "show-settings" command, I know that. But it shows you a long list of settings in a separate (text) pane, which for the example above happens to show that setting with yet another different "name": [M] @bool minibufferfindmode = False So although "in theory" the command should be "all you need to know"... I wouldn't qualify that as a nice UX. But I'm the same newbie when using VSCode and there I have none of the above problems of settings discoverability and knowing which settings are in effect at any moment. The UX there is really great! Even if I directly edit the settings.json file instead of using it's settings GUI editor. I always know what I'm doing. And I can say that I've had the same good UX, or even better, with Pycharm, for example. I don't pretend that we now radically change the way settings are "entered" in Leo (leoSettings, myLeoSettings and so on), but it's revealing to notice that the "show-settings" command is showing a "flattened" view of the settings! Doesn't that sound as a hint to you? For me it's a clear indication (despite being a newbie, I'm a programmer) that what Leo uses internally to access those settings is a flattened list of settings *and* that there's probably a dictionary (in the Python sense) or a map that Leo is using in memory to access the settings. Isn't that the in effect "the cache" that Vitalije is talking about? I think so. And that takes me to my second contribution today... regarding how Leo loads settings during startup time. When we discussed this same issue years ago (I have no time now to search in the forum) Vitalije and Terry did already commented some possible ways for improving it and I myself did also suggested another simple possible path to move forward, which at that time was simply ignored. My contribution was something in this line of thinking: "You don't need during startup all the Leo machinery just to load the settings files". And I do have stored in my Leo notes this quote from Terry about the issue: I think there's great potential for simplifying init. code and settings editing by using something simpler than full blown Leo outlines for the key/value store needed for settings. Sqlite is certainly an option - if you're just using it for settings, it may not be necessary to include those files in VCS. So I think that this all shows that there's really room for improvement in how Leo currently handles settings, both from the end-user point of view (UX) and from the "Leo internals" point of view (code). Edward: what else do you need to see the evidence...? Why are you having a so strong reaction to Vitalije's proposal? --------------------------------------------- I think we are done discussing this topic. > Edward, I'm not a native english speaker, but I have to say that a sentence like the one above gives a very bad impression: it's not encouraging participation from the community, but the opposite. And here it comes my second suggestion: I agree we probably don't need a Steering Council for Leo, but I think it would really great for our community if we moved our discussions to a real modern forum like Discourse <https://www.discourse.org/>, as Python and many other communities have already done. This post from the Python forum <https://discuss.python.org/t/is-this-really-better-than-a-mailing-list/57> gives some explanations of the particular benefits/features of Discourse, though it is in response to someone comparing it to a simple mailing list. But some of the greatest features that they don't mention there which I think would really benefit our community are: - *Easy refactoring of forum threads!* Moderators can easily move off-topic posts to a new thread, so the current topic can be kept focused, without losing any contributions. This is for me a feature that sets Discourse apart from any other forum software (and I've looked at many). - *Easy creation of polls!* Though there are probably many more that I even yet don't know. I stongly feel that we have to move forward as a Team and Discourse could be a game changer in many ways. Your comments are wellcome! -- 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/d5d39c3c-b25c-488f-b62c-6234fc90a9c3%40googlegroups.com.
