Re: Leo and black

On Fri, Aug 2, 2019 at 4:38 PM Matt Wilkie wrote: > After playing with black for a bit, I quite like it. The only thing I've > seen it change that I haven't wholesale agreed with is dedenting "next line > comments". > This doesn't bother me. In this black issue, amb states: "Comments are not

Re: Leo and black

After playing with black for a bit, I quite like it. The only thing I've seen it change that I haven't wholesale agreed with is dedenting "next line comments". func(arg1, arg2 ... keyword=thing) # indented comment about above line because inline would # be too long, and before-line is

Re: Leo and black

On Mon, Jul 29, 2019 at 9:04 AM Terry Brown wrote: rabbitMQ - high performance cross language / cross machine (cloud) message queue system..it seems like the missing link in easy decoupling / connecting of software. Thanks for this. I've bookmarked https://www.rabbitmq.com/ Edward -- You

Re: Leo and black

On Mon, Jul 29, 2019 at 9:33 AM vitalije wrote: > I didn't want to say that this command should be used rarely. I was just pointing out that unless you have changed the code in a node, there is no point in executing this command. The node selection logic already compares the old and new

Re: Leo and black

On Mon, Jul 29, 2019 at 8:06 AM vitalije wrote: That would be rather invasive and most of the time unnecessary spending CPU > time. Selecting nodes is already too complicated and not very fast (to say > the least). Please don't add any more burden to it. > Blackening nodes automatically would

Re: Leo and black

On Monday, July 29, 2019 at 4:04:57 PM UTC+2, Terry Brown wrote: > > I disagree with Vitalije's assessment of how often you'd execute it, > I didn't want to say that this command should be used rarely. I was just pointing out that unless you have changed the code in a node, there is no point

Re: Leo and black

Now that I think about it I started using Black before I stopped using Leo. I disagree with Vitalije's assessment of how often you'd execute it, I found I quite often wanted a node tidied up. But I would agree with Vitalije on taking a minimalist light weight approach to using Black in Leo. I

Re: Leo and black

On Monday, July 29, 2019 at 2:44:10 PM UTC+2, Edward K. Ream wrote: > > So it looks like Leo could optionally run blacken-node whenever selecting > and/or unselecting a node for which @language python is in effect. > > That would be rather invasive and most of the time unnecessary spending CPU

Re: Leo and black

On Sunday, July 28, 2019 at 4:03:37 PM UTC-5, Edward K. Ream wrote: > black looks considerably slower than Leo's beautify commands. On second thought, it looks like Leo *can* use black with very little extra work. *Black looks fast enough* The blacken-node command (in the "black

Re: Leo and black

On Sunday, July 28, 2019 at 4:03:37 PM UTC-5, Edward K. Ream wrote: [improving] Leo's existing beautify commands so they follow black's > line-breaking strategy [should] be relatively straightforward. This would > be a major departure for Leo's beautify commands. > A quick prototype of Leo's

Re: Leo and black

On Sun, Jul 28, 2019 at 5:15 PM Terry Brown wrote: > I've been using black for quite a while. I agree it's probably not > fast enough to continuously reformat a file as you type, but that would > probably be annoying. Thanks for these comments. The prototype code in the "black" branch could

Re: Leo and black

I've been using black for quite a while. I agree it's probably not fast enough to continuously reformat a file as you type, but that would probably be annoying. I just have a "run black on file" shortcut noremap l mtgg!Gblack -S -q -l 79 -`t that binds \l to run black, including setting a mark

Leo and black

The black python formatter is worthy of serious consideration. Its best feature is line wrapping , moderated by a maximum line length setting (code setting in the API and/or command-line arg). The "black"