After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
https://fedoraproject.org/wiki/PackagingDrafts/Tabs
- J<
On 08/20/2009 05:24 PM, Jason L Tibbitts III wrote:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
Someone went to the trouble to set a custom tab width? Man, I can only imagine what that does to Python.
~spot
On Thu, 2009-08-20 at 17:34 -0400, Tom "spot" Callaway wrote:
Someone went to the trouble to set a custom tab width? Man, I can only imagine what that does to Python.
Anybody using real tabs in python should be shot anyway. All sensible code I come across uses four spaces for indentation in python.
On Thu, Aug 20, 2009 at 2:24 PM, Jason L Tibbitts IIItibbs@math.uh.edu wrote:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
This sounds good to me. Redefining tab width is an extraordinary bad idea, and horrendous for software development. MAMEdevs[1] everywhere should listen up! ;-)
On Thu, 20 Aug 2009, Jason L Tibbitts III wrote:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
how about no tabs at all. With the exception of fortran and makefiles let's hang tabs out to die a cold, unloved death.
-sv
On Fri, Aug 21, 2009 at 01:20:08AM -0400, Seth Vidal wrote:
On Thu, 20 Aug 2009, Jason L Tibbitts III wrote:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
how about no tabs at all. With the exception of fortran and makefiles let's hang tabs out to die a cold, unloved death.
Yes, please! Especially half-mixed specfiles are fun. Isn't there an emacs/vim mode for specfiles that could be modified to automatically untabbify specfiles upon the next edit?
On 08/21/2009 08:52 AM, Axel Thimm wrote:
On Fri, Aug 21, 2009 at 01:20:08AM -0400, Seth Vidal wrote:
On Thu, 20 Aug 2009, Jason L Tibbitts III wrote:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
how about no tabs at all. With the exception of fortran and makefiles let's hang tabs out to die a cold, unloved death.
Yes, please! Especially half-mixed specfiles are fun. Isn't there an emacs/vim mode for specfiles that could be modified to automatically untabbify specfiles upon the next edit?
... and tab sensitive portions of a spec (such as Makefile fragments) will be corrupted ...
On Fri, Aug 21, 2009 at 08:58:04AM +0200, Ralf Corsepius wrote:
On 08/21/2009 08:52 AM, Axel Thimm wrote:
On Fri, Aug 21, 2009 at 01:20:08AM -0400, Seth Vidal wrote:
On Thu, 20 Aug 2009, Jason L Tibbitts III wrote:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
how about no tabs at all. With the exception of fortran and makefiles let's hang tabs out to die a cold, unloved death.
Yes, please! Especially half-mixed specfiles are fun. Isn't there an emacs/vim mode for specfiles that could be modified to automatically untabbify specfiles upon the next edit?
... and tab sensitive portions of a spec (such as Makefile fragments) will be corrupted ...
There are people embedding Makefile fragments into specfiles? How many specfiles are there this way and how many packagers do we have to brainwash to not do that? :)
On 08/21/2009 09:18 AM, Axel Thimm wrote:
On Fri, Aug 21, 2009 at 08:58:04AM +0200, Ralf Corsepius wrote:
On 08/21/2009 08:52 AM, Axel Thimm wrote:
On Fri, Aug 21, 2009 at 01:20:08AM -0400, Seth Vidal wrote:
On Thu, 20 Aug 2009, Jason L Tibbitts III wrote:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
how about no tabs at all. With the exception of fortran and makefiles let's hang tabs out to die a cold, unloved death.
Yes, please! Especially half-mixed specfiles are fun. Isn't there an emacs/vim mode for specfiles that could be modified to automatically untabbify specfiles upon the next edit?
... and tab sensitive portions of a spec (such as Makefile fragments) will be corrupted ...
There are people embedding Makefile fragments into specfiles?
I don't have an example at hand.
How many specfiles are there this way and how many packagers do we have to brainwash to not do that? :)
There is "brainwashed" in appending/cat'ing tab-sensitive Makefile-/Fortran/sh/text etc. fragments in rpm specs.
On 08/20/2009 11:24 PM, Jason L Tibbitts III wrote:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
-1
Tabs only add marginal unreadablity to specs.
They might not taste everybody, but that's all.
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> Tabs only add marginal unreadablity to specs.
Just to be clear, the proposal wasn't to eliminate tabs from specs, although that was proposed later in the thread. The proposal was to standardize a reasonable tab width.
- J<
On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote:
"RC" == Ralf Corsepiusrc040203@freenet.de writes:
RC> Tabs only add marginal unreadablity to specs.
Just to be clear, the proposal wasn't to eliminate tabs from specs, although that was proposed later in the thread. The proposal was to standardize a reasonable tab width.
Define reasonable tab with.
I guess you mean 8, but, whether you like it or not, there is no "standardized tab width".
Conversely, there are huge user groups, who "standardized" to other tab widths, e.g.
* Some BSDs systematically use a tab width of 4 everywhere. * Some vi users typically user a tab width of 3 (I am not using vi, so no idea where this originates from). * Many users apply a tab width of 2. * There are editors, which seem to guess on "best tab expansions". ...
To all these user groups, fixing rpm's tab width to 8 would seem "greasy kid-stuff" (sorry if this appears rude to you, but it's how I feel about people who are complaining about tab widths).
Ralf
On Fri, 2009-08-21 at 10:41 +0200, Ralf Corsepius wrote:
On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote:
Just to be clear, the proposal wasn't to eliminate tabs from specs, although that was proposed later in the thread. The proposal was to standardize a reasonable tab width.
Define reasonable tab with.
I guess you mean 8, but, whether you like it or not, there is no "standardized tab width".
Conversely, there are huge user groups, who "standardized" to other tab widths, e.g.
- Some BSDs systematically use a tab width of 4 everywhere.
- Some vi users typically user a tab width of 3 (I am not using vi, so
no idea where this originates from).
- Many users apply a tab width of 2.
- There are editors, which seem to guess on "best tab expansions".
...
These projects have standardized their tab widths. Why shouldn't Fedora?
On 08/21/2009 10:46 AM, Jussi Lehtola wrote:
On Fri, 2009-08-21 at 10:41 +0200, Ralf Corsepius wrote:
On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote:
Just to be clear, the proposal wasn't to eliminate tabs from specs, although that was proposed later in the thread. The proposal was to standardize a reasonable tab width.
Define reasonable tab with.
I guess you mean 8, but, whether you like it or not, there is no "standardized tab width".
Conversely, there are huge user groups, who "standardized" to other tab widths, e.g.
- Some BSDs systematically use a tab width of 4 everywhere.
- Some vi users typically user a tab width of 3 (I am not using vi, so
no idea where this originates from).
- Many users apply a tab width of 2.
- There are editors, which seem to guess on "best tab expansions".
...
These projects have standardized their tab widths. Why shouldn't Fedora?
Why should it? Because some editors are unable to grok tabs in usable ways and because some newbies are unable to cope with it?
On Fri, Aug 21, 2009 at 10:55:00AM +0200, Ralf Corsepius wrote:
On 08/21/2009 10:46 AM, Jussi Lehtola wrote:
On Fri, 2009-08-21 at 10:41 +0200, Ralf Corsepius wrote:
On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote:
Just to be clear, the proposal wasn't to eliminate tabs from specs, although that was proposed later in the thread. The proposal was to standardize a reasonable tab width.
Define reasonable tab with.
I guess you mean 8, but, whether you like it or not, there is no "standardized tab width".
Conversely, there are huge user groups, who "standardized" to other tab widths, e.g.
- Some BSDs systematically use a tab width of 4 everywhere.
- Some vi users typically user a tab width of 3 (I am not using vi, so
no idea where this originates from).
- Many users apply a tab width of 2.
- There are editors, which seem to guess on "best tab expansions".
...
These projects have standardized their tab widths. Why shouldn't Fedora?
Why should it? Because some editors are unable to grok tabs in usable ways and because some newbies are unable to cope with it?
So, if it is proven that there is no sane standardization for tab widths and users/editors are unable to cope with the various tab widths, Fedora shouldn't mandate a tab width etc. then that's more of an argment to make away with tabs for good.
Hello,
Ralf Corsepius wrote:
On 08/21/2009 10:46 AM, Jussi Lehtola wrote:
These projects have standardized their tab widths. Why shouldn't Fedora?
Why should it? Because some editors are unable to grok tabs in usable ways and because some newbies are unable to cope with it?
I was the reviewers who complained about the usage of a non-standard tab width. Please let me explain my intention behind this:
1. Spec files are not to be meant to be read only by the original packager. The should be in a format that _any_ packager can easily read and understand them. This is a quite generic requirement to all kind of communication. ;-) The current FPG cover this by requiring the legibility of the spec file.
IMHO this does not include only meaningful comments, indentations etc., but also the overall formatting when the file is viewed within an editor.
2. If the file was written with a specific (non-standard, please see below) tab width, it is quite hard to read. Sure, it is possible to change the tab width in the editor, but the question is: to what? So in order to display the spec file correctly it is necessary to guess the used tab width. I really consider this as not very practical.
3. It is correct that different projects use different tab widths. However, there are some widths which are more often used and so became more or less "standard". IMHO vi(m), (x)emacs and even the web browser uses 8 chars tab width per default. (During reviews I use quite often the browser just to have a first glance a the provided spec file...)
I definitively second that proposal.
Best regards, Christian
On Friday 21 August 2009, Ralf Corsepius wrote:
On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote:
> "RC" == Ralf Corsepiusrc040203@freenet.de writes:
RC> Tabs only add marginal unreadablity to specs.
Just to be clear, the proposal wasn't to eliminate tabs from specs, although that was proposed later in the thread. The proposal was to standardize a reasonable tab width.
Define reasonable tab with.
I guess you mean 8, but, whether you like it or not, there is no "standardized tab width".
Conversely, there are huge user groups, who "standardized" to other tab widths, e.g.
- Some BSDs systematically use a tab width of 4 everywhere.
- Some vi users typically user a tab width of 3 (I am not using vi, so
no idea where this originates from).
- Many users apply a tab width of 2.
- There are editors, which seem to guess on "best tab expansions".
...
You seem to be talking about indent steps instead of tab widths. They are different things. A lot of projects and people tweak their indent steps to their liking (such as in the examples above), but defining tab width is much less common and having it set to anything else than 8 is pretty much guaranteed to have bad effects somewhere.
On 08/21/2009 11:06 AM, Ville Skyttä wrote:
On Friday 21 August 2009, Ralf Corsepius wrote:
On 08/21/2009 09:21 AM, Jason L Tibbitts III wrote:
>> "RC" == Ralf Corsepiusrc040203@freenet.de writes:
RC> Tabs only add marginal unreadablity to specs.
Just to be clear, the proposal wasn't to eliminate tabs from specs, although that was proposed later in the thread. The proposal was to standardize a reasonable tab width.
Define reasonable tab with.
I guess you mean 8, but, whether you like it or not, there is no "standardized tab width".
Conversely, there are huge user groups, who "standardized" to other tab widths, e.g.
- Some BSDs systematically use a tab width of 4 everywhere.
- Some vi users typically user a tab width of 3 (I am not using vi, so
no idea where this originates from).
- Many users apply a tab width of 2.
- There are editors, which seem to guess on "best tab expansions".
...
You seem to be talking about indent steps instead of tab widths. They are different things. A lot of projects and people tweak their indent steps to their liking (such as in the examples above), but defining tab width is much less common and having it set to anything else than 8 is pretty much guaranteed to have bad effects somewhere.
Well, I don't understand your point.
I am actually talking about the number of characters, tabs are being expanded into when displaying files in editors and the like.
To make them "look nice" and "as desired", "tabbed indentation" and "display tab expansion" have to match.
Classical examples would be BSD sources. They typically are 4-char indented, using a tab for each "4 chars".
Ralf
On 08/21/2009 05:06 AM, Ville Skyttä wrote:
You seem to be talking about indent steps instead of tab widths. They are different things. A lot of projects and people tweak their indent steps to their liking (such as in the examples above), but defining tab width is much less common and having it set to anything else than 8 is pretty much guaranteed to have bad effects somewhere.
I think you might be mistaken. There is a group of people who believe there is an ASCII character whose semantic is "indent step". If something should be indented 2 levels then there should be two "indent step" characters which proceed it. They also believe how wide each indent step is is a per user preference. They have co-opted the ASCII tab character for this purpose. Some editors accommodate this philosophy by allowing each user to set their own "tab width" which expands each indent step character into the proper number of spaces.
The argument over whether to use tabs and what their width is has been a holy war for as long as I've programmed.
The proponents of "tab as indent step" have one major usability issue against them, you can never just open a text file and have it be readable unless you reset the tab width appropriately for each file. This is an enormous pain in the butt which is why the other camp is adamant about using spaces which have no ambiguity and require no special handling. Think of it as a portability issue.
On Friday 21 August 2009, John Dennis wrote:
I think you might be mistaken. There is a group of people who believe there is an ASCII character whose semantic is "indent step". If something should be indented 2 levels then there should be two "indent step" characters which proceed it.
I'm not one of those people.
tor 2009-08-20 klockan 16:24 -0500 skrev Jason L Tibbitts III:
After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage:
https://fedoraproject.org/wiki/PackagingDrafts/Tabs
- J<
Rpmlint's check for mixed tab/space indentation assumes a tab width of 8. Using something different is likely to either trigger false warnings or not catch all problems.
Mattias
packaging@lists.fedoraproject.org
-
Axel Thimm -
Christian Krause -
Christopher Stone -
Jason L Tibbitts III -
Jesse Keating -
John Dennis -
Mattias Ellert -
Ralf Corsepius -
Seth Vidal -
Susi Lehtola -
Tom Callaway -
Ville Skyttä