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
