On Thu, 18 Jan 2018, David Gibson wrote: > On Thu, Jan 18, 2018 at 06:15:47AM +0100, Julia Lawall wrote: > > > > > > On Thu, 18 Jan 2018, David Gibson wrote: > > > > > On Tue, Jan 16, 2018 at 07:10:23AM +0100, Julia Lawall wrote: > > > > > > > > > > > > On Mon, 15 Jan 2018, Frank Rowand wrote: > > > > > > > > > On 01/15/18 10:33, Julia Lawall wrote: > > > > > > The start of a line is column 0, at least according to emacs. > > > > > > > > > > According to vim, the first character of a line is column 1. I don't know > > > > > if it has a concept of column 0, to the left of that character. > > > > > > > > > > $ vim --version > > > > > VIM - Vi IMproved 7.4 > > > > > > > > > > Let the editor wars begin.... :-) > > > > > > > > > > Personally, I use vim, but if the dtc column numbers match emac's world view > > > > > instead of vim's, that is fine with me. > > > > > > > > At the start of a line, ie just after a \n, there has been no character. > > > > This change made the column numbers work for me in the annotations. > > > > > > > > There is also the issue of tabs. David wanted tabs to count as 8 > > > > characters, but actually cpp converts tabs to spaces. So if a dts file > > > > has been through cpp, the numbers will be smaller. So it could be better > > > > to consider tabs to be 1 character, to not have to think about what kind > > > > of include was used. > > > > > > Urgh.. debating which editor to match sounds like it's going to be a > > > rathole. > > > > > > Let's try a different approach: does gcc ever report column numbers? > > > If so, what's its interpretation? > > > > Chosen at random, I have the following error: > > > > drivers/thermal/kirkwood_thermal.c:88:15: warning: assignment makes > > pointer from > > integer without a cast [enabled by default] > > priv->sensor = devm_request_and_ioremap(&pdev->dev, res); > > > > and the following code: > > > > priv->sensor = devm_request_and_ioremap(&pdev->dev, res); > > > > In emacs, the go to the line and type control f 15 times solution puts the > > cursor right afher after the =. The column numbers of emacs report 22 for > > that position. I guess in vim, putting the cursor right on the = would > > report 15. > > > > When I run the dts compiler on tests/test_tree1.dts, for line 39: > > > > > > compatible = "subsubnode2", "subsubnode"; > > > > I get the start and end as 24 and 65. 24 is what emacs shows as the > > column number when I put the cursor right on the c. 65 is what the column > > number shows when I put the cursor right past the semicolon. > > > > I tried to move around in vim, but I don't know how it works. It seems to > > report the position of the c as 4 or 25. It seems to report the position > > of the final semicolon as 44 or 65. I am not sure how it work though, > > because it gives the impression that there is a single blank character > > before c, which is not the case. > > Ok, let's go with the gcc definition, which appears to be "# of bytes > past the last \n". So that would be the strategy of the patch, where seeing a newline sets the counter to 0. julia > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson > -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
