I think another interesting question is whether uncrustify needs to change wrapping at all? Couldn't we just add some code which checks line length and warns the user if the code has to long lines and print where the offenders are? Automatic wrapping never results in readable code.
Sebastian Carsten Haitzler (The Rasterman) wrote: > On Thu, 29 Jul 2010 20:55:12 -0700 Michael Jennings <m...@kainx.org> said: > > read the mail you replied to originally. i make the statement that you can > keep > growing the wrap width to fix up the formatting. and you just grow until you > cease to wrap. thats avoiding the bug. not fixing it. it's what i said. i > didn't change canoes. if its 80 -> 85, or 80 -> 135 - same principle. > > as for terminal resizes - all terminals anyone really uses (except for actual > vt100's etc.) can be resized - linux console included. you can change screen > resolution, text mode and font sizes. no different to a terminal in x - just > harder to do the resizing. > > your argument is "well chose 135 because there is a terminal mode". i'll > believe that argument the day xterm, rxvt, gnome-terminal, eterm, konsole, the > linux fb console etc. etc. all come in 135 wide by default when you run them. > your argument justifies making wrap width wider because of standardisation. i > argue that that is a slippery slope of simply moving the goalposts as opposed > to fixing the formatting itself. that's what i said long before you piped up. > please don't tell me i changed canoes mid-stream. > >> On Friday, 30 July 2010, at 10:43:48 (+0900), >> Carsten Haitzler wrote: >> >>> you don't get the point - the point is that the formatter doesnt >>> handle wrapping intelligently. >> Not once in anything that you wrote to me did you state that. So no, >> that wasn't your point. Changing canoes in midstream because you >> made an error in logic does not mean I don't get the point. :) >> >>> you will find code that doesnt fit in 132 die and needs wrapping - >>> and the same problem will exist. >> That's certainly true. However, there will be *significantly fewer* >> occurances of the problem, and the result will still be more readable >> for those problem cases because the right-hand column is further out, >> allowing more space to work with. >> >> It's possible using 132 will eliminate enough problems to make fixing >> the tool unnecessary, allowing everyone to get back to writing EFL. >> Isn't it worth a try? >> >>> the only solution other than fixing the formatter is the slippery >>> slope. fix the problem. don't follow the slippery slope of >>> workarounds. >> That's not what the logical fallacy referred to as "slippery slope" >> means. The URL I provided explains it. >> >>> you argue that 132 columns is just fine because there is a terminal >>> mode for it. that argument can be extended to any width with "just >>> resize your terminal". >> Not true. Not all terminals can be resized. That's the whole point. >> If all terminals could be resized to any desired width, it wouldn't >> matter one wit what column count we chose. Fixed terminals such as >> the Linux console cannot be resized. That's precisely why the default >> of 80 tends to be used. >> >>> the fact is that when you start any terminal... you get an 80 wide >>> one in almost all cases. not 132. you need to change things to be >>> otherwise. thus 80 as a baseline makes sense. 132 doesn't. >> 132 makes sense for all the reasons I already mentioned. It's not as >> ideal as 80, no, but it has specific, clear advantages over all other >> values aside from 80. That may not be enough to make you want to use >> it, but it's still valid. >> >>> if your fix to wrapping problems is "well just make your terminal >>> wider" you're ignoring the actual problem that the formatter can't >>> wrap correctly. >> "Just make your terminal wider" is a misrepresentation of my >> viewpoint, and you know that. Yes, the formatter has issues, but is >> fixing someone else's formatter something you really want to invest >> time in this close to release? >> >> One could also say that the "actual problem" is that this whole mess >> was inflicted on the community without sufficient testing or advance >> discussion and way too close to the release date to be reasonable. >> >> Heaven forbid someone offer a suggestion that might save everyone a >> lot of time and headaches and have logical reasoning to back it up.... >> >> Michael >> >> -- >> Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <m...@kainx.org> >> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) >> ----------------------------------------------------------------------- >> "I want to stand with you on a mountain. I want to bathe with you >> in the sea. I want to lay like this forever, until the sky falls >> down on me." -- Savage Garden, "Truly, Madly, Deeply" >> >> ------------------------------------------------------------------------------ >> The Palm PDK Hot Apps Program offers developers who use the >> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >> of $1 Million in cash or HP Products. Visit us here for more details: >> http://p.sf.net/sfu/dev2dev-palm >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
