[PATCH] clang-format.el: customization-support, MELPA-compatibility

[Manuel Klimek]

Johann, any chance you can send your xml-based version as a patch to
cfe-commits? :)

Cheers,
/Manuel

On Fri Jan 09 2015 at 12:31:28 PM Daniel Jasper <djasper at google.com> wrote:

> On Fri, Jan 9, 2015 at 12:30 PM, Manuel Klimek <klimek at google.com> wrote:
>
>> On Fri Jan 09 2015 at 11:08:30 AM Manuel Klimek <klimek at google.com>
>> wrote:
>>
>>> On Fri Jan 09 2015 at 11:05:01 AM Johann Klähn <kljohann at gmail.com>
>>> wrote:
>>>
>>>> Nevertheless the package on MELPA should be backwards compatible to
>>>> in-the-wild clang versions, so it would have to contain some form of
>>>> workaround for 3.4, or what do you think?
>>>>
>>>
>>> So, as of r225516 we now support outputting a <cursor> element if the
>>> cursor was given on the command line.
>>>
>>> What I don't understand yet is:
>>> Why doesn't emacs correctly handle this by itself? Doesn't it update the
>>> cursor correctly when we insert / replace code?
>>>
>>
>> Figured that out myself (by checking out the xml branch of Johann's
>> github):
>> Emacs does the right thing unless we're within a range that is being
>> replaced, in which case it sets the cursor to the beginning of that range
>> (which is not what we usually want).
>>
>> So, I think the xml-based emacs integration works great if we use the
>> cursor that clang-format hands back, and if clang-format doesn't hand it
>> back when we give it -cursor= (old version), emacs' default behavior isn't
>> too bad...
>>
>
> Sounds good to me.
>
>
>>
>>
>>>
>>>
>>>
>>>> On Jan 9, 2015 10:49 AM, "Manuel Klimek" <klimek at google.com> wrote:
>>>>
>>>>> I'll update the XML format to contain the cursor position...
>>>>>
>>>>> On Fri Jan 09 2015 at 10:38:13 AM Daniel Jasper <djasper at google.com>
>>>>> wrote:
>>>>>
>>>>>> The cursor being past the end of the file should not lead to an
>>>>>> error!? Does this happen if the cursor is a the very end of the file?
>>>>>> Should we special-case that? Alternatively, it might be easier to uses
>>>>>> clang-format's -lines parameter instead of -offset/-length.
>>>>>>
>>>>>> On Fri, Jan 9, 2015 at 9:44 AM, Manuel Klimek <klimek at google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Note that the version deletes all content of a file in case of an
>>>>>>> error (for example, when the cursor is past the end of the file), so I
>>>>>>> wouldn't point melpa at it yet.
>>>>>>> I'm working on an improved version.
>>>>>>>
>>>>>>> On Thu Jan 08 2015 at 4:32:22 PM Manuel Klimek <klimek at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +cfe-commits (please do not cut that out during code review, the
>>>>>>>> list is the source of truth for code reviews)
>>>>>>>>
>>>>>>>> Landed as r225447. Note that I'm planning to adapt it soon to not
>>>>>>>> replace the whole buffer, but just apply the diffs (I'll cc' you on the
>>>>>>>> patch for review, unless you object :)
>>>>>>>>
>>>>>>>> Cheers & thx!
>>>>>>>> /Manuel
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed Jan 07 2015 at 6:06:08 PM Johann Klähn <kljohann at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Jan 7, 2015 at 5:14 PM, Manuel Klimek <klimek at google.com>
>>>>>>>>> wrote:
>>>>>>>>> > +If called interactively uses the region or the current buffer
>>>>>>>>> if there
>>>>>>>>> > +is no active region.  If no style is given uses
>>>>>>>>> `clang-format-style'."
>>>>>>>>> >
>>>>>>>>> > Doing full-buffer if nothing is selected is a usability problem
>>>>>>>>> if one works
>>>>>>>>> > in an existing codebase; if no region is selected, it should
>>>>>>>>> just use the
>>>>>>>>> > cursor position (which will get the current statement reflowed).
>>>>>>>>> > The idea is that the user can do clang-format-buffer if they
>>>>>>>>> insist.
>>>>>>>>> Excellent point.
>>>>>>>>>
>>>>>>>>> > +(put 'clang-format-executable 'risky-local-variable t)
>>>>>>>>> >
>>>>>>>>> > Any reason not to use :risky in the defcustom?
>>>>>>>>> Oh, I thought I already did so. I must have accidently reverted
>>>>>>>>> that change.
>>>>>>>>>
>>>>>>>>> Thanks for your feedback, find attached an updated patch.
>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cfe-commits mailing list
>>>>>>> cfe-commits at cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150112/8d5ba848/attachment.html>