Re: rst preview line wrapping
Oops. Just found it's stretched because the window occupies two monitors. After I moved it to one monitor, it's okay now. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
rst preview line wrapping
Hi, I am trying to find a way to have line wrapping when previewing rst files. The text is displayed okay in the body panel but it goes all the way to the hidden far right. Is there a way to tell Leo to wrap the text when it goes outside the display boundary. Body Panel | Preview Panel | Outside display zone This line is a bit longer This line is a bit longer than expected so it is wrapped. than expected so it is wrapped. Thanks. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Leo 5.7.3 released
> > Thanks, Matt, for all your work. > You're welcome :) It's good to be able to give back. For the next long while life is giving me opportunity to appreciate it's full breadth and reach, from birth to death. Best to ping me directly at map...@gmail.com when new releases happen as my attention to the mailing list and Github is in subdued mode. Best, Matt -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
A milestone: the fast-read branch is ready for widespread testing
The fast-read branch is now ready for general testing. The code appears stable. Please report any problems immediately. *Highlights of the fast-read branch* 1. It includes the no-sax branch. That is, the fast-read branch contains new code for reading both external files and .leo files. 2. Caching has been radically simplified: A. No file caching whatever is done. The cache contains only non-essential items, such as marked and expanded bits. B. ~/.leo/db now contains only two sub-folders: *g_app_db* and *global_data*. g_app_db corresponds to the old "global" folder. It contains the cached result of g.app.db. The global_data folder contains all expanded and marked bits, plus some other data. The keys are simply the full path names of each .leo file. This should be safe enough. 3. Leo writes only a vestigial element in .leo files. This should be enough to allow old (Leo 4.5 and above) versions of Leo to read .leo files. 4. Leo no longer writes expanded and marked bits to the root node of @file trees. 5. As a result of 2, 3 and 4, all Leo files are essentially "fixed". Their contents will change much less often than before. As a result, the c.fixed switch has been eliminated, along with the @bool fixedwindow setting. 6. The g.enableDB switch has been eliminated, along with the --no-cache command-line argument. *Summary* Folks, this is a huge collapse in complexity for Leo's code, and for Leo's users. I plan to merge fast-read into devel in about a week. Leo now works as if --no-cache were permanently in effect. In other words, Leo *always* recreates outlines directly from external files. This eliminates an important source of confusion. Leo's new read code is almost exactly as fast as reading cached data, a remarkable accomplishment. Leo no longer pollutes .leo files with non-essential data, resulting in fewer diffs of .leo files. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: suggestion: disambiguate print-xxxx command names
On Sunday, June 24, 2018 at 8:13:50 PM UTC+1, Kent Tenney wrote: > > You've got a good memory Edward! > > I think there are also some print-xxx commands which involve > the printer, so the power of tab completion is compromised, > > Yes, I should have said that as well as the 'cognitive load' of the multiple use of 'print-', it is unhelpful when using tab completion. (I am happy to acknowledge that this is a small issue in the scheme of things...) Jon N > > On Sun, Jun 24, 2018 at 12:36 PM, Rob > > wrote: > >> I think most non-programmers would assume that `print.xxx` implies >> sending something to a `printer` object (actual paper printer or PDF >> creator), ie. something configured by the OS as a `printer`. For them (I >> consider myself mostly a non-programmer), what these commands actually mean >> is `output to the screen`. So, I agree that clarifying the difference >> somehow in the naming is a good idea. >> >> Rob... >> >> On Saturday, June 23, 2018 at 4:25:12 PM UTC-4, Edward K. Ream wrote: >>> >>> Kent has made almost the identical suggestion. I'm not sure why I wasn't more sympathetic to it before, but on second/third thought it seems reasonable. >>> >>> Changing names could, in theory, break scripts that use, say, >>> c.k.simulateCommand, but that does not seem sufficient reason to reject an >>> otherwise reasonable suggestion. >>> >>> Any other comments? >>> >>> 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 leo-editor+...@googlegroups.com . >> To post to this group, send email to leo-e...@googlegroups.com >> . >> Visit this group at https://groups.google.com/group/leo-editor. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: suggestion: disambiguate print-xxxx command names
You've got a good memory Edward! I think there are also some print-xxx commands which involve the printer, so the power of tab completion is compromised, On Sun, Jun 24, 2018 at 12:36 PM, Rob wrote: > I think most non-programmers would assume that `print.xxx` implies sending > something to a `printer` object (actual paper printer or PDF creator), ie. > something configured by the OS as a `printer`. For them (I consider myself > mostly a non-programmer), what these commands actually mean is `output to > the screen`. So, I agree that clarifying the difference somehow in the > naming is a good idea. > > Rob... > > On Saturday, June 23, 2018 at 4:25:12 PM UTC-4, Edward K. Ream wrote: >> >> Kent has made almost the identical suggestion. I'm not sure why I wasn't >>> more sympathetic to it before, but on second/third thought it seems >>> reasonable. >>> >> >> Changing names could, in theory, break scripts that use, say, >> c.k.simulateCommand, but that does not seem sufficient reason to reject an >> otherwise reasonable suggestion. >> >> Any other comments? >> >> 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 leo-editor+unsubscr...@googlegroups.com. > To post to this group, send email to leo-editor@googlegroups.com. > Visit this group at https://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. > -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: suggestion: disambiguate print-xxxx command names
I think most non-programmers would assume that `print.xxx` implies sending something to a `printer` object (actual paper printer or PDF creator), ie. something configured by the OS as a `printer`. For them (I consider myself mostly a non-programmer), what these commands actually mean is `output to the screen`. So, I agree that clarifying the difference somehow in the naming is a good idea. Rob... On Saturday, June 23, 2018 at 4:25:12 PM UTC-4, Edward K. Ream wrote: > > Kent has made almost the identical suggestion. I'm not sure why I wasn't >> more sympathetic to it before, but on second/third thought it seems >> reasonable. >> > > Changing names could, in theory, break scripts that use, say, > c.k.simulateCommand, but that does not seem sufficient reason to reject an > otherwise reasonable suggestion. > > Any other comments? > > 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Proposal: using only file contents when computing hashes
> > > Does anyone see anything wrong with my reasoning? > > Edward > I believe that you are right about this. Only the content matters. However, I was thinking about avoiding hashing completely. I haven't had a time to test that hypothesis but I believe that it would greatly improve speed of restoring cached files. I got this idea by watching how fast runs `git diff` or `git status` command which detect changed files immediately. If the reason they work so fast is that they are written in C, then it would be possible perhaps to execute them using subprocess and apply the reported diffs to the outline restored from cache. That was my idea before making new data model prototype. My guess is that both git and fossil have cached versions of source files and they just compare cached content with the content of the file, they use hashes for other purposes and not for fast comparison. (But this is just a guess, I didn't looked at it in more detail). If both git and fossil work faster because not hashing file content, then perhaps Leo can speed up by caching file content and not only hash. To repeat again, I am sure that neither filename nor name of git branch should matter when restoring outline from cache. Only the content is significant. We can not guarantee that the restored outline would have exactly the same shape as the one that generated file content, because some information can be lost. For example a section node can be in any position inside the sub-tree, but when writing external file it gets the same location. So, different outlines can result in the same external file. But that doesn't seem to be very important. What is important (and that should be guaranteed) is that the outline recreated from cache must produce the same content as the cached content value. Vitalije -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ebba40fdb adds explicit keypad bindings to leoSettings.leo
On Sat, Jun 23, 2018 at 7:10 PM, jkn wrote: Was this intended to include bindings for Keypad+Delete? That doesn't > seem to be present. > Yes. Fixed at 84347a954 in devel. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
