Boyd Stephen Smith Jr. wrote:
In <[🔎] 4A328695.5030706@symantec.com>, Bob McGowan wrote:Boyd Stephen Smith Jr. wrote:Being disciplined with tabbing (indentation), spacing (alignment), and line-breaking/word-wrapping can allow your code/text to be beautiful independent of the viewers tab stop settings or terminal width.This is fine, for a particular workgroup who have a defined discipline. But I've had consistent problems with downloaded code, where different disciplines have been used. I end up with some lines indented less/more than others, in haphazard patterns, that make it impossible to determine which line belongs where, visually. And, there's no notation/comment in the file telling me what tabstop setting was used, so I have to experiment with various values until the right one is found. Or, at least, the one I "think" is right.Usually, 8 or 4 is the answer. Sometimes neither is consistently correct. Unfortunately, there's no magic fix on the receiver side. If you are getting the files from a person/group that is sloppy with their tabs, you'll just have to use their tab stops to be able to read their text. Hopefully, they will *at least* publish there tab stop information. For example, with a ex/vi/vim modeline or the emacs equivalent or both.I'm not familiar with the 'list' option, perhaps that would solve the above issue? I would love to be able to have consistent results, regardless of the file source.The 'list' option makes tabs print as "^I" and newlines show up as "$".[1] It helps find leading or trailing white space and differentiate tabs and spaces. It won't help (much) when trying to find the correct tab stop to accommodate others undisciplined indentation by others.
Ah. I use the shorthand 'l', just forgot what it means ;(
The 'expandtab' only affects _my_ editing input, not existing tabs, so there are no "spurious" changes made that would result in a "white space fix", as far as I can see.It depends. It can affect tabs on lines that you modified, even if you later "revert" your modifications before preparing the patch. At the very least, it can make a block of code use tabs (+ spaces) on some lines and only spaces on other lines -- which really mangles indentation for anyone using different tab stops.
I see, I was not aware of this side effect.And, it's the tabs+spaces in downloaded code that was giving me headaches. It would appear my "solution" was/is sub-optimal.
'expandtab' is *bad* unless it is project policy to never use tabs. It makes things "look right" only in the case where everyone is using exactly the same tab stops. If others are using tabs, your indentation needs to as well. The 'ci' and 'pi' options can help here.
Thanks, I'll check these out. -- Bob McGowan
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature