Re: Proposal: abandon support for .json files and jupyter notebooks.

On Wed, Jul 5, 2023 at 12:06 PM Thomas Passin wrote: > There's a large difference between Edward's work flow and mine - not that either of us has a single "work flow", I'm sure. He likes to use clones extensively - often extracting them with the cff command, I think. Correct. > Edward has done

Re: Why gnx-based unls are important

On Wed, Jul 5, 2023 at 12:14 PM Thomas Passin wrote: > I don't think the concept of operations for the new UNLs has been fully worked out yet. I know of no problems whatsoever with gxn-based unls. Leo's new link-resolution code significantly improves the operation of legacy (path-based)

Re: Why gnx-based unls are important

On Wed, Jul 5, 2023 at 11:57 AM jkn wrote: On my Linux box, I get something in the lower 'status bar' like(*) > > unl:///home/jkn/path/to/myfile.leo#node-->subnode-->subnode > > but when I run on my windows machine, the same file (shared via NextCloud) > will not be like this, shurely? What

Re: Discuss: retire two of the three new gnx-related settings?

On Wednesday, July 5, 2023 at 6:29:35 AM UTC-5 Edward K. Ream wrote: If these settings must remain, their default values should change to: - *@string unl-status-kind = gnx* - *@bool full-unl-paths = False* Alright. These settings will remain with the new defaults shown above. It's time

Re: Discuss: retire two of the three new gnx-related settings?

On Wed, Jul 5, 2023 at 8:48 AM Thomas Passin wrote: > I disagree about removing the *@string unl-status-kind* setting. I get > the most value from the status bar when I can see the path of a node. A > gnx-based unl tells me nothing useful. If I want to see if the node is in > the outline I

Unbreakable unls have already changed my workflow

I am using unbreakable (gnx-based) unls (clickable links) as a lightweight alternative to clones. As you probably know, I use clones extensively while developing code. I create an organizer node for each issue/PR. This organizer node contains clones of all nodes related to my work. Once

Re: Proposal: abandon support for .json files and jupyter notebooks.

On Wednesday, July 5, 2023 at 7:00:47 AM UTC-5 iamap...@gmail.com wrote: In most cases reading a .json file into a single file is a good enough *start*. You can then convert the node to @clean and reorganize as you like. OK, it seems like a reasonable solution. Thanks Edward You're welcome.

New PRs related to gnx-based unls

PR #3424 contains *small* tweaks to Leo's code. Retiring the two settings discussed in this post would be a much bigger change. If Thomas agrees to the change I'll create

Discuss: retire two of the three new gnx-related settings?

Don't panic. I'm not going to do anything rash. Imo, there is no need for these two new settings: - *@string unl-status-kind = legacy* - *@bool full-unl-paths = True* If these settings must remain, their default values should change to: - *@string unl-status-kind = gnx* - *@bool

Re: Proposal: abandon support for .json files and jupyter notebooks.

On Wed, Jul 5, 2023 at 5:07 AM HaveF HaveF wrote: > I don't recall a proposal to abandon .json files. Can you refresh my >> memory? >> > I read it in this thread > : > > > The present importer for (special-format!) .json files

Why gnx-based unls are important

This post explains why PR #3215 (gnx-based unls) is a milestone in Leo's history. gnx-based unls are a fundamental resource comparable in importance to @clean and cff: - Unls won't break if you rename or move a node. - Leo supports

Re: Custom Menus Can Be Very Useful - An Example

On Tue, Jul 4, 2023 at 10:31 PM Thomas Passin wrote: > I create a custom menu for Leo that is located just before the *Help* menu. > It's been so useful that I want to encourage others to create their own. Thanks for this post. Please create a developer info item. Edward -- You received

Re: Proposal: abandon support for .json files and jupyter notebooks.

On Wed, Jul 5, 2023 at 3:40 AM HaveF HaveF wrote: > Of course, .ipynb files are not worth to support. > I don't recall a proposal to abandon .json files. Can you refresh my memory? Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To

Leo 6.7.4 on schedule for Friday, July 14

We have 10 days to test the big PR. I expect no significant problems. The remaining issues on the 6.7.4 list are optional. Otoh, I'll delay the release if unexpected problems arise. There is no rush.

PR #3215 (gnx-based unls) merged into devel

PR #3215 is a milestone in Leo's history. It contains spectacular new resources for users and writers of Leonine scripts and plugins. The PR is too big, but I make no apologies :-) The first comment discusses the changes in detail. New

Re: gnx-based unls make the backlink and quickMove plugins obsolete

On Mon, Jul 3, 2023 at 10:23 PM Thomas Passin wrote: This is getting me to think there should be a new method, say > c.getCrossfileUnl(p), that returns a tuple (file, gnx). (p.v.context.fileName(), p.gnx) Edward -- You received this message because you are subscribed to the Google Groups

gnx-based unls make the backlink and quickMove plugins obsolete

These plugins create and manage links, including cross-outline links. But gnx-based unls can also refer to nodes in other outlines! Most users will have no need for either plugin. Both plugins save link data in uAs. That's an interesting approach! However, a script could easily create uAs

Re: Enhancement - Dragging outline to desktop icon should open in same Leo session

\On Monday, July 3, 2023 at 12:38:38 PM UTC-5 Thomas wrote: Some people launch Leo from a desktop icon. If you have such an icon and drag'n'drop an outline on it, the outline will open in a new Leo session. Drag another outline, get yet another Leo session. Feel free to create an

Re: A new unit test pattern

On Mon, Jul 3, 2023 at 11:23 AM Edward K. Ream wrote: g.findAnyUnl assumes that @data unl-path-prefixes is functional. Setting up > this condition is more complicated than usual. > > > One new helper helps simulate the @data unl-path-prefixes setting. > > > The other new he

A new unit test pattern

I have been adding new unit tests for some (not all) new functions/methods in the big PR. Some of these tests are more complicated than usual. For example, tests of *g.findAnyUnl* require that the *@data unl-path-prefixes* setting refers to actual files. The details are a bit messy, so I

Re: Debate: always save session data?

On Monday, July 3, 2023 at 10:24:39 AM UTC-5 Thoma wrote: On Monday, July 3, 2023 at 10:57:02 AM UTC-4 Edward K. Ream wrote: I'm going to shorten *--always-write-session-data* to *--write-session*. Remember to change *-a* to *-w *(it's the kind of thing I would forget :-) ). The new name

Re: Debate: always save session data?

On Mon, Jul 3, 2023 at 8:32 AM Thomas Passin wrote: > I just tested the new code for *--always-write-session-data*, and it > worked as expected: > > 1. Open Leo and load several outlines; > 2. Close Leo and re-open with *.leo\workbook.leo* on the command line; > 3. Close and re-open Leo without

Re: Debate: always save session data?

On Monday, July 3, 2023 at 6:34:16 AM UTC-5 Edward K. Ream wrote: > A command line is out of the question. ... > So we must choose *now* how Leo will work for *everyone.* It's time to resolve this question! It's funny how writing changes my mind. *Aha!* The only way to resolve this qu

Debate: always save session data?

We disagree about when to write *session data *(a list outlines). Some say, "Always." Others say, "Only if the command line had no outlines." I see no way to allow all Leonistas to make Leo work as they like. A command line is out of the question. My bright idea failed spectacularly :-)

Re: ENB: About session preferences

On Monday, July 3, 2023 at 5:34:42 AM UTC-5 Edward K. Ream wrote: > Drat. My scheme is in ruins. The only way to enable this plugin would be with a per-outline setting (@enabled-plugins). I'm stuck. My plan, for now: - Leo will always write session data. Sorry Thomas. - A new command-line

Re: ENB: About session preferences

On Monday, July 3, 2023 at 4:52:17 AM UTC-5 Edward K. Ream wrote: > I'll modify PR #3215 <https://github.com/leo-editor/leo-editor/pull/3215> so that Leo always writes session data. > Those who prefer otherwise can enable the modify_session plugin. Drat. My scheme is in ruins.

ENB: About session preferences

Thomas has convinced me not to change Leo's session-handling code significantly. I have closed #3417 and its related PR: Leo will retain its session-* commands and related documentation. However, Leonistas disagree about *when *to

Re: Discuss: Remove all session commands?

On Mon, Jul 3, 2023 at 12:28 AM Robert-Felix wrote: > I have not done the sessions related code yet, (i didnt even know what > they were 5 minutes ago) and I do not intend if i dont have to ! haha! In > fact, I intended to use the same system as in leointeg: It reopens the last > Leo files you

Re: Discuss: Remove all session commands?

On Sunday, July 2, 2023 at 5:37:28 PM UTC-5 Edward K. Ream wrote: #3417 <https://github.com/leo-editor/leo-editor/issues/3417> now has the title: Discourage all session commands. I'll create a PR that adds discouraging comments to docstrings and Leo's documentation. All the sessions co

Re: Discuss: Remove all session commands?

On Sun, Jul 2, 2023 at 4:24 PM Thomas Passin wrote: ...if the other commands are in there and working, might as well leave them > in. Except for the cost of maintaining and explaining those features. But I agree with you that the cost is small and it might prevent howls. > That wouldn't be

Re: Discuss: Remove all session commands?

On Sunday, July 2, 2023 at 12:22:57 PM UTC-5 Edward K. Ream wrote: >>Someone may be using [the session commands], someone who isn't following this discussion. > That's always a danger. The compromise: encourage Félix not to transliterate them :-) Imagine that the session commands

Re: Discuss: Remove all session commands?

On Sun, Jul 2, 2023 at 9:36 AM Thomas Passin wrote: But if the existing commands still work, why remove them? > Leo will be better off without them. Less to learn, less to document, less to maintain. Someone may be using them, someone who isn't following this discussion. > That's always a

Discuss: Remove all session commands?

Leo's now requires only two methods from leoSessions.py: *SM.save_snapshot* and *SM.load_snapshot*. These two methods read and write json data to *~/.leo/session.leo*. Issue #3409 suggests writing session data to Leo's global cache

Keeping Leo and leoJS in sync

I'm not concerned about keeping Leo and leoJS in sync. Why? Because *leoJS will track Leo but not the reverse*. Félix has already demonstrated admirable dedication to keeping leoJS in sync with Leo. I do not doubt that he will continue to do so. Otoh, it's not possible to keep up with

Re: Edward K. Ream, Could you record some of your daily workflow?

On Sun, Jul 2, 2023 at 8:16 AM HaveF HaveF wrote: > I got the idea from this post > . > Thanks. I'll take a look. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this

Re: Transliterate mypy into rust? Using ChatGPT??

On Sun, Jul 2, 2023 at 8:23 AM HaveF HaveF wrote: Base on the https://github.com/0xpayne/gpt-migrate > Thanks for the link. It will be worth watching their progress. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from

Please test the ekr-3181-mypy-links branch

This branch contains the code for PR #3215 . The first comment of this PR describes the changes in detail. The PR is nearly complete. Please test the new code and report any problems. There is plenty of time for changes and corrections. The

Re: Edward K. Ream, Could you record some of your daily workflow?

On Thu, Jun 29, 2023 at 6:35 AM HaveF HaveF wrote: For example, in doc Lesson 7: How to make complex changes to a code base > , > I > still don't understand how and where to set a

Re: Transliterate mypy into rust? Using ChatGPT??

On Friday, June 30, 2023 at 2:12:08 PM UTC-5 Edward K. Ream wrote: I've just asked this question <https://github.com/python/mypy/issues/15560> of the mypy devs. Alex helpfully suggested I used dmypy, the mypy daemon. Right now dmypy is acting like mypy's evil twin, but that's

Re: Transliterate mypy into rust? Using ChatGPT??

On Friday, June 30, 2023 at 2:12:08 PM UTC-5 Edward K. Ream wrote: I've just asked this question <https://github.com/python/mypy/issues/15560> of the mypy devs. Alex, the mypy dev, mentioned that mypy is already faster than regular python because of mypyc <https://github.com/my

Re: PR3215 UNL Not Found By CTRL-Click

On Sat, Jul 1, 2023 at 6:59 AM Thomas Passin wrote: > All right, let's put it on the back burner for after the next release. > I'll create a reminder issue for it. > Thanks, Thomas. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To

Re: PR3215 UNL Not Found By CTRL-Click

On Fri, Jun 30, 2023 at 9:08 PM Thomas Passin wrote: Just one thing ... when a CTRL-Click on a UNL navigates to its target, the > focused node in the tree, which is the correct one, is not always visible > in the window. In my test, I had to scroll the tree to find it. > I've spent about an

Re: how to get all the content of the body?

On Fri, Jun 30, 2023 at 9:17 PM Thomas Passin wrote: > I tested the script with the latest revision of the PR3215 branch that has > all the UNL/GNX changes. It still works, Glory Hallelujah! > :-) Keep on testing! Edward -- You received this message because you are subscribed to the Google

Re: PR3215 UNL Not Found By CTRL-Click

On Fri, Jun 30, 2023 at 9:08 PM Thomas Passin wrote: All right, after merging the latest rev, the outlines open correctly on > restart, and there is no message about the missing set-rep-dir.cmd file. I > went back and checked that problematic UNL and it still is handled > correctly. Thanks

Re: Transliterate mypy into rust? Using ChatGPT??

On Fri, Jun 30, 2023 at 6:52 PM Robert-Felix wrote: > Of course, You'd need gpt4 at least for that in my experience. Gpt3 was > good enough for demos and small chunks witouth anything tricky. > Or maybe gpt5? Edward -- You received this message because you are subscribed to the Google

Re: PR3215 UNL Not Found By CTRL-Click

> 1. After merging the new rev and re-launching Leo, the previously-open >> outlines were not opened, except for the workbook; >> 2. I got this (minor) message: not found: >> C:/Tom/git/leo-editor/leo/scripts/set-repo-dir.cmd >> > > I'm seeing something similar, repeatedly. I'm on it. > Rev

Re: PR3215 UNL Not Found By CTRL-Click

On Fri, Jun 30, 2023 at 4:19 PM Thomas Passin wrote: > It did fix it. > > But two more problems: > > 1. After merging the new rev and re-launching Leo, the previously-open > outlines were not opened, except for the workbook; > 2. I got this (minor) message: not found: >

Transliterate mypy into rust? Using ChatGPT??

I've just asked this question of the mypy devs. Any 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

Re: PR3215 UNL Not Found By CTRL-Click

On Fri, Jun 30, 2023 at 1:25 PM Thomas Passin wrote: > Testing the PR3215 branch, I stumbled onto this path-based UNL that Leo > cannot find using a CTRL-click in a different outline. I copied this UNL > right from the status bar: Thanks for your testing! I may have found and fixed this bug

Why is PR #3215 so large?

PR #3215 is indeed large and complicated. Here are the reasons why: 1. It had to be. Many files use unls, some in unexpected ways. 2. There was no reason to be overly fastidious. I knew PR #3215 would succeed. Adding other PRs would

Re: Edward K. Ream, Could you record some of your daily workflow?

On Thu, Jun 29, 2023 at 6:35 AM HaveF HaveF wrote: > Dear, Edward K. Ream, > > I believe your daily workflows is an invaluable asset, as well as > leo-editor. > > Even the doc and Leo files contain lots of information there, but there > are still > lack of your wo

Re: Heads up: The SessionManager class will go away

On Fri, Jun 30, 2023 at 10:54 AM jkn wrote: > FWIW I usually run Leo from a direct desktop shortcut - having different > command files to run with different command-line parameters is something > ... unusual. I only ever do it if I have had a crash and am trying to see > what is going on. Having

Re: Heads up: The SessionManager class will go away

On Fri, Jun 30, 2023 at 10:44 AM Thomas Passin wrote: I just cycled Leo several time with this morning's update to PR3215. My > workbook remains intact, and the other session outlines re-opened. (Not at > the first launch: only the workbook opened, not a surprise, I suppose). > Thanks for

Re: Status bar behavior, especially with PR 3215

On Friday, June 30, 2023 at 10:00:52 AM UTC-5 Edward K. Ream wrote: > How about changing the *Copy* item to *Copy All*. > Let's just get rid of both. Selecting the text and doing Ctrl-C works now and is good enough. Well, it doesn't look easy to get rid of these items. Let's just leav

Re: Status bar behavior, especially with PR 3215

On Mon, Jun 26, 2023 at 9:55 PM Thomas Passin wrote: > In the status bar, a right-click brings up a two-item context menu: *Select > All* and *Copy*. I have always found this a little confusing. ... > How about changing the *Copy* item to *Copy All*. Let's just get rid of both. Selecting

Re: Heads up: The SessionManager class will go away

On Fri, Jun 30, 2023 at 8:53 AM jkn wrote: The idea, n*ow fully realized* in PR #3215 > , is this: > > 1. On exit, Leo *always* saves a list of open outlines (automatic > session-snapshot-save). > 2. When you open Leo without specifying any

Re: Heads up: The SessionManager class will go away

On Fri, Jun 30, 2023 at 8:28 AM Thomas Passin wrote: >> I actually do use the equivalent of custom temporary sessions sometimes, but the way I do it is to use the command line. I usually keep a Leo window open all the time with maybe 5 or 6 outlines open (at a minimum, the workbook, my bookmarks

Re: Heads up: The SessionManager class will go away

On Friday, June 30, 2023 at 5:04:54 AM UTC-5 jkn wrote: titles like 'The SessionManager will go away' probably cause people to go "what?! Why?! When?!", which might not be what you want... Hehe. It was exactly what I wanted--to get everyone's attention. I'm particularly glad I got *your*

Re: Heads up: The SessionManager class will go away

On Friday, June 30, 2023 at 7:54:48 AM UTC-5 Thomas wrote: I think this is exactly what is wanted most of the time, especially if each of the session-loaded outlines gets navigated to the focus when Leo was last closed. The trouble with having the user build and specify the contents of

Re: Heads up: The SessionManager class will go away

On Fri, Jun 30, 2023 at 5:04 AM jkn wrote: > FWIW I can't really tell what #3408 will actually *do*. "Real Sessions" > sounds great, but what is written there is more about the coding. I would > like to better understand when the user experience will be at the end of > this. > The idea, n*ow

Re: Heads up: The SessionManager class will go away

On Fri, Jun 30, 2023 at 4:39 AM jkn wrote: > starting Leo via different sets of (for me) .sh files, for different > 'session sets of files' seems pretty cheesy in this day & age - sorry. > No worries. PR #3215 (the massive PR) now supports

Re: Heads up: The SessionManager class will go away

On Friday, June 30, 2023 at 2:45:17 AM UTC-5 Edward K. Ream wrote: But nothing in leoSessions.py gives Leo such [real] sessions. The SessionManager class and the session-* commands must go. Big sigh. It does not seem wise to the retire the SessionManager class as part of PR #3215 <ht

Re: Heads up: The SessionManager class will go away

On Friday, June 30, 2023 at 3:12:44 AM UTC-5 Edward K. Ream wrote: > Would #3408 <https://github.com/leo-editor/leo-editor/issues/3408> work for you? In effect, #3404 would do these commands automatically. If "fluid" sessions don't work for you the obvious workflow is to cre

Re: Heads up: The SessionManager class will go away

On Fri, Jun 30, 2023 at 2:55 AM jkn wrote: I routinely start Leo with a set of files (four or five), previously saved > via session-snapshot-load and session-snapshot-save. Unless I'm > misunderstanding you, loss of this feature would be a serious blow to my > leo productivity. > I see:

Re: Heads up: The SessionManager class will go away

On Thursday, June 29, 2023 at 5:06:37 PM UTC-5 Edward K. Ream wrote: The *session-** commands are absurd solutions to a non-existent problem. This class significantly complicates Leo's startup logic. The entire SessionManager class must go. Félix take note :-) The *session-** commands

Re: Heads Up - My Workbook Is Getting Destroyed

On Thu, Jun 29, 2023 at 4:41 PM Thomas Passin wrote: > Even though I dislike PRs that are very complicated and try to do too many > things, I have to agree in this case. > Thanks :-) Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To

Heads up: The SessionManager class will go away

Leo no longer supports --session-restore and --session-save. LM.scanOptions lists them as obsolete. But the *SessionManager* class still exists. *SM.load_session* is the culprit behind #3404 . It would be straightforward to fix this

Re: Heads Up - My Workbook Is Getting Destroyed

On Thursday, June 29, 2023 at 3:43:22 AM UTC-5 Edward K. Ream wrote: > See #3404 <https://github.com/leo-editor/leo-editor/issues/3404>. The first comment of the issue discusses the failure and how to fix it. > PR #3215 <https://github.com/leo-editor/leo-editor/pull/3215> may

Re: Heads Up - My Workbook Is Getting Destroyed

On Thursday, June 29, 2023 at 2:10:26 AM UTC-5 Edward K. Ream wrote: See #3404 <https://github.com/leo-editor/leo-editor/issues/3404>. The first comment of the issue discusses the failure and how to fix it. ... PR #3215 <https://github.com/leo-editor/leo-editor/pull/3215> may as

Re: Why does leo asks to restart when a .leo file modification is detected? (instead of asking to reload the file?)

44e1-b75f-76ce7ecb4bb0n%40googlegroups.com?utm_medium=email_source=footer> > . > -- - Edward K. Ream: edream...@gmail.com Leo Editor: https://leo-editor.github.io/leo-editor/ <http://leoeditor.com/> - -- You r

Re: Heads Up - My Workbook Is Getting Destroyed

On Tuesday, June 27, 2023 at 4:55:37 PM UTC-5 Thomas wrote: > I haven't filed an issue on this yet because I haven't got all the conditions nailed down. See #3404 . The first comment of the issue discusses the failure and how to fix it.

Re: Heads Up - My Workbook Is Getting Destroyed

On Wed, Jun 28, 2023 at 3:15 PM Thomas Passin wrote: one defensive code change to make is for Leo never to replace the workbook > - whether or not it can find it - without asking the user. On first use, > when the Leo user gets created, that wouldn't apply. Good idea. Edward -- You

Re: New Ultra-fast replacement for pylint/flake8

On Wednesday, June 28, 2023 at 9:17:50 AM UTC-5 tbp1...@gmail.com wrote: > Ruff ...is 100 times or more faster because it is written in Rust. Wow. ruff does the flake8 tests instantly. Here is the output of a script that checks leo/core and leo/commands

Re: Heads Up - My Workbook Is Getting Destroyed

On Wed, Jun 28, 2023 at 10:27 AM Thomas Passin wrote: > I've done more testing, and the pattern is definitely repeatable. If I > check out the ekr-3181-mypy-links branch, the first time I launch Leo > the workbook may not be affected but every time after that it is destroyed > and replaced by

Re: New Ultra-fast replacement for pylint/flake8

On Wed, Jun 28, 2023 at 9:17 AM Thomas Passin wrote: > Ruff is a new-ish linter program that > does the job of pylint or flake8 but is 100 times or more faster because it > is written in Rust. It might be worth looking at for Leo. Oh yeah! Edward -- You

Re: Discuss: option for short file names in unls?

On Tue, Jun 27, 2023 at 9:48 PM HaveF HaveF wrote: > I don't know the meaning of short url, is it just for easy look? > Yes. The new *@data unl-path-prefixes* setting resolves relative to absolute paths. As a result, shorter (relative) paths are likely to be more useful than long (absolute)

Re: how to get all the content of the body?

On Wed, Jun 28, 2023 at 8:09 AM HaveF HaveF wrote: > Super useful function! It works! You save my day, Thomas! Thanks, Thomas, for your help. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop

Re: PR #3215 is ready for review

On Wed, Jun 28, 2023 at 3:58 AM Edward K. Ream wrote: PR #3215 <https://github.com/leo-editor/leo-editor/pull/3215> creates > *optional* unls based on gnxs. > And now the PR is even more ready for review :-) Todays revs: - Add two new helpers: *g.findAnyUnl* and *g.isValidU

Re: PR #3215 is ready for review

On Wednesday, June 28, 2023 at 3:58:07 AM UTC-5 Edward K. Ream wrote: > PR #3215 <https://github.com/leo-editor/leo-editor/pull/3215> creates *optional* unls based on gnxs. I'll wait at least a week before merging this PR. There is plenty of time for comments and corrections. Edward

PR #3215 is ready for review

PR #3215 creates *optional* unls based on gnxs. I have been eating my own dog food for days without problems. Please test the *ekr-3181-mypy-links* branch and report any problems. *Settings* leoSettings.leo contains three new settings

Re: Discuss: option for short file names in unls?

On Tuesday, June 27, 2023 at 2:41:21 PM UTC-5 tbp1...@gmail.com wrote: > I have several immediate reactions: Thomas, I have no idea what you are afraid of. > This kind of proposal will create something new that is not a UNL and not a GNX. It's a UNL because *g.handleUNL* accepts it. It's a

Re: Discuss: option for short file names in unls?

On Tuesday, June 27, 2023 at 1:34:40 PM UTC-5 Edward K. Ream wrote: Yet another new setting, *@bool full-unl-paths = True* (with the legacy-compatible default), would choose between the long and short forms. ... This option must *not* affect what p.get_UNL returns. Hmm. gnx-based unls

Discuss: option for short file names in unls?

Legacy unls have always contained a full path name. For example: unl://C:/Users/Dev/ekr.leo#g.findUNL & helpers However, the proposed *@data unl_path_prefixes* setting would render long/absolute paths unnecessary, so using the following should work: unl://ekr.leo#g.findUNL & helpers Yet

ENB: Unbreakable UNLs: a status report

This Engineering Notebook post discusses PR #3215 , especially Thomas's valid concerns about compatibility. Despite mistakes, work is going well. Our collaboration has been a great success. Consider this post an update to the PR's

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 10:44 PM Thomas Passin wrote: In the zettelkasten app, using the new p.get_legacy_UNL() doesn't work > right. I *think* it's because I had to change the ">" to "%3E" to get QT > to pass it to my code when I click on these links (these paths appear in an > anchor

Re: About PR #3215: unbreakable unls!

On Monday, June 26, 2023 at 1:50:28 PM UTC-5 tbp1...@gmail.com wrote: > Furthermore, having the path visible in the status bar could be really useful. Let's not argue about preferences. I've just added this checklist item to the PR: Add a setting that determines whether the status area will

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 2:01 PM Thomas Passin wrote: Something close to seven plugins use unls, including mod-http and > quickMove. They should all be checked to see if they will still work. Good idea. I've added this item to the PRs list. Edward -- You received this message because you

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 1:50 PM Thomas Passin wrote: Yes, since the UNL contained the path to the outline, Leo could open a > non-open outline and navigate to the right node. I always thought that was > a wonderful, even almost miraculous, capability. We shouldn't lose it. > I've just added

Re: leojs alpha

On Mon, Jun 26, 2023 at 2:38 PM jkn wrote: I agree with Thomas that maintaining two codebases in sync is probably and > impossible job in practice. I'm not worried. Leo on the desktop is complete as it is. I trust Félix to bring the Leonine world to vs-code. Edward -- You received this

Re: Code Review, Requirements, and Community Particiation

On Mon, Jun 26, 2023 at 2:34 PM Thomas Passin wrote: If we had a proposed set of requirements for a change to fix a well-defined > problem, we probably wouldn't be in the fix we're in right now about this > PR. > We aren't in a fix. We just need to find the least disruptive way of transitioning

Re: Code Review, Requirements, and Community Particiation

On Mon, Jun 26, 2023 at 2:34 PM Thomas Passin wrote: > In the announcement about the proposed PR 3215 that massively affects > UNLs, @Edward wrote > > "I won't wait for a code review. The code involved is too tricky to > understand in an hour or five." > I'll retract this statement. There have

Re: Leo active file bug and how to get the content of unl

On Mon, Jun 26, 2023 at 12:57 PM Thomas Passin wrote: Oh ye of little faith. In the PR the call to g.app.selectLeoWindow appears > in both g.findUNL and g.findGNX. So these calls have already been done when > g.handleUnl returns. > > > That's not the point. This bit of code returns the focus to

Re: Leo active file bug and how to get the content of unl

On Mon, Jun 26, 2023 at 12:56 PM Thomas Passin wrote: 1.I was probably thinking that g.findUNL (the legacy unl-finding function) might return a position in another outline. To my knowledge, that has never been true. > > Yes it has. Here's the docstring from the (unreplaced) g.findUNL: > >

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 12:50 PM Thomas Passin wrote: 1. CTRL-clicking on an old-style unl pointing into the same outline > navigates to the right node; for a unl pointing into a different outline it > does not navigate to the right place or even the right outline. > Thanks for testing. We'll

Re: Leo active file bug and how to get the content of unl

On Sun, Jun 25, 2023 at 10:22 AM Thomas Passin wrote: > Great! And if you want to do the same for a UNL in another outline, you can add these two lines (at least until that PR gets merged; I don't know about after that): # Add this after the "content =" line. if c2 is not c0:

Re: Leo active file bug and how to get the content of unl

On Mon, Jun 26, 2023 at 12:32 PM Edward K. Ream wrote: > Oops! In the PR g.handleUNL returns None. I'll restore the legacy operation immediately. Done. g.handleUNL returns a commander or None, exactly as in devel. Edward -- You received this message because you are subscribed to the Goo

Re: Leo active file bug and how to get the content of unl

On Sun, Jun 25, 2023 at 8:05 AM Thomas Passin wrote: > Assuming that these commands will continue to work after the PR: c0, p0 = c, c.p c2 = g.handleUnl(unl, c) Oops! In the PR g.handleUNL returns None. I'll restore the legacy operation immediately. Edward -- You received this message

Re: Leo active file bug and how to get the content of unl

On Sun, Jun 25, 2023 at 7:51 AM Thomas Passin wrote: > "Remove support for cross-file UNLs" - WTF??? This will break some of my > scripts. How are we going to navigate to other outlines by UNL? Wasn't > that half of the point of having UNLs in the first place? This conversation is likely

Re: About PR #3215: unbreakable unls!

On Monday, June 26, 2023 at 10:02:40 AM UTC-5 Edward K. Ream wrote: > I'll add p.get_legacy_UNL and p.get_short_legacy_UNL. > I'll add expanded searching to g.findUNL, just as in g.findGNX. Both done. *Notes* 1. *Warning*: Plugins that call g.findUNL directly must *not *

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 9:21 AM Thomas Passin wrote: The bookmark manager needs to 1) flatten the paths of nested nodes (to > provide labels like "software/python/frameworks") and 2) make each step of > those flattened labels clickable so that a user can navigate to their > node. Gnxs can't

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