Re: About unit testing Leo

I think going through so much of the Leo codebase as you have done in the last couple of weeks you've come up with something of a catalog of things that might benefit from different approaches, in some cases the benefit of hindsight, for that matter. I can't put together a detailed response right

Re: Copy/Paste into abbreviations weirdness

to False solved the issue. > > Vitalije > > On Friday, July 27, 2018 at 5:35:02 AM UTC+2, Terry Brown wrote: >> >> Ish - I see this in 4d23cbb5, but there's a block of commits which crash >> on load with current (vestigial) cache, making it hard to use git bisect. &

Re: Copy/Paste into abbreviations weirdness

Try 5ff9a7f3e5 Cheers -Terry On Fri, Jul 27, 2018 at 7:58 AM Rob wrote: > Just updated to latest in devel branch and it's still pasting the > placeholder text instead of clipboard. > > Rob... > > On Friday, July 27, 2018 at 3:57:47 AM UTC-4, vitalije wrote: >> >> I saw this behavior recently

Re: GitHub merge

Based on looking at `gitk --all` and then perhaps more efficiently `git log --stat`, I'd say what you did had no negative impact beyond perhaps an unnecessary merge commit - i.e. it didn't actually change any files in devel or anywhere else. Cheers -Terry On Fri, Jul 27, 2018 at 8:04 AM Rob

Re: GitHub merge

It is in the main GitHub repo., but I'm not sure if it's doing any harm. I.e. it might just be merge commit that merges branches that were already in sync. bar trivial changes. I'll investigate a bit more. Cheers -Terry On Fri, Jul 27, 2018 at 8:04 AM Rob wrote: > After returning from an

Re: Copy/Paste into abbreviations weirdness

Ish - I see this in 4d23cbb5, but there's a block of commits which crash on load with current (vestigial) cache, making it hard to use git bisect. I guess a clean ~/.leo should work... so running git bisect and launching Leo like this: rm -rf /tmp/.leo ; HOME=/tmp python3

Re: My future with Leo

On Sat, 21 Jul 2018 03:59:25 -0700 (PDT) "Edward K. Ream" wrote: > Recent discussions convince me that Leo is in excellent hands with > Terry and Vitalije. This is reassuring. Leo is likely to thrive > after I am gone. It has also been upsetting. I am no longer an > essential part of my own

Re: Empty node bug - just me?

On Sun, 3 Jun 2018 11:06:23 -0500 "Edward K. Ream" wrote: > On Thu, May 31, 2018 at 4:52 PM, Terry Brown > wrote: > > > Anyone else seen this behavior? > > > > Load outline. Top node of a Python @auto file will be marked > > dirty, and a node in

Re: curly quotes

On Tue, 17 Jul 2018 13:54:16 -0400 Jeff Filipovits wrote: > I am a lawyer and would like to use Leo to keep track of research and > potentially assist in writing briefs. This is a relatively petty > thing, but it is driving me crazy. Is there a way to get Leo use > curly (single and double)

Large project collaboration

This a long post which dredges up some of the recent discussion and looks at different ways of moving forward from there. Please read to the end before responding to perhaps non-central points :) The big issue - what is the future of the Leo code base? First a couple of delayed responses to some

Re: ENB: positions are intuitive

On Mon, Jul 9, 2018 at 11:22 AM Edward K. Ream wrote: > > A more clever, more useful, representation of positions may be possible. > If so, it will, perforce, be less intuitive than Leo's present positions. > > Edward > It seems though that any loss of intuitiveness would only impact Leo devs.,

uni-clones, this is not the cache you're looking for...

Saw the uni-clones again this morning, but they went away after I'd saved and reloaded the file. 950eb2c66. Same @clean file. But here's the thing I forgot to mention. My workflow involves moving the .leo file, but not the corresponding cache, between two machines, in a repeating cycle. Hmm,

Re: TDD on languages other than python?

On Thu, 5 Jul 2018 06:44:48 -0500 "Edward K. Ream" wrote: [snip] > Anyone have other ideas? > > Naturally, what you do will depend on what TDD facilities are already > available in the other language. > > Edward I find I prefer to use pytest https://pytest.org/ for python testing, first and

Re: fast-read branch has been merged into devel

On Mon, 2 Jul 2018 16:08:02 -0500 "Edward K. Ream" wrote: > On Mon, Jul 2, 2018 at 10:54 AM, Terry Brown > wrote: > > > Just in case anyone else sees anything similar. When first opening > > an outline with the new merged devel/fast-read branch 950eb2c66b51, &

Re: fast-read branch has been merged into devel

Just in case anyone else sees anything similar. When first opening an outline with the new merged devel/fast-read branch 950eb2c66b51, I had a @clean file in which all the nodes were marked as clones. Goto next clone and regular searching could not find any corresponding clone though. Over

Re: IPC: A virtual sprint/classroom?

On Thu, 28 Jun 2018 09:06:20 -0700 (PDT) "Edward K. Ream" wrote: > Leo already supports IPC in several ways: > > 1. The cursesGui2 plugin uses a broadcast/listener pattern for > debugging. The Leo edit pane widgets use signals using

Re: How to retire --no-cache?

On Thu, 28 Jun 2018 09:18:13 -0500 "Edward K. Ream" wrote: > On Thu, Jun 28, 2018 at 6:49 AM, jkn wrote: > > I have to say that although I think GvR's steering of Python > development as > > BDFL has generally been extraordinarily skillful, the jumping > > around with command-line parsing

Re: fast-read branch fixes caching

On Wed, 27 Jun 2018 11:28:11 -0500 "Edward K. Ream" wrote: > > gives KeyError.  Also c.db.keys() used to exist > > ​Both fixed at ​ced5a06. All looks good now thanks. Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To

Re: fast-read branch fixes caching

On Wed, 27 Jun 2018 06:15:10 -0700 (PDT) "Edward K. Ream" wrote: > Rev 467742f > > > in fast-read fixes caching. In particular, the bookmarks plugin > should work. Please test and report any problems.

Re: fast-read will be merged into devel tomorrow

On Tue, 26 Jun 2018 08:28:29 -0500 "Edward K. Ream" wrote: > On Tue, Jun 26, 2018 at 7:11 AM, lewis > wrote: > > > Hi Terry, > > > > I have switched to using the fast-read branch. When I load a > > bookmarks layout in a leo file, the same bookmarks layout becomes > > active for all other files

Re: fast-read will be merged into devel tomorrow

On Tue, 26 Jun 2018 05:11:42 -0700 (PDT) lewis wrote: > Hi Terry, > > I have switched to using the fast-read branch. When I load a > bookmarks layout in a leo file, the same bookmarks layout becomes > active for all other files I open. > File specific bookmarks do not show. It sounds like c.db

Re: fast-read will be merged into devel tomorrow

Got a hard crash: Traceback (most recent call last): File "D:\local\leo-editor\leo\plugins\contextmenu.py", line 318, in refresh_rc lick_cb c.refreshFromDisk() File "D:\local\leo-editor\leo\commands\commanderFileCommands.py", line 245, in refreshFromDisk c.recreateGnxDict() File

Re: fast-read will be merged into devel tomorrow

On Mon, 25 Jun 2018 11:11:14 -0500 Terry Brown wrote: > I'm not sure if these times are fair p.s. all times are for a second run after a first run to warm the OS read caches. Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-edito

Re: fast-read will be merged into devel tomorrow

On Mon, 25 Jun 2018 06:11:43 -0700 (PDT) "Edward K. Ream" wrote: > The new code seems rock solid, and I see no reason not to make it > available for wider testing. Maybe it makes little difference, but reducing yesterday's "in a week" to today's "tomorrow" does limit the time for testing. >

Re: Import freemind files into leo

On Fri, Jun 22, 2018 at 3:52 PM Thomas Passin wrote: > Good move, since ElementTree is included in the standard Python distro > (there was a time when it wasn't). > It's possible the plug-in's old enough to pre-date the inclusion of ElementTree in Python. It's also possible that the plugin

Git / clone oddness

This is maybe just an instance of the branch switching clone issues Edward's reported before, but I just noticed https://github.com/leo-editor/leo-editor/commit/423365ce1540159 on the qdock-layout branch duplicated a node in ipynb.py. I thought I might have just fat fingered a duplicate, but

Re: leo_cloud coolness and gotchas

On Fri, 15 Jun 2018 09:00:44 -0700 (PDT) Rob wrote: > That works, but the path is different to the DropBox (or Google > Drive) local folders on different machines and OS's. That's not a > problem for the leoSettings file, but I can't use that strategy for > other use cases I envision. I had not

Re: leo_cloud coolness and gotchas

On Fri, 15 Jun 2018 08:23:18 -0700 (PDT) Rob wrote: > Recently, I discovered the excellent and useful plugin, leo_cloud.py > (thanks Terry Brown!) My initial interest was to find an easier way > to sync myLeoSettings across multiple machines, locations and OS's. I > see add

Re: Inspired by Vitalije's prototype

On Tue, 12 Jun 2018 09:30:51 -0500 "Edward K. Ream" wrote: > > And I say Leo's architecture could be way more simpler and more > > modular, allowing people to more easily contribute with less > > control from anyone. There is only a minimal neccessary core for > > what leo is doing, the rest is

Re: Hang on Session Start

On Mon, 11 Jun 2018 18:29:39 -0700 (PDT) Chris George wrote: > I use @path to load my music collection in a Leo file. This allows me > to comment on albums and songs. I can launch directly from the > organizer tree. Leo is ideal for this use. Chris was it you who started using leo_cloud

Re: ENB: Changes to caching

Top posting because I'm replying on my phone. The freelayout machinery also writes to c.db to associate layout with outline, and maybe g.db to store layouts. The qdock based layout system is different but still needs something like c.db. Cheers - Terry On June 9, 2018 6:54:39 AM CDT, "Edward

Re: The fast-read branch is ready for (careful!) testing

On Fri, 8 Jun 2018 09:16:58 -0700 (PDT) "Edward K. Ream" wrote: > Investigate whether the --no-cache command-line option is still > needed. This is a non-trivial question, because Leo caches things > like the current position, etc.  It may be that only the "global" db > key will be used, but we

Re: We can test/explore new features if auto-update for code and docs is available on the UI (was Re: Please read: "You can do that if...")

On Mon, 4 Jun 2018 07:32:43 -0700 (PDT) "Edward K. Ream" wrote: > 1. Install git. > 2. git clone https://github.com/leo-editor/leo-editor.git (once) > 3. git checkout (whenever you like) > > And that's it.  Doing anything else is a waste of your time. Same result without using the command

Re: Inspired by Vitalije's prototype

On Fri, Jun 1, 2018 at 2:57 PM, vitalije wrote: > This is exactly why I was reluctant to share unfinished prototype. I did > beg you though, not to make any decisions before the prototype is finished, > but it seems too hard to resist. I couldn't resist the temptation to share > the unfinished

Empty node bug - just me?

Anyone else seen this behavior? Load outline. Top node of a Python @auto file will be marked dirty, and a node in that file will be empty, except for having the right headline (the headline of the def the node should have contained). Refresh from disk fixes it. Saving the file without refresh

@bool add-context-to-headlines = False

I'm going to argue that add-context-to-headlines should be False by default. I think it's clear why from the two attached images, one is unpleasant to look at and the other truncates method names. I think this added context in the headlines is really only useful when you've cloned a node and

Re: Are startup scripts worth doing?

On Mon, 28 May 2018 12:52:57 -0700 (PDT) "Edward K. Ream" wrote: > The startup branch > contains > implements #740 > : "execute > leo_startup.py on startup". > > However, I have serious

Re: Documentation on new data model for Leo outlines

On Thu, 17 May 2018 12:00:30 -0700 (PDT) Matt Wilkie wrote: > > Veering off topic I wish there was a more general solution for dot > > access to dict members, I understand all the arguments against, but > > often writing mathematical expressions... > > > > col = (pos['x'] -

Re: Documentation on new data model for Leo outlines

On Tue, 15 May 2018 08:04:21 -0500 "Edward K. Ream" <edream...@gmail.com> wrote: > On Tue, May 15, 2018 at 6:55 AM, Terry Brown <terrynbr...@gmail.com> > wrote: > > > What about a namedtuple? > > ​That or a bunch. Just to be clear, ​the code itsel

Re: Documentation on new data model for Leo outlines

On Tue, 15 May 2018 04:36:15 -0700 (PDT) "Edward K. Ream" wrote: > *Readability will not affect performance* > > attrs[gnx] is a tuple [h, b, ps, chn, sz[0]]. The components should > be accessed via a bunch, or an enum, say, > > e_h = 0 > e_b = 1 > e_ps = 2 What about a

Re: Global and local @outline-data tree-abbreviations

On Mon, 14 May 2018 09:34:27 -0700 (PDT) Rob wrote: > I have a quite extensive (and growing) collection of tree > abbreviations in myLeoSettings.leo. I would like to also have some > local-only tree abbreviations that are only relevant for specific > xxx.leo files. For

Re: Scope issues when using lisp-like style

On Mon, 14 May 2018 01:31:57 -0700 (PDT) vitalije wrote: > for a,b,c in helper_1(x, y): > m,n,r = a, b, c Think I stumbled on that myself once. If it was common, it could be m, n, r = update_from(helper_1(x, y), m, n, r) where def update_from(aList, *args):

Re: Column tracking

On Thu, 10 May 2018 09:48:52 -0500 Kent Tenney wrote: > cursor location info like > line: 3 col: 21 fcol: > > - what is the difference between col: and fcol: > - I don't see either one tracking cursor position > > Is it just me? It's just you, everyone else sees the cursor

Re: Nearing the end of code cleanups

On Thu, 10 May 2018 07:10:13 -0700 (PDT) "Edward K. Ream" wrote: > - Hundreds of useless 'if trace: g.trace(...)' lines are gone. This is great, it will make Leo's source that much easier to read. For tracing I typically just add print statements as needed, then delete

Re: A new diff script allows mass updates of code

On Tue, 8 May 2018 09:03:02 -0700 (PDT) "Edward K. Ream" wrote: > On Tuesday, May 8, 2018 at 6:40:37 AM UTC-5, Edward K. Ream wrote: > > > The scrip creates outline-oriented diffs between *all* changed > > files > between any two revs. > > This script seems like a

Re: ENB: Fixing clone problems

On Mon, 7 May 2018 08:10:49 -0500 "Edward K. Ream" wrote: > Unless other problems arise we'll make this part of 5.7.3. Imo, the > buggy legacy code is good enough for master & 5.7.2 branches because > devs will be using devel. Haven't been following this thread in detail,

Re: New c.interactive* methods

On Thu, 3 May 2018 15:02:46 -0700 (PDT) "Edward K. Ream" wrote: > @g.command('i2') > def i2_command(event): > c = event.get('c') > if not c: return > > def callback(arg1, arg2, c, event): > g.trace(arg1, arg2) > c.bodyWantsFocus() > >

Re: ENB: Why I think keyword args are benign

On Tue, 1 May 2018 16:05:18 -0500 "Edward K. Ream" wrote: > ​Sounds reasonable. I wonder, is there any plausible situation in > which a ​uA wouldn't be json serializable? > > Anyone have thoughts about this? Well, every time a user's placed a non-JSON-serializable key or

Re: ENB: Why I think keyword args are benign

On Sat, 28 Apr 2018 22:25:09 -0700 (PDT) David Szent-Györgyi wrote: > On Tuesday, April 24, 2018 at 8:38:37 AM UTC-4, Edward K. Ream wrote: > > > > > > It looks like json.dumps may have problems with > > p.v.unknownAttributes fields. > > > > Again, not a gotcha, but something

Re: Please read: recent changes to master and devel

Eh, while we're doing this discussion of Leo architecture thing, here's a longish email I wrote the other day and didn't send... On Wed, 25 Apr 2018 17:22:18 -0700 (PDT) "Edward K. Ream" wrote: > All comments welcome. I'm not sure this is a very valuable comment, and

Re: LeoU: Formal code review of vnode class

On Mon, 30 Apr 2018 05:07:05 -0500 "Edward K. Ream" wrote: > > Finally though another point that I think Vitalije also touches on - > > these discussions are not unhealthy, but they're not really > > productive either, unless there's serious interest in major > >

Re: LeoU: Formal code review of vnode class

FWIW, I think I generally agree with Vitalije. First, seeing everyone's apologizing ;-) let me apologize for dragging an attempt at general discussion into the weeds of specifics, I know that's annoying. I know that the point doesn't rest on the particular history of uAs or VNodes or whatever.

Re: keys2 branch merged into devel

On Fri, 27 Apr 2018 20:24:47 -0700 (PDT) lewis wrote: > I'm seeing weird backspace behaviour in headline. > Create a node test1. Use backspace to delete characters from the > headline. Backspace deletes fine if you start from eol. > > Place cursor before 'test1' and

Re: Non essential features are harmful (or not)

On Fri, 27 Apr 2018, vitalije wrote: Finally, it seems that you know much more about uA's use cases. Have you ever put something in uA's that isn't json serializable? I want to try and analyze that more, maybe just by searching my drives for .leo files and passing them through the JSON

Re: Non essential features are harmful (or not)

On Fri, 27 Apr 2018, vitalije wrote: as much independent of each other many classes would look differently. For example one of the most basic element of Leo's data is certainly VNode. And yet one can not instantiate VNode class without acquiring full blown commander, which in VNode is known

Re: ENB: Why I think keyword args are benign

On Tue, 24 Apr 2018 07:38:35 -0500 "Edward K. Ream" wrote: > It looks like json.dumps may have problems with p.v.unknownAttributes > fields. In theory yes, in practice not so much, although still a potential problem. The leo_cloud plugin stores outlines (well, subtrees,

Re: ENB: Why I think keyword args are benign

On April 24, 2018 4:58:52 AM CDT, "Edward K. Ream" wrote: >On Mon, Apr 23, 2018 at 1:46 PM, vitalije wrote: > >Terry, do you have any comments? I haven't been following the code, just the discussion. I'm in favor of incremental simplification where

Re: keys2 branch merged into devel

On Sun, 22 Apr 2018 08:50:04 -0700 (PDT) "Edward K. Ream" wrote: > I have just completed the last part the keys2 branch and merged it > into devel. > > Please test devel, *not *keys2. > > I merged keys2 into devel a day early because of problems pulling and > pushing from

Re: Schedule for keys2 branch, Leo 5.7.2

On Fri, 20 Apr 2018 10:35:51 -0700 (PDT) "Edward K. Ream" wrote: Congrats. on the keys2 branch > I would like to release Leo 5.7.2 a week from today, on Friday April > 27. The following bugs must be fixed first: I'd add https://github.com/leo-editor/leo-editor/issues/388.

Key / Menu issue Re: [leo-editor/leo-editor] Detach: AttributeError: 'LeoQtGui' object has no attribute 'getImageImageFinder' (#864)

On Thu, 19 Apr 2018 14:13:33 + (UTC) wangzhaohe wrote: > Thanks! It runs well now! > > But I found another problem in **branch devel**: > > /home/swot/.leo/myLeoSettings.leo#@settings-->Menus-->@menus-->@menu > >@menu Recent > > Recent : F can not be pressed.

Re: The keys2 branch is now of devel quality

On Tue, 17 Apr 2018 11:24:04 -0500 "Edward K. Ream" wrote: > On Tue, Apr 17, 2018 at 9:34 AM, Edward K. Ream > wrote: > > ​> It should now be pretty safe to use the keys2 branch. Please do > > test this cod​e. > > Some recent rev broke abbreviations.

Re: ENB: #423, improving Leo's key handling

On Sat, 14 Apr 2018 13:47:46 -0500 Terry Brown <terrynbr...@gmail.com> wrote: > Ctrl-F seems broken in aa23ac452c9f, I was thinking this was related > to the #794 but now realize it's probably the new key handling code. > Focus looks right, but nothing I can do (click, select, wh

Re: ENB: #423, improving Leo's key handling

Ctrl-F seems broken in aa23ac452c9f, I was thinking this was related to the #794 but now realize it's probably the new key handling code. Focus looks right, but nothing I can do (click, select, whatever) let's me type content in the Find: field. Cheers -Terry -- You received this message

Re: Completed #848:

On Wed, 11 Apr 2018 05:26:47 -0700 (PDT) "Edward K. Ream" wrote: > #848 Recent Files menu will break for foreign languages > is now > complete. The first non-blank, non-comment line of the node `@menu > Recent Files'

Re: Please try @auto for Jupyter Notebooks

On Tue, 10 Apr 2018 11:40:36 -0500 "Edward K. Ream" wrote: > ​This may be yet another 2/3 difference. Try e912eeb67. Ok, no tracebacks, cool. Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe

Re: Please try @auto for Jupyter Notebooks

On Tue, 10 Apr 2018 11:26:02 -0500 "Edward K. Ream" wrote: > > > > So it loaded, but with the Traceback I just posted. > > > ​Please try fb16c99b9. Seems to work, but still a Traceback Leo Log Window Leo 5.7.2 devel, build 20180408225138, Sun Apr 8 22:51:38 PDT 2018

Re: Please try @auto for Jupyter Notebooks

On Tue, 10 Apr 2018 10:49:27 -0500 Terry Brown <terrynbr...@gmail.com> wrote: > conda says it was installed already. Current trunk 77b8c7d833 I'm > getting but it did load the file now, so 77b8c7d833 must have helped. So it loaded, but with the Traceback I just posted. Cheers -Te

Re: Please try @auto for Jupyter Notebooks

On Tue, 10 Apr 2018 10:39:05 -0500 "Edward K. Ream" <edream...@gmail.com> wrote: > On Tue, Apr 10, 2018 at 8:50 AM, Terry Brown <terrynbr...@gmail.com> > wrote: > > p.s. I also got > > ​[no children] in the @auto node, > > ​You won't get anythin

Re: Please try @auto for Jupyter Notebooks

p.s. I also got this in the @auto node, @nocolor-node Note: This node's body text is ignored when writing this file. The @others directive is not required but no children. Not necessarily at the same time as the exception, the above might have come from refresh from disk, whereas the

Re: Please try @auto for Jupyter Notebooks

On Tue, 10 Apr 2018 05:40:00 -0700 (PDT) "Edward K. Ream" wrote: > Please, please, give this a try and tell me what you think. Imo it > moots a lot of Jupyter-related work on Leo's to-do list. Well, my aspiration was not a better way to edit notebooks, but a way to execute

Re: 45b20e4: Third draft of eval commands optionally restores legacy operation

On Fri, 30 Mar 2018 07:18:29 -0500 "Edward K. Ream" <edream...@gmail.com> wrote: > On Fri, Mar 30, 2018 at 7:07 AM, Terry Brown <terrynbr...@gmail.com> > wrote: > > > Yes, as far I can tell, although it occurs to me I should check > > larger blocks mor

Re: 45b20e4: Third draft of eval commands optionally restores legacy operation

Yes, as far I can tell, although it occurs to me I should check larger blocks more. Cheers - Terry On March 30, 2018 2:56:13 AM CDT, "Edward K. Ream" <edream...@gmail.com> wrote: >On Thu, Mar 29, 2018 at 8:11 PM, Terry Brown <terrynbr...@gmail.com> >wrote: > &

Re: 45b20e4: Third draft of eval commands optionally restores legacy operation

On Thu, 29 Mar 2018 18:35:49 -0500 "Edward K. Ream" <edream...@gmail.com> wrote: > On Thu, Mar 29, 2018 at 4:57 PM, Terry Brown <terrynbr...@gmail.com> > wrote: > > > vs-eval would eval the selection if there was one, eval doesn't > > seem to do t

Re: 45b20e4: Third draft of eval commands optionally restores legacy operation

On Thu, 29 Mar 2018 14:39:23 -0700 (PDT) "Edward K. Ream" wrote: > The "legacy" ivar, set using @bool legacy-eval, controls whether the > old or new code is used. The default is True if no such setting is > found. > > The new code is much like the old. The old_eval and >

Re: Syntax colorizer change for html

arching, I can't find the 'missing link'. > > > > Rob... > > > > On Thursday, March 29, 2018 at 3:48:03 PM UTC-4, Terry Brown > > wrote: > >> > >> > >> with @language html at top of node, and my personal old solarized > >> dark theme, I s

Re: File Templating

On Thu, 29 Mar 2018 10:40:51 -0700 (PDT) k-hen wrote: > Hi All, > > I'm familiar with the scripting components but was wondering if > there's an existing way to do basic templating using @files. > > Essentially for starters I just want to be able to reference the >

Re: a9709ee: second draft of eval command

On Thu, 29 Mar 2018 10:56:32 -0500 "Edward K. Ream" wrote: > To repeat, I don't plan to going back to the old code. It is not sound > because it can't handle "else" or any other compound statement. See > the post script. The old code relied on the user to select a valid

Re: a9709ee: second draft of eval command

On Thu, 29 Mar 2018 10:36:48 -0500 "Edward K. Ream" wrote: > > > After the exec, the local dictionary contains all results. These > > > become the self.answers array. > > > > They don't seem to be in c.vs - how are the accessed now? > > ​The only "connection" is in the

Re: a9709ee: second draft of eval command

On Thu, 29 Mar 2018 02:08:15 -0700 (PDT) "Edward K. Ream" wrote: > I spent quite a few happy hours yesterday and this morning completely > revising the EvalController code. Which probably makes it hard to hear a bunch of whiny criticism, but all the functionality of these

Re: ENB, for Terry: Moving 4 (or 5?) vs- commands to mod_scripting

On Wed, 28 Mar 2018 04:31:11 -0700 (PDT) "Edward K. Ream" wrote: > I am about to start work on #839 > : Split > valuespace plugin in two. Some questions and comments: > > 1. It looks like vs-eval-replace should be moved

Re: color icons

On Tue, 27 Mar 2018 14:26:36 -0700 (PDT) jkn <jkn...@nicorp.f9.co.uk> wrote: > On Tuesday, March 27, 2018 at 6:26:36 PM UTC+1, Terry Brown wrote: > > > > https://github.com/leo-editor/snippets/blob/master/examples/tests/make_icons.py > > > > > > ma

color icons

https://github.com/leo-editor/snippets/blob/master/examples/tests/make_icons.py make the simple icons attached. Intended for dark rather than light background. Might be useful for other automated icon generation things, seeing it iterates the 16 states in the correct 00..15 order. Maybe it

Change to icon functions

5406b6e45 changes the calling signature of appendImageDictToList, it no longer accepts an iconDir parameter. Always hard to know when a method's "internal" and can be changed this way or part of the external API and shouldn't be changed. Let me know if it causes trouble for anyone, we can change

Re: Soon! valuespace and jupyter

On Mon, 26 Mar 2018 15:21:39 -0500 "Edward K. Ream" wrote: > There will be a natural back and forth between the vs- commands and > corresponding jupyter interface Just to clarify, while there can be jupyter aware vs-* commands, I argue for set of jupyter free vs-eval

Re: Soon! valuespace and jupyter

On Mon, 26 Mar 2018 10:55:36 -0700 (PDT) "Edward K. Ream" wrote: > On Monday, March 26, 2018 at 11:50:15 AM UTC-5, Edward K. Ream wrote: > > > There are several problems with the vs- commands. > > I am thinking that these commands might move into the mod_scripting >

Re: tree icons

On Thu, 22 Mar 2018 15:22:50 -0700 (PDT) "Edward K. Ream" wrote: > Arrrgh. The present code does not handle --theme correctly, nor does > it handle double-clicking, say, BreezeDarkTheme.leo. The stylesheet > is computed correctly, but not the icons (in general). Instead, >

Re: tree icons

appendImageDictToList() in qt_tree.py needs re-education. It takes an icon dir. computed by the client and tacks the clients requested icon path on to it. So it's working in the declutter code, because the icon path comes from g.app.gui.getImageFinder() and so is absolute so the icon dir.

Re: tree icons

On Thu, 22 Mar 2018 11:49:36 -0500 "Edward K. Ream" wrote: > 2. Terry's code uses g.os_path_join instead of > g.os_path_finalize_join. The differences are obscure. Terry, does > the code work for you using g.os_path_finalize_join? Results are the same. > 4. The most

Re: tree icons

On Thu, 22 Mar 2018 06:18:55 -0500 "Edward K. Ream" <edream...@gmail.com> wrote: > On Wed, Mar 21, 2018 at 10:41 PM, Terry Brown <terrynbr...@gmail.com> > wrote: > > > 6c71e872c1c8 is very close to working, could even be considered to > > be wor

Re: tree icons

6c71e872c1c8 is very close to working, could even be considered to be working, it's showing dark icons etc. Not sure if they're the same ones as before or perhaps transparent icons on a dark background, but they look ok. -- You received this message because you are subscribed to the Google

Re: tree icons

commit 3d8564 This still looks odd to me: getImageFinder ... @string color_theme: leo_dark_0 @string theme_name: leo_dark_0 @string theme_path: None home: C:/Users/tbrown02 leo: D:/local/leo-editor/leo directory table... [

Re: tree icons

On Wed, 21 Mar 2018 12:15:37 -0500 "Edward K. Ream" wrote: > Rev 79b8101 fixes another home-directory bug in ​ no obvious change this end, sorry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this

Re: tree icons

On Wed, 21 Mar 2018 11:42:43 -0500 "Edward K. Ream" wrote: > I am hoping that this fix will explain lots of mysteries. still not working here I invoked Leo like this: python.exe launchLeo.py --no-splash --trace-startup --theme=leo_dark_0 >log 2>&1 getImageFinder ...

Re: tree icons

On Wed, 21 Mar 2018 05:42:42 -0700 (PDT) "Edward K. Ream" wrote: > On Wednesday, March 21, 2018 at 6:47:27 AM UTC-5, Edward K. Ream > wrote: > > Where do icons reside when they load correctly? > > In an ENB I am writing I predict that either of the following might > solve

Re: 848fca9 & 18f08bf: A rewrite of qt_gui.getImageFinder

On Tue, 20 Mar 2018 18:56:35 -0700 (PDT) Chris George wrote: > I would say the ability to point to these images lies somewhere else > in Leo's code. Can't imagine that it hasn't been encountered in the recent work, but I know there's some code that caches icons, for cases

Re: 848fca9 & 18f08bf: A rewrite of qt_gui.getImageFinder

On Tue, 20 Mar 2018 17:33:59 -0700 (PDT) "Edward K. Ream" wrote: > On Tuesday, March 20, 2018 at 7:25:54 PM UTC-5, Edward K. Ream wrote: > > Imo, this should find images in all the reasonable places, in the > most > > reasonable order. > > > > Rev ece92f9 adds the

Re: tree icons

On Tue, 20 Mar 2018 16:15:12 -0700 (PDT) "Edward K. Ream" <edream...@gmail.com> wrote: > On Tuesday, March 20, 2018 at 1:04:54 PM UTC-5, Terry Brown wrote: > > > > Doh, my theme had survived unscathed until just now, now my tree > > icons are

Re: tree icons

On Tue, 20 Mar 2018 13:30:50 -0500 "Edward K. Ream" <edream...@gmail.com> wrote: > On Tue, Mar 20, 2018 at 1:16 PM, Edward K. Ream <edream...@gmail.com> > wrote: > > On Tue, Mar 20, 2018 at 1:04 PM, Terry Brown <terrynbr...@gmail.com> > wrote: > &g

Re: tree icons

On Tue, 20 Mar 2018 13:04:51 -0500 Terry Brown <terrynbr...@gmail.com> wrote: > Doh, my theme had survived unscathed until just now, now my tree icons > are light in a dark theme. How do I fix that? Also seeing can not load image: /home/tbrown/local/leo-editor/leo/Icons/file_

tree icons

Doh, my theme had survived unscathed until just now, now my tree icons are light in a dark theme. How do I fix that? Thanks, 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,

<    1   2   3   4   5   6   7   8   9   10   >