This does fix the problem and does not appear to break anything else. The
behavior is that for a brief moment during the save the icons disappear but
then come right back.
On Monday, August 31, 2015 at 11:53:12 AM UTC-4, Terry Brown wrote:
>
> On Mon, 31 Aug 2015 08:37:25 -0700 (PDT)
> john lunzer <lun...@gmail.com <javascript:>> wrote:
>
> > When I save a Leo outline all of my icons disappear? The next
> > headline update will restore them. Anyone seeing similar behavior?
>
> No, although I can see how that could happen. The visual-declutter
> code clears all the icons it inserted based on rules before the save,
> so that you're not left with a file riddled with "virtual" icons mixed
> with icons you may have added manually yourself and want to keep. I.e.
> if you disable the declutter code, all it's icons should disappear. You
> would think it would need to put them back after the save, but I'm not
> seeing them disappear.
>
> Hmm, so based on the code I would expect the problem you report,
> because of
> leo-editor/leo/core/LeoPy.leo#Code-->Qt gui-->@file
> ../plugins/qt_tree.py-->qtree.Drawing-->qtree.full_redraw &
> helpers-->qtree.clear_visual_icons
>
> But I don't see the problem. The solution would be to add
> self.declutter_update = True
> to the above clear_visual_icons() - can you try that and see if the
> problem goes away?
>
> Cheers -Terry
>
> > On Monday, August 17, 2015 at 3:06:38 PM UTC-4, Terry Brown wrote:
> > >
> > > On Mon, 17 Aug 2015 05:09:55 -0700 (PDT)
> > > john lunzer <lun...@gmail.com <javascript:>> wrote:
> > >
> > > > I've discovered a visual glitch when using the rules for the task
> > > > icons. After the icon has been added by the declutter feature if
> > > > I then attempt to edit the headline again by making it shorter
> > > > (backspace or delete) the original headline seems to get "burned
> > > > in"
> > >
> > > Thought that was going to be a tough one but seemed simple after
> > > all, very lightly tested but seems to be fixed (and pushed).
> > >
> > > Cheers -Terry
> > >
> > > > behind the editable headline box so that the end of the original
> > > > headline still shows. Interestingly if I make a change and then
> > > > press Ctrl + z (undo) then everything seems fine and the original
> > > > headline is no longer "burned in" in the background.
> > > >
> > > > On Wednesday, August 12, 2015 at 11:56:07 AM UTC-4, john lunzer
> > > > wrote:
> > > > >
> > > > > Also, kudos for collapsing leoSettings.leo again before
> > > > > pushing, so that
> > > > >> it looks right when opened.
> > > > >>
> > > > >
> > > > > If that happened it was purely by accident :) Though I will
> > > > > certainly remember to do so in the future.
> > > > >
> > > > > On Wednesday, August 12, 2015 at 11:14:07 AM UTC-4, Terry Brown
> > > > > wrote:
> > > > >>
> > > > >> On Wed, 12 Aug 2015 04:57:16 -0700 (PDT)
> > > > >> john lunzer <lun...@gmail.com> wrote:
> > > > >>
> > > > >> > Just pushed @path/active-path icons in the latest commit.
> > > > >> > Check the updated tree-declutter-patterns in leoSettings.leo
> > > > >> > for the accompanying rules. No need to use them of course
> > > > >> > but I think they make a big difference when using
> > > > >> > active-path.
> > > > >>
> > > > >> Like the way you handle removed files.
> > > > >>
> > > > >> Also, kudos for collapsing leoSettings.leo again before
> > > > >> pushing, so that it looks right when opened.
> > > > >>
> > > > >> Cheers -Terry
> > > > >>
> > > > >> > On Tuesday, August 11, 2015 at 8:18:30 AM UTC-4, john lunzer
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > Terry, the rule for showing the last part of filenames can
> > > > >> > > be improved to better support windows users:
> > > > >> > >
> > > > >> > > # show the last part of long filenames
> > > > >> > >
> > > > >> > > RULE ^.{1,1000}([/\\])(.{30})
> > > > >> > >
> > > > >> > > REPLACE …\1\2
> > > > >> > >
> > > > >> > >
> > > > >> > > The first capture group with faithfully respect the use of
> > > > >> > > backslashes in windows paths. (I like 30 instead of 20, no
> > > > >> > > need to change that though)
> > > > >> > >
> > > > >> > >
> > > > >> > > On Monday, August 10, 2015 at 5:09:42 PM UTC-4, john
> > > > >> > > lunzer wrote:
> > > > >> > >>
> > > > >> > >> Thanks for the pixel buffer! I've found a pixel buffer of
> > > > >> > >> 7 to be good.
> > > > >> > >>
> > > > >> > >> Anyway I found an instance in which the headline/icons
> > > > >> > >> won't update. On the use of edit-headline-long. If you
> > > > >> > >> press cancel nothing will happen, but if you hit enter
> > > > >> > >> then the headline will go back to normal and never update
> > > > >> > >> until the next update event (doesn't need to be the same
> > > > >> > >> headline).
> > > > >> > >>
> > > > >> > >> On Monday, August 10, 2015 at 10:55:21 AM UTC-4, Terry
> > > > >> > >> Brown wrote:
> > > > >> > >>>
> > > > >> > >>> On Mon, 10 Aug 2015 04:43:50 -0700 (PDT)
> > > > >> > >>> john lunzer <lun...@gmail.com> wrote:
> > > > >> > >>>
> > > > >> > >>> > Terry, I've noticed that the Icons butt right up
> > > > >> > >>> > against the status boxes. Is there any way to add a
> > > > >> > >>> > pixel or two (whichever looks best) of buffer between
> > > > >> > >>> > them?
> > > > >> > >>>
> > > > >> > >>> I've just pushed the addition of a setting
> > > > >> > >>> @int tree-icon-separation = 1
> > > > >> > >>> which controls icon separation in pixels.
> > > > >> > >>>
> > > > >> > >>> I also just pushed a fix to a hard crash of Leo when
> > > > >> > >>> declutter is active and you find two successive search
> > > > >> > >>> hits in headlines, I think what was happening was
> > > > >> > >>> (quoting commit):
> > > > >> > >>>
> > > > >> > >>> When search results are found in headlines headkey2
> > > > >> > >>> fires (on the second search hit in a headline), and
> > > > >> > >>> full_redraw() for declutter takes the headline out of
> > > > >> > >>> edit mode, and Leo crashes, probably because the find
> > > > >> > >>> code didn't expect to leave edit mode. So don't update
> > > > >> > >>> when a QLineEdit has focus
> > > > >> > >>>
> > > > >> > >>> I guess I'm not sure if it's the find code or just the
> > > > >> > >>> editing code in general, the fix should handle all
> > > > >> > >>> cases.
> > > > >> > >>>
> > > > >> > >>> Cheers -Terry
> > > > >> > >>>
> > > > >> > >>> > On Sunday, August 9, 2015 at 8:28:52 AM UTC-4, john
> > > > >> > >>> > lunzer wrote:
> > > > >> > >>> > >
> > > > >> > >>> > > Just delightful. Leo feels immensely more
> > > > >> > >>> > > personalized and dynamic with the declutter feature
> > > > >> > >>> > > (as if it already didn't feel that way). Let's not
> > > > >> > >>> > > forget to get this into the documentation
> > > > >> > >>> > > eventually.
> > > > >> > >>> > >
> > > > >> > >>> > > On Saturday, August 8, 2015 at 10:02:48 PM UTC-4,
> > > > >> > >>> > > Terry Brown wrote:
> > > > >> > >>> > >>
> > > > >> > >>> > >> On Sat, 8 Aug 2015 17:09:56 -0700 (PDT)
> > > > >> > >>> > >> john lunzer <lun...@gmail.com> wrote:
> > > > >> > >>> > >>
> > > > >> > >>> > >> > I've actually been thinking about this for a long
> > > > >> > >>> > >> > time, but I've wanted to implement parts of the
> > > > >> > >>> > >> > to-do plugin on purely text based input.
> > > > >> > >>> > >> >
> > > > >> > >>> > >> > So a task that wasn't done would start with [ ]
> > > > >> > >>> > >> > A task that was finished would be [*]
> > > > >> > >>> > >> > and a task that was cancelled would be [x]
> > > > >> > >>> > >> >
> > > > >> > >>> > >> > Can I access the task icons in the same way that
> > > > >> > >>> > >> > you're access the icons currently with declutter?
> > > > >> > >>> > >>
> > > > >> > >>> > >> Sure, so the rules would be:
> > > > >> > >>> > >>
> > > > >> > >>> > >> RULE ^\[ ] (.*)
> > > > >> > >>> > >> REPLACE \1
> > > > >> > >>> > >> ICON cleo/chkboxblk.png
> > > > >> > >>> > >> RULE ^\[\*] (.*)
> > > > >> > >>> > >> REPLACE \1
> > > > >> > >>> > >> ICON cleo/chkblk.png
> > > > >> > >>> > >> RULE ^\[[xX]] (.*)
> > > > >> > >>> > >> REPLACE \1
> > > > >> > >>> > >> ICON cleo/xblk.png
> > > > >> > >>> > >>
> > > > >> > >>> > >> `cleo` was the name of the plugin that preceeded
> > > > >> > >>> > >> `todo`, if you didn't know.
> > > > >> > >>> > >>
> > > > >> > >>> > >> Also I just updated the rules in leoSettings.py,
> > > > >> > >>> > >> they do the same thing, I just eliminated an
> > > > >> > >>> > >> editing artifact. They were like
> > > > >> > >>> > >>
> > > > >> > >>> > >> RULE ^@(clean) (.*)
> > > > >> > >>> > >> REPLACE \2
> > > > >> > >>> > >>
> > > > >> > >>> > >> and are now like
> > > > >> > >>> > >>
> > > > >> > >>> > >> RULE ^@clean (.*)
> > > > >> > >>> > >> REPLACE \1
> > > > >> > >>> > >>
> > > > >> > >>> > >> Cheers -Terry
> > > > >> > >>> > >>
> > > > >> > >>> > >> > On Saturday, August 8, 2015 at 1:52:20 PM UTC-4,
> > > > >> > >>> > >> > Terry Brown wrote:
> > > > >> > >>> > >> > >
> > > > >> > >>> > >> > > On Sat, 8 Aug 2015 10:45:37 -0700 (PDT)
> > > > >> > >>> > >> > > john lunzer <lun...@gmail.com <javascript:>>
> > > > >> > >>> > >> > > wrote:
> > > > >> > >>> > >> > >
> > > > >> > >>> > >> > > > Not sure if you had come across this but
> > > > >> > >>> > >> > > > different rules can co-exist. For example
> > > > >> > >>> > >> > > > along with all the @file type directives I
> > > > >> > >>> > >> > > > have .py files specifically bolded and both
> > > > >> > >>> > >> > > > the rule for adding the icon and the rule for
> > > > >> > >>> > >> > > > bolding co-exist without issue. This just
> > > > >> > >>> > >> > > > keeps getting better! I assume there could be
> > > > >> > >>> > >> > > > some issues if the rules affected the same
> > > > >> > >>> > >> > > > style aspects.
> > > > >> > >>> > >> > >
> > > > >> > >>> > >> > > The rules are just applied in sequence. Only
> > > > >> > >>> > >> > > gotcha is that if the first rule replaces
> > > > >> > >>> > >> > > `@clean ` with something else, subsequent rules
> > > > >> > >>> > >> > > that match `@clean ` won't fire - but I can't
> > > > >> > >>> > >> > > see when that would be a problem, and you can
> > > > >> > >>> > >> > > control the order.
> > > > >> > >>> > >> > >
> > > > >> > >>> > >> > > Cheers -Terry
> > > > >> > >>> > >> > >
> > > > >> > >>> > >> > > > On Saturday, August 8, 2015 at 1:39:03 PM
> > > > >> > >>> > >> > > > UTC-4, john lunzer wrote:
> > > > >> > >>> > >> > > > >
> > > > >> > >>> > >> > > > > Just pulled the most recent changes.
> > > > >> > >>> > >> > > > > Auto-update works great and the new icons
> > > > >> > >>> > >> > > > > look good. I'll be certain to let you know
> > > > >> > >>> > >> > > > > if I come across any issues.
> > > > >> > >>> > >> > > > >
> > > > >> > >>> > >> > > > > On Saturday, August 8, 2015 at 1:06:57 PM
> > > > >> > >>> > >> > > > > UTC-4, john lunzer wrote:
> > > > >> > >>> > >> > > > >>
> > > > >> > >>> > >> > > > >> Awesome, thanks for the quick updates,
> > > > >> > >>> > >> > > > >> I'll check them out soon (at the latest on
> > > > >> > >>> > >> > > > >> Monday).
> > > > >> > >>> > >> > > > >>
> > > > >> > >>> > >> > > > >> On Saturday, August 8, 2015 at 12:44:44 PM
> > > > >> > >>> > >> > > > >> UTC-4, Terry Brown wrote:
> > > > >> > >>> > >> > > > >>>
> > > > >> > >>> > >> > > > >>> Also just pushed some icons for different
> > > > >> > >>> > >> > > > >>> @<file> types, with support for the
> > > > >> > >>> > >> > > > >>> leo_dark_0 theme. See updated rules in
> > > > >> > >>> > >> > > > >>> leo/config/leoSettings.leo#@settings-->Tree
> > > > >> > >>> > >> > > > >>> operation-->@data tree-declutter-patterns
> > > > >> > >>> > >> > > > >>>
> > > > >> > >>> > >> > > > >>> Cheers -Terry
> > > > >> > >>> > >> > > > >>>
> > > > >> > >>> > >> > > > >>> On Sat, 8 Aug 2015 08:59:35 -0500
> > > > >> > >>> > >> > > > >>> "'Terry Brown' via leo-editor"
> > > > >> > >>> > >> > > > >>> <leo-e...@googlegroups.com> wrote:
> > > > >> > >>> > >> > > > >>>
> > > > >> > >>> > >> > > > >>> > On Fri, 7 Aug 2015 14:15:01 -0700 (PDT)
> > > > >> > >>> > >> > > > >>> > john lunzer <lun...@gmail.com> wrote:
> > > > >> > >>> > >> > > > >>> >
> > > > >> > >>> > >> > > > >>> > > One is that the conversions do not
> > > > >> > >>> > >> > > > >>> > > seem to take place until a certain
> > > > >> > >>> > >> > > > >>> > > action occurs in the tree. I can
> > > > >> > >>> > >> > > > >>> > > always get the conversions to happen
> > > > >> > >>> > >> > > > >>> > > from expanding a node (but not
> > > > >> > >>> > >> > > > >>> > > contracting a node). It also seems
> > > > >> > >>> > >> > > > >>> > > like sometimes the tree scrolls to a
> > > > >> > >>> > >> > > > >>> > > center a specific node after some
> > > > >> > >>> > >> > > > >>> > > conversions.
> > > > >> > >>> > >> > > > >>> >
> > > > >> > >>> > >> > > > >>> > I think these issues are fixed in the
> > > > >> > >>> > >> > > > >>> > latest push. It was tricky to get the
> > > > >> > >>> > >> > > > >>> > update to work, it's done on idle so
> > > > >> > >>> > >> > > > >>> > you're outside any redraw loop.
> > > > >> > >>> > >> > > > >>> >
> > > > >> > >>> > >> > > > >>> > Cheers -Terry
> > > > >> > >>> > >> > > > >>> >
> > > > >> > >>> > >> > > > >>>
> > > > >> > >>> > >> > > > >>
> > > > >> > >>> > >> > > >
> > > > >> > >>> > >> > >
> > > > >> > >>> > >> >
> > > > >> > >>> > >>
> > > > >> > >>> > >
> > > > >> > >>> >
> > > > >> > >>>
> > > > >> > >>
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
--
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
