[libvirt] [PATCH v3 04/18] conf: Rework parsing in virStoragePoolDefParseSourceAdapter

[John Ferlan]

On 03/14/2017 03:08 PM, Laine Stump wrote:
> On 03/14/2017 02:30 PM, John Ferlan wrote:
>>
>> On 03/11/2017 08:16 PM, Laine Stump wrote:
>>> On 03/10/2017 04:10 PM, John Ferlan wrote:
>>>> Rather than use virXPathString, pass along an virXPathNode and alter
>>>> the parsing to use virXMLPropString.
>>> Just so I understand the reasoning correctly - you're not doing this so you can use virXMLPropString() instead of virXPathString(), but just so you can remove the "adapter" from the path to each attribute (and in the cases where that turns a "path" into simply the attribute name, you're switching to virXMLPropString() because it's presumably slightly more efficient. Right? Or is there some other reason you prefer virXMLPropString()?
>>>
>> Missed this on the first pass through your review... Probably because
>> your email client has stopped believing in line wrapping or my client
>> isn't seeing some setting properly <sigh>
> 
> 
> Really? Oh %&*()%$*)%$...
> 
> Late last week I encountered messages from someone which, when replied to, led to all of *their* quoted paragraphs in the reply each being a single very long line. So I asked about it on IRC, and Dan pointed me to some webpage claiming to know how to "fix" Thunderbird so that it worked reasonably with git-generated emails. I made the suggested changes, it didn't help, and then *I thought* I changed everything back. Apparently not :-(
> 
> 

My (old) notes on this...

Configuring thunderbird to wrap long lines...

Make sure sends are only in TEXT format in the 'account' settings and
the 'prefs' settings...

Find/use the word wrap add on

Use the config editor (prefs -> advanced -> config editor) to change:

(You'll prefs is a dialog box, advance a tab, and you have to promise to
be careful when using the config editor)

("mailnews.send_plaintext_flowed", false)

Make sure the mailnews.wraplength is set at the default of 72


John

>>
>> I had originally wanted the ability to just parse an <adapter...> since
>> that was how this would be represented in the domain; however, even
>> though that got mothballed - I still felt what I'd done so far was at
>> least a step up in readability, flow, etc. over what was there before.
> 
> Okay, so even more reason than what I'd assumed, i.e. more than enough :-)
>