Re: I am going to start using PR's

[Thomas Passin]

I'm not crazy about bureaucracy, but  I have noticed that the PR can lead 
to a lot of good discussion, and what gets added in the end may not be 
exactly what was in the PR at the start.

On Friday, August 21, 2020 at 8:55:30 PM UTC-4, Offray Vladimir Luna 
Cárdenas wrote:
>
> Lunzer,
>
> I may share the Fossil comments, as I'm an avid user of it. Paraphrasing 
> Conway's Law[1] culture and infrastructure reflect each other and I think 
> that Git reflect the bureaucracy of Linux Kernel development with its fork 
> and PR by default, while Fossil considers a small group of developers who 
> mostly know each other [2] and has a more lean/agile approach.
>
> [1] https://en.wikipedia.org/wiki/Conway%27s_law
> [2] https://fossil-scm.org/fossil/doc/bsd-vs-gpl/www/fossil-v-git.wiki
>
> I program mostly solo projects and when I hopefully I will pass to 
> projects with few well trusted developers. Seeing from the quality of 
> SQLite and Linux, PR's presence or absence are not a warranty over code 
> quality, but for sure PRs are sign of the believe in quality through 
> bureaucracy and self-restrain. Of course commit message as XKCD are pretty 
> useless (and funny ;-)), but in my case they (+diff) have been working kind 
> of well. I have seen similar behavior on non solo projects like Fossil and 
> SQLite.
>
> But I'm not an active Leo code contributor. So I was just giving my 
> opinion but in the end, core contributors should choose what works best for 
> the developers.
>
> Cheers,
>
> Offray
>
>
> On 21/08/20 3:01 p. m., lun...@gmail.com wrote:
>
> @offay, I've seen similar comments on the Fossil forums. 
>
> I don't have faith in developers to write "good commit messages". You need 
> only see this comic to understand my feelings:  https://xkcd.com/1296/ . 
> Developers (in general) are lazy, and this is not entirely caused by 
> "laziness", but these days more often due to lack of established best 
> practices and lack of time. Developers will perform the least amount of 
> steps to get code into production. PRs, while being bureaucratic, put a 
> hard stop in front of developers which forces them to think much harder 
> about their proposed changes and how they will be used and perceived by 
> others. While this slows down development, even in small teams, it is a net 
> win for code quality.
>
> My biggest complaint with PRs with git is that the PRs and not wholly 
> encapsulated within the repo. This is bad for privacy, bad for custody, and 
> bad for archivability. But better documentation and more deliberate 
> contributions are worth these trade-offs, if a better system comes around 
> I'm always interested.
>
> On Friday, August 21, 2020 at 2:14:02 PM UTC-4 off...@riseup.net wrote:
>
>>
>> On 17/08/20 11:28 a. m., Edward K. Ream wrote: 
>> > The days of cowboy commits are coming to an end. 
>> > 
>> > In future, I plan to create a PR for all my work. A PR is a good 
>> > record of what has been done, and it should help prevent unwanted 
>> > merge conflicts. 
>> > 
>> > I think separate PR's for all work makes sense for all of Leo's devs. 
>> > What do you think? 
>> > 
>> I dislike them. I think they introduce an unnecessary bureaucracy in 
>> most projects with small/solo developers and that good commit messages + 
>> actual diffs can be good enough for most project as commit 
>> documentation. But of course, each project and its developer community 
>> have different styles and ways to work together. 
>>
>> Cheers, 
>>
>> Offray 
>>
>> -- 
> 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-e...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/leo-editor/e3fcfb9e-c9fc-4795-a8bc-a59add33207fn%40googlegroups.com
>  
> 
> .
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3f6a7eec-a36c-4878-8941-091005991033o%40googlegroups.com.

Re: Unbinding Keys

[Thomas Passin]

My keyboard, which is fairly new, doesn't emit , which is 
very annoying.  I have to use the menu to get the command.  Maybe you have 
a keyboard issue?

On Friday, August 21, 2020 at 8:42:16 PM UTC-4, k-hen wrote:
>
> It's very boring so far, just getting started :-)
>
> The biggest helper for now are the paste-node and paste-node-as-clone 
> which don't seem to be working for me, 
> and Ctrl+n doesn't seem to unbind either, i.e. after setting to None.
>
> I've check-bindings and they seem like they're free.
>
> The others seem to work fine though. 
> For now these are all globally scope but I could see wanting to be more 
> granular.
>
> Thanks very much for your help.
>
> Kevin
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/646be3c2-5de1-4eba-89a0-b9d85ea3e2f1o%40googlegroups.com.

Re: I am going to start using PR's

[Offray Vladimir Luna Cárdenas]

Lunzer,

I may share the Fossil comments, as I'm an avid user of it. Paraphrasing
Conway's Law[1] culture and infrastructure reflect each other and I
think that Git reflect the bureaucracy of Linux Kernel development with
its fork and PR by default, while Fossil considers a small group of
developers who mostly know each other [2] and has a more lean/agile
approach.

[1] https://en.wikipedia.org/wiki/Conway%27s_law
[2] https://fossil-scm.org/fossil/doc/bsd-vs-gpl/www/fossil-v-git.wiki

I program mostly solo projects and when I hopefully I will pass to
projects with few well trusted developers. Seeing from the quality of
SQLite and Linux, PR's presence or absence are not a warranty over code
quality, but for sure PRs are sign of the believe in quality through
bureaucracy and self-restrain. Of course commit message as XKCD are
pretty useless (and funny ;-)), but in my case they (+diff) have been
working kind of well. I have seen similar behavior on non solo projects
like Fossil and SQLite.

But I'm not an active Leo code contributor. So I was just giving my
opinion but in the end, core contributors should choose what works best
for the developers.

Cheers,

Offray


On 21/08/20 3:01 p. m., lun...@gmail.com wrote:
> @offay, I've seen similar comments on the Fossil forums.
>
> I don't have faith in developers to write "good commit messages". You
> need only see this comic to understand my feelings: 
> https://xkcd.com/1296/ . Developers (in general) are lazy, and this is
> not entirely caused by "laziness", but these days more often due to
> lack of established best practices and lack of time. Developers will
> perform the least amount of steps to get code into production. PRs,
> while being bureaucratic, put a hard stop in front of developers which
> forces them to think much harder about their proposed changes and how
> they will be used and perceived by others. While this slows down
> development, even in small teams, it is a net win for code quality.
>
> My biggest complaint with PRs with git is that the PRs and not wholly
> encapsulated within the repo. This is bad for privacy, bad for
> custody, and bad for archivability. But better documentation and more
> deliberate contributions are worth these trade-offs, if a better
> system comes around I'm always interested.
>
> On Friday, August 21, 2020 at 2:14:02 PM UTC-4 off...@riseup.net wrote:
>
>
> On 17/08/20 11:28 a. m., Edward K. Ream wrote:
> > The days of cowboy commits are coming to an end.
> >
> > In future, I plan to create a PR for all my work. A PR is a good
> > record of what has been done, and it should help prevent unwanted
> > merge conflicts.
> >
> > I think separate PR's for all work makes sense for all of Leo's
> devs.
> > What do you think?
> >
> I dislike them. I think they introduce an unnecessary bureaucracy in
> most projects with small/solo developers and that good commit
> messages +
> actual diffs can be good enough for most project as commit
> documentation. But of course, each project and its developer
> community
> have different styles and ways to work together.
>
> Cheers,
>
> Offray
>
> -- 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/e3fcfb9e-c9fc-4795-a8bc-a59add33207fn%40googlegroups.com
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/eaac3f26-9fba-b964-de46-181dc772233c%40riseup.net.

Re: Unbinding Keys

[k-hen]

It's very boring so far, just getting started :-)

The biggest helper for now are the paste-node and paste-node-as-clone which 
don't seem to be working for me, 
and Ctrl+n doesn't seem to unbind either, i.e. after setting to None.

I've check-bindings and they seem like they're free.

The others seem to work fine though. 
For now these are all globally scope but I could see wanting to be more 
granular.

Thanks very much for your help.

Kevin


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/992042b4-14ed-4ba5-8a2b-07a72c481330n%40googlegroups.com.


http://leoeditor.com/namespaces/leo-python-editor/1.1; >





Settings README
@settings
fonts
@string font-family = Fira Code
@string font-size = 10pt 

@enabled-plugins
@keys
@shortcuts

Misc
@string central-dock-widget = body
@bool use-vr-dock = True


zz_archive
XX @bool create-at-persistence-nodes-automatically = True



myLeoSettings.leo personal settings file created Sat Apr  4 11:42:48 2020

Only nodes that are descendants of the @settings node are read.

Only settings you need to modify should be in this file, do
not copy large parts of leoSettings.py here.

For more information see http://leoeditor.com/customizing.html

# Leo loads plugins in the order they appear here.

# This node *MUST* be a child of the @settings node to take effect.

# **Important**: to change these defaults, put
# an @enabled-plugins node in myLeoSettings.leo.

# Highly-recommended plugins:

plugins_menu.py
free_layout.py
# Now loaded automatically.
# But it's useful to have a free_layout menu in the Plugins menu.

# Recommended plugins:

contextmenu.py
# This is required by the vim.py and xemacs.py plugins.

leo_to_html.py
mod_scripting.py
nav_qt.py
nodetags.py
quicksearch.py
screen_capture.py
settings_finder.py
stickynotes.py
todo.py
# viewrendered.py

viewrendered3.py



# Alphabetical list of all Leo plugins.

# Note: This list may be out of date. leo/plugins contains all official plugins.
# Note: Leo loads all qt_*.py files automatically when the qt gui is in effect.

# active_path.py
# add_directives.py
# at_folder.py
# at_produce.py
# at_view.py
# attrib_edit.py
# backlink.py
# bibtex.py
# bigdash.py
# bookmarks.py
# bzr_qcommands.py
# chapter_hoist.py
# colorize_headlines.py
# contextmenu.py
# ctagscompleter.py
# cursesGui.py
# datenodes.py
# debugger_pudb.py
# dragdropgoodies.py
# dtest.py
# dump_globals.py
# empty_leo_file.py
# enable_gc.py
# expfolder.py
# FileActions.py
# free_layout.py
# loaded automatically
# ftp.py
# geotag.py
# gitarchive.py
# graphcanvas.py
# import_cisco_config.py
# initinclass.py
# interact.py
# jinjarender.py
# leo_interface.py
# leo_pdf.py
# leo_to_html.py
# leo_to_rtf.py
# leocursor.py
# leofeeds.py
# leomail.py
# leomylyn.py
# leoOPML.py
# leoremote.py
# leoscreen.py
# lineNumbers.py
# livecode.py
# macros.py
# markup_inline.py
# maximizeNewWindows.py
# mime.py
# mnplugins.py
# mod_autosave.py
# mod_framesize.py
# mod_http.py
# mod_leo2ascd.py
# mod_read_dir_outline.py
# mod_scripting.py
# mod_speedups.py
# mod_tempfname.py
# mod_timestamp.py
# multifile.py
# nav_qt.py
# nested_splitter.py

# loaded automatically.
# niceNosent.py
# nodeActions.py
# nodediff.py
# nodetags.py
# nodewatch.py
# notebook.py
# open_shell.py
# outline_export.py
# paste_as_headlines.py
# plugins_menu.py
# pretty_print.py
# projectwizard.py
# python_terminal.py
# QNCalendarWidget.py
# qt_quicksearch.py
# quickMove.py
# quicksearch.py
# quit_leo.py
# read_only_nodes.py
# redirect_to_log.py
# richtext.py
# rss.py
# rst3.py
# run_nodes.py
# screen_capture.py
# screencast.py
# screenshots.py
# script_io_to_body.py
# scripts_menu.py
# setHomeDirectory.py
# settings_finder.py
# sftp.py
# slideshow.py
# spydershell.py
# startfile.py
# stickynotes.py
# stickynotes_plus.py
# systray.py
# testRegisterCommand.py
# textnode.py
# todo.py
# tomboy_import.py  
# trace_gc_plugin.py
# trace_keys.py
# trace_tags.py
# valuespace.py
# viewrendered.py
# viewrendered2.py
# vim.py
# wikiview.py
# word_count.py
# word_export.py
# xemacs.py
# xml_edit.py
# xsltWithNodes.py
# zenity_file_dialogs.py


# You can define keyboard shortcuts here of the form:
#
#some-command Shift-F5

# Navigation


# original defaults
# extract-names:  Ctrl+Shift+n
# new:Ctrl+n
# toggle-active-pane: Ctrl+y


# unbind
extract-names = None
new = None
toggle-active-pane = None


# outline operations

insert-node = Ctrl+Shift+n  # insert
insert-child= Ctrl+Shift+m  # child

move-outline-up = Ctrl+Shift+i  # up
move-outline-down   = Ctrl+Shift+  # down
move-outline-left   = Ctrl+Shift+h  # left
move-outline-right  = Ctrl+Shift+l  # right

Re: ViewRendered 3 Now Renders Asciidoc (with limitations)

[Thomas Passin]

I've moved this work to a new branch on my repo - the vr3-asciidoc branch.  
It's at 

https://github.com/tbpassin/leo-editor/tree/vr3-asciidoc

Please get vr3 from there if you want to try the latest efforts.

On Thursday, August 20, 2020 at 6:34:14 PM UTC-4, Thomas Passin wrote:
>
> I have been upgrading vr3 to render asciidoc nodes, mostly because of 
> Kevin's interest.  The work is not finished, but at least vr3 will render a 
> single node of asciidoc. Because it is still in progress I haven't issued a 
> PR.  But you can get it from my github repo -
>
> https://github.com/tbpassin/leo-editor
>
> The new version is in the devel branch.  It is version v3.0b10.
>
> To render asciidoc, you need to have an asciidoc processor installed, and 
> the two that should work are asciidoc (from 
> https://asciidoc.org/index.html, and sometimes available as an 
> installable package on Linux), and asciidoc3 (from pypi)  I haven't been 
> able to get asciidoc3 to work on my Windows machine, so I recommend the 
> former.
>
> The asciidoc processor needs to be available on the system path so that 
> vr3 can find its executable file (which could be a batch file launcher).  
> For asciidoc, which does not install into Python's site-packages, you can 
> create a new Leo setting to point to the asciidoc directory -
>
> @string vr3-asciidoc-path = 
>
> Vr3 will run asciidoc if it finds it, otherwise it will try for 
> asciidoc3.  More information is in the Help section 
> (Plugins/viewrendered3/about in the Leo menus).
>
> Please report any serious problems here.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/16d148d9-8eae-446c-b392-42ca790ac607o%40googlegroups.com.

Re: Documented Database Use Case

[Thomas Passin]

For those familiar with mysql, the following line in the launcher batch 
file will also work. You don't have to put the password into the batch file 
(a good thing), but you will have to type the password on the console every 
time you run it (could get tedious) -

@mysql -u root -p <"%1"

I used the expanded form in the example outline because it shows more 
clearly what the elements of the command are.

On Friday, August 21, 2020 at 3:03:16 PM UTC-4, Thomas Passin wrote:
>
> If you are willing to use a command line interface to your database, like 
> mysql.exe, then it can pretty easy.  You put your sql into a txt file, and 
> launch it with a batch file.  You can create a menu item to run the 
> launcher in a new "Open With" menu item by adding a new setting in your 
> @settings tree, either in your outline or in MyLeoSettings.leo.  The menu 
> item can be connected to a hot key - in the attached example, I use 
> .
> [snip]
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e1f9faec-a4db-4e1f-a8a8-ef3317519900o%40googlegroups.com.

Re: I am going to start using PR's

[Edward K. Ream]

On Fri, Aug 21, 2020 at 3:01 PM lun...@gmail.com  wrote:

> @offay, I've seen similar comments on the Fossil forums.
>
> I don't have faith in developers to write "good commit messages".
>

Imo, commit messages usually only need to be a readable tag. There are
exceptions, but they are few.

Let's try using PR's for a while. We can always go back to the wild west if
we want :-)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1%2B%2B6qHn6G1p7Gu9c6LkeQ%3DMtv-Y2JYcNtru2P7_tzLJg%40mail.gmail.com.

Re: Leo Interrupt

[k-hen]

Very cool - sounds like something I'll be using soon then - thanks!

On Friday, August 21, 2020 at 3:16:06 PM UTC-4 vitalije wrote:

> leo-ver-serv will store all the history of Leo files in the sqlite3 
> database files named after the original Leo files, just with added 
> '.history'. If for example you edit workbook.leo file, leo-ver-serv will 
> store changes to workbook.leo.history in the same folder.
>
> Vitalije
>
> On Friday, August 21, 2020 at 8:53:29 PM UTC+2, k-hen wrote:
>>
>> Excellent, I'll check it out - thanks! - do you happen to know if that 
>> history_tracer works with the sqlite/db back-end?
>> Re: interrupt, that's great news too - in addition to just Leo functions, 
>> if/when I get database queries working, being able to cancel the command is 
>> a relatively critical use case there too :-)
>>
>> Kevin
>>
>>
>> On Friday, August 21, 2020 at 1:24:43 PM UTC-4 vitalije wrote:
>>
>>>
>>>
>>> On Friday, August 21, 2020 at 4:14:43 PM UTC+2, k-hen wrote:

 Yes, absolutely, I'm a huge proponent of Git and it's toolchain :-)
 That said I want my personal comments and notes and settings *outside* 
 of git and not checked in as well. 
 So I need both regular backups/protection for Leo in _addition_ to the 
 Git repo which is synced with other devs.


>>> I am not sure this is relevant, but there is a history_tracer plug-in 
>>> which takes snapshots of your Leo files after each change. That is 
>>> something like making git commit after each edit. You need to have 
>>> leo-ver-serv program running and your Leo documents must be on the list of 
>>> files that leo-ver-serv should keep an eye on.
>>>
>>> By the way, I would also like that we could interrupt Leo without 
>>> killing it. On several occasions I missed that functionality. I've added 
>>> support for interrupting the execute-script command in Leo, and it wouldn't 
>>> be so hard to support many other commands. I don't have the time to do it 
>>> myself right now, but I guess it would be sufficient to add try/except 
>>> KeyboardInterrupt pair around some global method that executes commands. 
>>> This might not cover all commands, but it certainly would cover a lot of 
>>> them. Edward was recently refactoring key handling code and I believe there 
>>> is a method something like a main command handler there.
>>>
>>> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3da4ceb1-ce7b-46e3-b48b-18bb1d272d73n%40googlegroups.com.

Re: Documented Database Use Case

[k-hen]

Very cool, can't wait to check it out - thanks!

On Friday, August 21, 2020 at 3:03:16 PM UTC-4 tbp1...@gmail.com wrote:

> If you are willing to use a command line interface to your database, like 
> mysql.exe, then it can pretty easy.  You put your sql into a txt file, and 
> launch it with a batch file.  You can create a menu item to run the 
> launcher in a new "Open With" menu item by adding a new setting in your 
> @settings tree, either in your outline or in MyLeoSettings.leo.  The menu 
> item can be connected to a hot key - the attached example, I use 
> .
>
> The example in the attached Leo outline works on my system, except that I 
> use a fake password for the database and you won't have any tables like 
> mine in your database.  You will have to edit the details of launching your 
> database utility.  To use it, select the node for the sql file you want to 
> run, the use the hotkey or the File/Open With/run-sql menu item.
>
> If you change the menu definition iin your @settings, you will need to 
> close and restart Leo.  It's OK to change the launching cmd programs 
> without restarting.
>
> You can run any batch file with the other example in my outline, hot-keyed 
> to .  The example batch file just echoes a message to the 
> console.
>
> I suggest keeping the menu setting in your own outline until you get the 
> kinks worked out.  The you can copy it over to MeLeoSettings.leo.
>
> These are Windows command files, but changing to, say, bash scripts would 
> be easy enough.
>
> BTW, you can use the same method to add a launcher for your favorite 
> (non-Leo) editor.  Then you can open any Leo node (even if it's not an 
> external file node) in that editor.
>
> On Friday, August 21, 2020 at 12:15:30 PM UTC-4, k-hen wrote:
>>
>> Yes, that's true, and just to be clear, that's not what I'm suggesting 
>> or expecting :-) 
>>
>> What I want is to use Leo to build the *code* that 
>> constructs/populates/queries a separate 'proper' database. 
>>
>> One option is just to have Leo remain in Sqlite (and allow some basic 
>> querying that way), but *also* to define a connection in which to run 
>> various updates and queries through a global variable or something. For 
>> this I want Leo to supplement/replace a query studio. 
>>
>> Another option is to use agnostic ansi sql or a wrapper library 
>> (sqlalchemy has some support for this) to store the Leo node tables 
>> inside of another target db, thereby allowing joins and things between 
>> the Leo nodes and their non-Leo counterparts. 
>>
>> I can think of arguments for both based on different circumstances, but 
>> initially at least, my preference would probably be the former. 
>>
>>
>>
>>
>>
>> On Fri, 2020-08-21 at 08:21 -0700, Thomas Passin wrote: 
>> > I'm doubtful about Leo-as-a-database as a replacement for a 
>> > conventional rdbms, because of the need for atomic  transactions. 
>> > That has always take a lot of care in design and implementation of 
>> > the code.  Of course, we don't know what Speed has done, and maybe 
>> > you don't need such capabilities anyway... 
>> > 
>> > On Friday, August 21, 2020 at 10:59:07 AM UTC-4, k-hen wrote: 
>> > > Is there *anything* I can do to help entice him? 
>> > > 
>> > > Please Speed, please - if you're reading this, I'd *love* to see 
>> > > what you've done, 
>> > > it sounds incredible to me and it could really make a big 
>> > > difference to me to be able to use and build on your amazing work. 
>> > > 
>> > > I do a lot of database development and this could really, really 
>> > > help me out a whole lot. 
>> > > I'll take scraps/hello worlds/anything, I don't mind trying to pick 
>> > > through it, it doesn't need to be a fancy write-up or anything 
>> > > either. 
>> > > I could see myself using and building and growing it every single 
>> > > day :-) 
>> > > 
>> > > Thanks so much for considering, hope all is well. 
>> > > 
>> > > Yours Sincerely, 
>> > > Kevin   
>> > > 
>> > > :-) 
>> > > 
>> > > 
>> > > 
>> > > On Friday, August 14, 2020 at 11:03:25 AM UTC-4 k-hen wrote: 
>> > > > I'd be *very* interested in that, thank you!  :-D 
>> > > > 
>> > > > 
>> > > > On Fri, 2020-08-14 at 06:55 -0500, Edward K. Ream wrote: 
>> > > > > On Thu, Aug 13, 2020 at 9:37 AM k-hen  
>> > > > > wrote: 
>> > > > > 
>> > > > > > Is there a concept of Leo-as-database? 
>> > > > > 
>> > > > > Yes, and probably in several forms. 
>> > > > > 
>> > > > > My brother Speed has created something he calls Leopard: Leo 
>> > > > > (something) response demon. Don't know exactly how it works. 
>> > > > > For years I've been asking him to describe it here, but he 
>> > > > > seems to have other priorities. As he describes it, the Leo 
>> > > > > outline is the db, including queries. 
>> > > > > 
>> > > > > I'll ask him again to tell us more. 
>> > > > > 
>> > > > > Edward 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop 

Re: I am going to start using PR's

[lun...@gmail.com]

@offay, I've seen similar comments on the Fossil forums.

I don't have faith in developers to write "good commit messages". You need 
only see this comic to understand my feelings:  https://xkcd.com/1296/ . 
Developers (in general) are lazy, and this is not entirely caused by 
"laziness", but these days more often due to lack of established best 
practices and lack of time. Developers will perform the least amount of 
steps to get code into production. PRs, while being bureaucratic, put a 
hard stop in front of developers which forces them to think much harder 
about their proposed changes and how they will be used and perceived by 
others. While this slows down development, even in small teams, it is a net 
win for code quality.

My biggest complaint with PRs with git is that the PRs and not wholly 
encapsulated within the repo. This is bad for privacy, bad for custody, and 
bad for archivability. But better documentation and more deliberate 
contributions are worth these trade-offs, if a better system comes around 
I'm always interested.

On Friday, August 21, 2020 at 2:14:02 PM UTC-4 off...@riseup.net wrote:

>
> On 17/08/20 11:28 a. m., Edward K. Ream wrote:
> > The days of cowboy commits are coming to an end.
> >
> > In future, I plan to create a PR for all my work. A PR is a good
> > record of what has been done, and it should help prevent unwanted
> > merge conflicts.
> >
> > I think separate PR's for all work makes sense for all of Leo's devs.
> > What do you think?
> >
> I dislike them. I think they introduce an unnecessary bureaucracy in
> most projects with small/solo developers and that good commit messages +
> actual diffs can be good enough for most project as commit
> documentation. But of course, each project and its developer community
> have different styles and ways to work together.
>
> Cheers,
>
> Offray
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e3fcfb9e-c9fc-4795-a8bc-a59add33207fn%40googlegroups.com.

Re: Leo Interrupt

[vitalije]

leo-ver-serv will store all the history of Leo files in the sqlite3 
database files named after the original Leo files, just with added 
'.history'. If for example you edit workbook.leo file, leo-ver-serv will 
store changes to workbook.leo.history in the same folder.

Vitalije

On Friday, August 21, 2020 at 8:53:29 PM UTC+2, k-hen wrote:
>
> Excellent, I'll check it out - thanks! - do you happen to know if that 
> history_tracer works with the sqlite/db back-end?
> Re: interrupt, that's great news too - in addition to just Leo functions, 
> if/when I get database queries working, being able to cancel the command is 
> a relatively critical use case there too :-)
>
> Kevin
>
>
> On Friday, August 21, 2020 at 1:24:43 PM UTC-4 vitalije wrote:
>
>>
>>
>> On Friday, August 21, 2020 at 4:14:43 PM UTC+2, k-hen wrote:
>>>
>>> Yes, absolutely, I'm a huge proponent of Git and it's toolchain :-)
>>> That said I want my personal comments and notes and settings *outside* 
>>> of git and not checked in as well. 
>>> So I need both regular backups/protection for Leo in _addition_ to the 
>>> Git repo which is synced with other devs.
>>>
>>>
>> I am not sure this is relevant, but there is a history_tracer plug-in 
>> which takes snapshots of your Leo files after each change. That is 
>> something like making git commit after each edit. You need to have 
>> leo-ver-serv program running and your Leo documents must be on the list of 
>> files that leo-ver-serv should keep an eye on.
>>
>> By the way, I would also like that we could interrupt Leo without killing 
>> it. On several occasions I missed that functionality. I've added support 
>> for interrupting the execute-script command in Leo, and it wouldn't be so 
>> hard to support many other commands. I don't have the time to do it myself 
>> right now, but I guess it would be sufficient to add try/except 
>> KeyboardInterrupt pair around some global method that executes commands. 
>> This might not cover all commands, but it certainly would cover a lot of 
>> them. Edward was recently refactoring key handling code and I believe there 
>> is a method something like a main command handler there.
>>
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/326dddfc-790f-4fa6-9a10-4f917ea88c1eo%40googlegroups.com.

Re: Documented Database Use Case

[Thomas Passin]

If you are willing to use a command line interface to your database, like 
mysql.exe, then it can pretty easy.  You put your sql into a txt file, and 
launch it with a batch file.  You can create a menu item to run the 
launcher in a new "Open With" menu item by adding a new setting in your 
@settings tree, either in your outline or in MyLeoSettings.leo.  The menu 
item can be connected to a hot key - the attached example, I use 
.

The example in the attached Leo outline works on my system, except that I 
use a fake password for the database and you won't have any tables like 
mine in your database.  You will have to edit the details of launching your 
database utility.  To use it, select the node for the sql file you want to 
run, the use the hotkey or the File/Open With/run-sql menu item.

If you change the menu definition iin your @settings, you will need to 
close and restart Leo.  It's OK to change the launching cmd programs 
without restarting.

You can run any batch file with the other example in my outline, hot-keyed 
to .  The example batch file just echoes a message to the 
console.

I suggest keeping the menu setting in your own outline until you get the 
kinks worked out.  The you can copy it over to MeLeoSettings.leo.

These are Windows command files, but changing to, say, bash scripts would 
be easy enough.

BTW, you can use the same method to add a launcher for your favorite 
(non-Leo) editor.  Then you can open any Leo node (even if it's not an 
external file node) in that editor.

On Friday, August 21, 2020 at 12:15:30 PM UTC-4, k-hen wrote:
>
> Yes, that's true, and just to be clear, that's not what I'm suggesting 
> or expecting :-) 
>
> What I want is to use Leo to build the *code* that 
> constructs/populates/queries a separate 'proper' database. 
>
> One option is just to have Leo remain in Sqlite (and allow some basic 
> querying that way), but *also* to define a connection in which to run 
> various updates and queries through a global variable or something. For 
> this I want Leo to supplement/replace a query studio. 
>
> Another option is to use agnostic ansi sql or a wrapper library 
> (sqlalchemy has some support for this) to store the Leo node tables 
> inside of another target db, thereby allowing joins and things between 
> the Leo nodes and their non-Leo counterparts. 
>
> I can think of arguments for both based on different circumstances, but 
> initially at least, my preference would probably be the former. 
>
>
>
>
>
> On Fri, 2020-08-21 at 08:21 -0700, Thomas Passin wrote: 
> > I'm doubtful about Leo-as-a-database as a replacement for a 
> > conventional rdbms, because of the need for atomic  transactions. 
> > That has always take a lot of care in design and implementation of 
> > the code.  Of course, we don't know what Speed has done, and maybe 
> > you don't need such capabilities anyway... 
> > 
> > On Friday, August 21, 2020 at 10:59:07 AM UTC-4, k-hen wrote: 
> > > Is there *anything* I can do to help entice him? 
> > > 
> > > Please Speed, please - if you're reading this, I'd *love* to see 
> > > what you've done, 
> > > it sounds incredible to me and it could really make a big 
> > > difference to me to be able to use and build on your amazing work. 
> > > 
> > > I do a lot of database development and this could really, really 
> > > help me out a whole lot. 
> > > I'll take scraps/hello worlds/anything, I don't mind trying to pick 
> > > through it, it doesn't need to be a fancy write-up or anything 
> > > either. 
> > > I could see myself using and building and growing it every single 
> > > day :-) 
> > > 
> > > Thanks so much for considering, hope all is well. 
> > > 
> > > Yours Sincerely, 
> > > Kevin   
> > > 
> > > :-) 
> > > 
> > > 
> > > 
> > > On Friday, August 14, 2020 at 11:03:25 AM UTC-4 k-hen wrote: 
> > > > I'd be *very* interested in that, thank you!  :-D 
> > > > 
> > > > 
> > > > On Fri, 2020-08-14 at 06:55 -0500, Edward K. Ream wrote: 
> > > > > On Thu, Aug 13, 2020 at 9:37 AM k-hen  
> > > > > wrote: 
> > > > > 
> > > > > > Is there a concept of Leo-as-database? 
> > > > > 
> > > > > Yes, and probably in several forms. 
> > > > > 
> > > > > My brother Speed has created something he calls Leopard: Leo 
> > > > > (something) response demon. Don't know exactly how it works. 
> > > > > For years I've been asking him to describe it here, but he 
> > > > > seems to have other priorities. As he describes it, the Leo 
> > > > > outline is the db, including queries. 
> > > > > 
> > > > > I'll ask him again to tell us more. 
> > > > > 
> > > > > 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8be28d25-4bcf-42bb-a5d3-53c315ada72fo%40googlegroups.com.


leo-db-test.leo

Re: Leo Interrupt

[k-hen]

Excellent, I'll check it out - thanks! - do you happen to know if that 
history_tracer works with the sqlite/db back-end?
Re: interrupt, that's great news too - in addition to just Leo functions, 
if/when I get database queries working, being able to cancel the command is 
a relatively critical use case there too :-)

Kevin


On Friday, August 21, 2020 at 1:24:43 PM UTC-4 vitalije wrote:

>
>
> On Friday, August 21, 2020 at 4:14:43 PM UTC+2, k-hen wrote:
>>
>> Yes, absolutely, I'm a huge proponent of Git and it's toolchain :-)
>> That said I want my personal comments and notes and settings *outside* of 
>> git and not checked in as well. 
>> So I need both regular backups/protection for Leo in _addition_ to the 
>> Git repo which is synced with other devs.
>>
>>
> I am not sure this is relevant, but there is a history_tracer plug-in 
> which takes snapshots of your Leo files after each change. That is 
> something like making git commit after each edit. You need to have 
> leo-ver-serv program running and your Leo documents must be on the list of 
> files that leo-ver-serv should keep an eye on.
>
> By the way, I would also like that we could interrupt Leo without killing 
> it. On several occasions I missed that functionality. I've added support 
> for interrupting the execute-script command in Leo, and it wouldn't be so 
> hard to support many other commands. I don't have the time to do it myself 
> right now, but I guess it would be sufficient to add try/except 
> KeyboardInterrupt pair around some global method that executes commands. 
> This might not cover all commands, but it certainly would cover a lot of 
> them. Edward was recently refactoring key handling code and I believe there 
> is a method something like a main command handler there.
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ae1acc03-bca8-4f80-a96d-b8d30c7e615dn%40googlegroups.com.

Re: Sentinel Naming Convention

[k-hen]

Intriguing ... can't wait!

On Friday, August 21, 2020 at 12:53:30 PM UTC-4 Edward K. Ream wrote:

> On Fri, Aug 21, 2020 at 9:38 AM k-hen  wrote:
>
> I know this issue has been put to bed and is extremely unlikely to happen, 
>> but just one more thing:
>> If I had a magic wand:
>>
>> I could add a decorator to *alias* a node's gnx, so the gnx could stay 
>> as-is, but I could give it an alternate/external name as well.
>>
>
> Let me encourage you to think about Leonine scripts and uA's 
> , 
> rather than extensions to Leo. The combination might blow your mind :-)
>
> You can probably do what you want now. You don't need my approval and you 
> won't have to wait for upgrades.  
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/33387216-d544-4e00-bc78-68397b589f37n%40googlegroups.com.

Re: I am going to start using PR's

[Offray Vladimir Luna Cárdenas]

On 17/08/20 11:28 a. m., Edward K. Ream wrote:
> The days of cowboy commits are coming to an end.
>
> In future, I plan to create a PR for all my work. A PR is a good
> record of what has been done, and it should help prevent unwanted
> merge conflicts.
>
> I think separate PR's for all work makes sense for all of Leo's devs.
> What do you think?
>
I dislike them. I think they introduce an unnecessary bureaucracy in
most projects with small/solo developers and that good commit messages +
actual diffs can be good enough for most project as commit
documentation. But of course, each project and its developer community
have different styles and ways to work together.

Cheers,

Offray

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/dec1fb4a-7767-1b01-2292-3bfecd521cbe%40riseup.net.

Re: Leo Write-Only Mode

[vitalije]

On Friday, August 21, 2020 at 4:08:35 PM UTC+2, k-hen wrote:
>
> Thank you for the import script and the responses.
>
> I feel like maybe I'm missing something with @nosent though, why is it 
> much harder to use? 
>
> Let's say I have a directory of files that are each templated, i.e. 
> possibly having a header and footer. 
> These files are checked into git and synchronized using @auto nodes and 
> can both be edited and read _into_ Leo when changes occur, e.g. after git 
> pulling.
> Then I can clone the body (inner section) of these nodes and write them 
> out somewhere else using an @nosent file.
> Never would I want a change to this output file to be read back _into_ Leo.
> This file is local only and would not be checked into git, it could be 
> deleted and would always be overwritten.
> As you know, Git prefers small files rather than large ones and this one 
> could be quite massive and treated as a 'large file' and therefore lose 
> certain functionality. 
>
> Sure a script could do this too, but it's a poor man's version of using 
> includes. 
>
>
>

You can try md_docer plug-in or write your own scripts using the code from 
md_docer as an inspiration.

In almost all my Leo documents now, the first thing I do is to add a node 
with the headline '@button nsave @key=Ctrl-s'. So, whenever I press Ctrl-s 
to save my Leo document, script in this node is executed. There is alwayas 
a 'c.save()' line in this script, so that the document is saved, but then 
my script writes all nodes that need to be written in some special way. For 
example, nodes whose headline starts with '@coffee ...', are compiled with 
the coffee compiler, '@pug' nodes are compiled with the pug compiler, @css 
nodes are compiled with sass compiler, ... The limit is just your 
imagination. You can easily write your nodes without sentinels and Leo 
won't try to read file and synchronize Leo. Actually I don't have coffee, 
scss, pug and other types of files that are considered to be source files. 
I have just compiled versions written as a real files.

HTH 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5131e5c1-413a-4acc-8802-08ee8e491f62o%40googlegroups.com.

Re: Leo Interrupt

[vitalije]

On Friday, August 21, 2020 at 4:14:43 PM UTC+2, k-hen wrote:
>
> Yes, absolutely, I'm a huge proponent of Git and it's toolchain :-)
> That said I want my personal comments and notes and settings *outside* of 
> git and not checked in as well. 
> So I need both regular backups/protection for Leo in _addition_ to the Git 
> repo which is synced with other devs.
>
>
I am not sure this is relevant, but there is a history_tracer plug-in which 
takes snapshots of your Leo files after each change. That is something like 
making git commit after each edit. You need to have leo-ver-serv program 
running and your Leo documents must be on the list of files that 
leo-ver-serv should keep an eye on.

By the way, I would also like that we could interrupt Leo without killing 
it. On several occasions I missed that functionality. I've added support 
for interrupting the execute-script command in Leo, and it wouldn't be so 
hard to support many other commands. I don't have the time to do it myself 
right now, but I guess it would be sufficient to add try/except 
KeyboardInterrupt pair around some global method that executes commands. 
This might not cover all commands, but it certainly would cover a lot of 
them. Edward was recently refactoring key handling code and I believe there 
is a method something like a main command handler there.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0cfc9392-f434-4da8-ab98-ed2f134c7900o%40googlegroups.com.

Re: Leo Write-Only Mode

[Edward K. Ream]

On Fri, Aug 21, 2020 at 9:08 AM k-hen  wrote:

I feel like maybe I'm missing something with @nosent though, why is it much
> harder to use?
>

Clones are fragile in @auto trees, even when @persistence is enabled.

Also, so-called cross-file clones can be problematic, due to a fairly nasty
version of the multiple update problem.

It sounds to me like a script-based solution might be best. You could, say,
populate some specially marked nodes (of your own choosing) with content.
Examples might be @header and @footer.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0nF85Sad3WPvLMGfEudn8QBQ5KdTt3XE5e3omY%3DLLs8w%40mail.gmail.com.

Re: Unbinding Keys

[Edward K. Ream]

On Fri, Aug 21, 2020 at 9:40 AM k-hen  wrote:

> Not to pester, but some of my shortcut keys still aren't working and
> having them could save me a tremendous amount if time.
> If there's anything you could point me to, I'd really appreciate it :-)
>

Please send me your myLeoSettings.leo file.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0x2XL%3D9mn2oASEJGmQQzi52W00tSDnfrQfk9A4cWP7%2Bw%40mail.gmail.com.

Re: Sentinel Naming Convention

[Edward K. Ream]

On Fri, Aug 21, 2020 at 9:38 AM k-hen  wrote:

I know this issue has been put to bed and is extremely unlikely to happen,
> but just one more thing:
> If I had a magic wand:
>
> I could add a decorator to *alias* a node's gnx, so the gnx could stay
> as-is, but I could give it an alternate/external name as well.
>

Let me encourage you to think about Leonine scripts and uA's
,
rather than extensions to Leo. The combination might blow your mind :-)

You can probably do what you want now. You don't need my approval and you
won't have to wait for upgrades.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0xPCrLbR_NAu-L6dTQHW29f2SapTWWCot5e8CWyTKNOg%40mail.gmail.com.

Re: Documented Database Use Case

[perceptiblelogic]

Yes, that's true, and just to be clear, that's not what I'm suggesting
or expecting :-)

What I want is to use Leo to build the *code* that
constructs/populates/queries a separate 'proper' database.

One option is just to have Leo remain in Sqlite (and allow some basic
querying that way), but *also* to define a connection in which to run
various updates and queries through a global variable or something. For
this I want Leo to supplement/replace a query studio.

Another option is to use agnostic ansi sql or a wrapper library
(sqlalchemy has some support for this) to store the Leo node tables
inside of another target db, thereby allowing joins and things between
the Leo nodes and their non-Leo counterparts.

I can think of arguments for both based on different circumstances, but
initially at least, my preference would probably be the former.





On Fri, 2020-08-21 at 08:21 -0700, Thomas Passin wrote:
> I'm doubtful about Leo-as-a-database as a replacement for a
> conventional rdbms, because of the need for atomic  transactions. 
> That has always take a lot of care in design and implementation of
> the code.  Of course, we don't know what Speed has done, and maybe
> you don't need such capabilities anyway...
> 
> On Friday, August 21, 2020 at 10:59:07 AM UTC-4, k-hen wrote:
> > Is there *anything* I can do to help entice him?
> > 
> > Please Speed, please - if you're reading this, I'd *love* to see
> > what you've done,
> > it sounds incredible to me and it could really make a big
> > difference to me to be able to use and build on your amazing work.
> > 
> > I do a lot of database development and this could really, really
> > help me out a whole lot.
> > I'll take scraps/hello worlds/anything, I don't mind trying to pick
> > through it, it doesn't need to be a fancy write-up or anything
> > either.
> > I could see myself using and building and growing it every single
> > day :-)
> > 
> > Thanks so much for considering, hope all is well.
> > 
> > Yours Sincerely,
> > Kevin  
> > 
> > :-)
> > 
> > 
> > 
> > On Friday, August 14, 2020 at 11:03:25 AM UTC-4 k-hen wrote:
> > > I'd be *very* interested in that, thank you!  :-D 
> > > 
> > > 
> > > On Fri, 2020-08-14 at 06:55 -0500, Edward K. Ream wrote:
> > > > On Thu, Aug 13, 2020 at 9:37 AM k-hen 
> > > > wrote:
> > > > 
> > > > > Is there a concept of Leo-as-database?
> > > > 
> > > > Yes, and probably in several forms.
> > > > 
> > > > My brother Speed has created something he calls Leopard: Leo
> > > > (something) response demon. Don't know exactly how it works.
> > > > For years I've been asking him to describe it here, but he
> > > > seems to have other priorities. As he describes it, the Leo
> > > > outline is the db, including queries. 
> > > > 
> > > > I'll ask him again to tell us more.
> > > > 
> > > > 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/eac181c4d302feafd68beca2a8727f406a7137d3.camel%40gmail.com.

Re: Documented Database Use Case

[Thomas Passin]

I'm doubtful about Leo-as-a-database as a replacement for a conventional 
rdbms, because of the need for atomic  transactions.  That has always take 
a lot of care in design and implementation of the code.  Of course, we 
don't know what Speed has done, and maybe you don't need such capabilities 
anyway...

On Friday, August 21, 2020 at 10:59:07 AM UTC-4, k-hen wrote:
>
> Is there *anything* I can do to help entice him?
>
> Please Speed, please - if you're reading this, I'd *love* to see what 
> you've done,
> it sounds incredible to me and it could really make a big difference to me 
> to be able to use and build on your amazing work.
>
> I do a lot of database development and this could really, really help me 
> out a whole lot.
> I'll take scraps/hello worlds/anything, I don't mind trying to pick 
> through it, it doesn't need to be a fancy write-up or anything either.
> I could see myself using and building and growing it every single day :-)
>
> Thanks so much for considering, hope all is well.
>
> Yours Sincerely,
> Kevin  
>
> :-)
>
>
>
> On Friday, August 14, 2020 at 11:03:25 AM UTC-4 k-hen wrote:
>
>> I'd be *very* interested in that, thank you!  :-D 
>>
>>
>> On Fri, 2020-08-14 at 06:55 -0500, Edward K. Ream wrote:
>>
>> On Thu, Aug 13, 2020 at 9:37 AM k-hen  wrote:
>>
>> > Is there a concept of Leo-as-database?
>>
>> Yes, and probably in several forms.
>>
>> My brother Speed has created something he calls Leopard: Leo (something) 
>> response demon. Don't know exactly how it works. For years I've been asking 
>> him to describe it here, but he seems to have other priorities. As he 
>> describes it, the Leo outline *is* the db, including queries. 
>>
>> I'll ask him again to tell us more.
>>
>> Edward
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "leo-editor" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/leo-editor/rPA65N-Ujhc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> leo-editor+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/CAMF8tS0OoBRm2CrLe7K%2Bo0AhsLD1YkkH5f9v4DJEcRuo%2Bs-ABw%40mail.gmail.com
>>  
>> 
>> .
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/605ddfdf-9408-45e8-964b-5dc04001c52do%40googlegroups.com.

Re: Documented Database Use Case

[k-hen]

Is there *anything* I can do to help entice him?

Please Speed, please - if you're reading this, I'd *love* to see what 
you've done,
it sounds incredible to me and it could really make a big difference to me 
to be able to use and build on your amazing work.

I do a lot of database development and this could really, really help me 
out a whole lot.
I'll take scraps/hello worlds/anything, I don't mind trying to pick through 
it, it doesn't need to be a fancy write-up or anything either.
I could see myself using and building and growing it every single day :-)

Thanks so much for considering, hope all is well.

Yours Sincerely,
Kevin  

:-)



On Friday, August 14, 2020 at 11:03:25 AM UTC-4 k-hen wrote:

> I'd be *very* interested in that, thank you!  :-D 
>
>
> On Fri, 2020-08-14 at 06:55 -0500, Edward K. Ream wrote:
>
> On Thu, Aug 13, 2020 at 9:37 AM k-hen  wrote:
>
> > Is there a concept of Leo-as-database?
>
> Yes, and probably in several forms.
>
> My brother Speed has created something he calls Leopard: Leo (something) 
> response demon. Don't know exactly how it works. For years I've been asking 
> him to describe it here, but he seems to have other priorities. As he 
> describes it, the Leo outline *is* the db, including queries. 
>
> I'll ask him again to tell us more.
>
> Edward
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "leo-editor" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/leo-editor/rPA65N-Ujhc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> leo-editor+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/leo-editor/CAMF8tS0OoBRm2CrLe7K%2Bo0AhsLD1YkkH5f9v4DJEcRuo%2Bs-ABw%40mail.gmail.com
>  
> 
> .
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/eb0bb9fd-fcb3-4f52-a12c-e245c95e040bn%40googlegroups.com.

Re: Unbinding Keys

[k-hen]

Not to pester, but some of my shortcut keys still aren't working and having 
them could save me a tremendous amount if time.
If there's anything you could point me to, I'd really appreciate it :-)

On Monday, August 17, 2020 at 5:31:33 PM UTC-4 k-hen wrote:

> Hi,
> I do see this issue: https://github.com/leo-editor/leo-editor/issues/327
> and it's marked as closed, but for some reason the keys aren't unbinding.
> My other shortcut assignments are working.
>
> e.g. 
> myLeoSettings/at-settings/at-keys/at-shortcuts
>
> new = None
> toggle-active-pane = None
>
> Am I doing something wrong?
>
> Thanks,
> Kevin
>
>
>
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/bd0438d5-5676-406a-a474-226327c2f0c0n%40googlegroups.com.

Re: Sentinel Naming Convention

[k-hen]

I know this issue has been put to bed and is extremely unlikely to happen, 
but just one more thing:
If I had a magic wand:

I could add a decorator to *alias* a node's gnx, so the gnx could stay 
as-is, but I could give it an alternate/external name as well.
So if/when the file write happens it would use the alias if there was one 
and the gnx if there wasn't, which could be easily coalesced and both 
globally unique.
Then I'd feel more comfortable, even encourage, scattering //  
throughout the code.
Also, any existing files using gnx would be unaffected.

Furthermore, I have Leo support universal file handlers so I those could be 
leo://fileref:urls which would open leo to the appropriate node from those 
comments.

Anyway, just thought I'd mention it, maybe someday I'll try to dive into 
this.


On Tuesday, August 18, 2020 at 8:26:54 PM UTC-4 k-hen wrote:

> Those are all valid points. In fairness, I think this could be a separate 
> _option_ without affecting existing documents but I see your point. 
> FWIW, in the database world it's generally best not to expose primary 
> keys, so you'd have both an internal id and a public one which would be 
> mapped.
> Alternatively, a few languages let you specify #region tags that work 
> specifically for folding so that could work too (someday).
>
> I understand this would be a major change to Leo though are that there are 
> higher priority things to do, just thought I'd mention it anyway for future 
> reference :-)
>
> Thanks.
>
> On Tuesday, August 18, 2020 at 8:35:39 AM UTC-4 Edward K. Ream wrote:
>
>> On Mon, Aug 17, 2020 at 6:29 PM  wrote:
>>
>> > maybe *someday* a GUID/UUID or a Hash of that gnx 
>>
>> Let me be clear. I would vote against this proposal, for the following 
>> reasons:
>>
>> 1. user-id + timestamp is useful information. Imo, a distinct user id, 
>> say the user's github id, is required to ensure unique gnx's. There has 
>> been a long, technical, discussion of this.
>>
>> 2. Any change to gnx format would amount to a change in supported 
>> external files. Any such change would make it impossible for old versions 
>> of Leo to read @file nodes. This is a big deal.
>>
>> In short, the supposed advantages, such as they are, do not come close to 
>> justifying a big change to Leo.
>>
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ab6c04ee-65b3-4004-a89a-7cca73daeee0n%40googlegroups.com.

Re: Leo Interrupt

[Edward K. Ream]

On Fri, Aug 21, 2020 at 9:14 AM k-hen  wrote:

> Yes, absolutely, I'm a huge proponent of Git and it's toolchain :-)
> That said I want my personal comments and notes and settings *outside* of
> git and not checked in as well.
> So I need both regular backups/protection for Leo in _addition_ to the Git
> repo which is synced with other devs.
>

I'm not sure what happened. However, Leo's perfect import checks are
strong. If they fail, the importers will add @ignore directives, preventing
accidental changes to your files.

I should add that Leo's importers are the foundation for both @auto and
@clean, as well as c.recursiveImport.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS01P%3DB4mvdUNFBJ8wsFH2ZJ1ak%3DhxBDHBiNA2kp4mzMzQ%40mail.gmail.com.

Re: ViewRendered 3 Now Renders Asciidoc (with limitations)

[k-hen]

This is so awesome - thank you!  :-D


On Thursday, August 20, 2020 at 7:06:39 PM UTC-4 Edward K. Ream wrote:

> On Thu, Aug 20, 2020 at 5:34 PM Thomas Passin  wrote:
>
>> I have been upgrading vr3 to render asciidoc nodes, mostly because of 
>> Kevin's interest.  The work is not finished, but at least vr3 will render a 
>> single node of asciidoc. Because it is still in progress I haven't issued a 
>> PR.  But you can get it from my github repo -
>>
>> https://github.com/tbpassin/leo-editor
>>
>> The new version is in the devel branch.  It is version v3.0b10.
>>
>
> Thanks for this work!
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/851dca94-41d1-45ee-846f-8c160a5439c1n%40googlegroups.com.

Re: Leo Interrupt

[k-hen]

Yes, absolutely, I'm a huge proponent of Git and it's toolchain :-)
That said I want my personal comments and notes and settings *outside* of 
git and not checked in as well. 
So I need both regular backups/protection for Leo in _addition_ to the Git 
repo which is synced with other devs.


On Thursday, August 20, 2020 at 7:00:05 PM UTC-4 Edward K. Ream wrote:

> On Thu, Aug 20, 2020 at 1:06 PM k-hen  wrote:
>
>> Hi,
>> Just wondering - Is there perhaps a way to interrupt Leo without fully 
>> killing it?
>>
>
> There isn't, and it's not likely ever to happen.
>
> In general, you want a work flow that is impervious to killing Leo from 
> the console. Using git to protect valuable original sources is what I 
> recommend.  `git checkout .` will undo any horrors :-)
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/96f70747-3886-4207-9dfd-8daf5d370c75n%40googlegroups.com.

Re: Leo Write-Only Mode

[k-hen]

Thank you for the import script and the responses.

I feel like maybe I'm missing something with @nosent though, why is it much 
harder to use? 

Let's say I have a directory of files that are each templated, i.e. 
possibly having a header and footer. 
These files are checked into git and synchronized using @auto nodes and can 
both be edited and read _into_ Leo when changes occur, e.g. after git 
pulling.
Then I can clone the body (inner section) of these nodes and write them out 
somewhere else using an @nosent file.
Never would I want a change to this output file to be read back _into_ Leo.
This file is local only and would not be checked into git, it could be 
deleted and would always be overwritten.
As you know, Git prefers small files rather than large ones and this one 
could be quite massive and treated as a 'large file' and therefore lose 
certain functionality. 

Sure a script could do this too, but it's a poor man's version of using 
includes. 

Another issue I have is that this file is going to be quite _deep_ and 
html/markdown/asciidoc all have a maximum of 0+5 levels of section depth,
so when *every* level of nodes writes as a section to the file then it 
breaks the output, 
so I need to be able to treat some nodes as sections and some as just body 
content.

I've also decided that I can write my comments to file comments, so that 
Leo can write the whole subtree, even if i don't want to publish all of it.
This large output file is only a temporary step because it would be 
transmuted before distribution and so asciidoc would exclude those comments.


Kevin




On Thursday, August 20, 2020 at 6:54:51 PM UTC-4 Edward K. Ream wrote:

> On Thu, Aug 20, 2020 at 4:50 PM k-hen  wrote:
>
>> I'm feeling pretty stupid right now, I think this is what @asis & @nosent 
>> are for and I just missed it - even though I was staring right at it.
>>
>
> No need for apologies! There is a lot to digest for newbies.
>
>> I've heard comments to avoid these and they're flagged as not 
>> 'recommended' and so was just dismissing them without consideration.
>> I'm not sure if there are particular reasons *why* they're not 
>> recommended but I'll go ahead and give them a shot.
>>
>
> I don't recommend @nosent or @asis because they are much harder to use 
> than @file, @clean and @auto. Leo's automagic reloading of @clean files is 
> what you want if you can't tolerate Leo's sentinels. If you *can* 
> tolerate Leo's sentinels, then @file is bullet-proof.
>
> I know from first-hand experience that getting @clean nodes to be as one 
> wants can take significant work when Leo's importers are up to snuff. I've 
> recently beefed up the C (C++) and typescript importers because importing 
> to @clean wasn't as easy as I would have wanted.
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3bf3fdc1-de5c-4728-82b6-246d86765094n%40googlegroups.com.

Re: PR's now required for the master and devel branches

[Thomas Passin]

And after I said this is a good idea, I just accidentally merged my changes 
to VR3 to upstream/devel instead of origin/devel.  Grrr.  No harm done, I 
think, because these changes were the ones that start to add asciidoc 
rendering, and they work on my computer at least.  They don't change any 
other functionality that someone would be using.

But I had better make sure I know how to avoid this in the future.  I've 
been working with Git Extensions, and somewhere I didn't notice that it had 
changed my checkout branch from origin to upstream.

On Thursday, August 20, 2020 at 7:05:55 PM UTC-4, Edward K. Ream wrote:
>
> This is an experimental restriction. It can easily be removed.
>
> I think requiring PR's for devel and master makes sense. They alert 
> everyone of proposed changes before they take effect. The PR's themselves 
> are a permanent record of changes.
>
> Let me know if you have any considerations about this new policy.
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/88280e38-464e-4c6a-8314-5c5fee4c8272o%40googlegroups.com.

Re: PR's now required for the master and devel branches

[Mike Hodson]

On Thu, Aug 20, 2020 at 5:05 PM Edward K. Ream  wrote:

> This is an experimental restriction. It can easily be removed.
>
> I think requiring PR's for devel and master makes sense. They alert
> everyone of proposed changes before they take effect. The PR's themselves
> are a permanent record of changes.
>
> Let me know if you have any considerations about this new policy.
>
>
I for one like it. I've messed up too much with my own private git, so pull
requests to make any mergeable changes sounds quite good.
I've been quiet but definitely following progress; at some point I'll start
using Leo again, but this whole leointeg thing seems very nice.

Mike

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAN%2B%2B4hF_Sox44-jDKvJGqmiHPkS-ZKLRu33kT--cr9EXN8ej%3DQ%40mail.gmail.com.