Bug 170902 - Remove TAB policy from fedora-init.el
Summary: Remove TAB policy from fedora-init.el
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-rpmdevtools   
(Show other bugs)
Version: 4
Hardware: All Linux
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-15 11:14 UTC by Enrico Scholz
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 1.3-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-27 19:08:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Do not sed `indent-tabs-mode' but tabify buffer on demand (1.20 KB, patch)
2005-10-15 15:53 UTC, Enrico Scholz
no flags Details | Diff
Simplified version (871 bytes, patch)
2005-10-15 16:59 UTC, Ville Skyttä
no flags Details | Diff

Description Enrico Scholz 2005-10-15 11:14:56 UTC
Description of problem:

Please remove the

| (set (make-local-variable 'indent-tabs-mode) nil)

line from fedora-init.el.  rpmbuild works well with tabs instead of whitespaces
and there does not exist a policy forbidding tabs.

The TAB policy can (and is) customized globally and I do not want to setup it
for every filemode.

Beside that, setting it in the fedora-new-rpm-spec-file-init does not make much
sense: the new tab policy applies to new spec files only; when opening an
already existing file, the hook will not be called and the global policy will be

Version-Release number of selected component (if applicable):


Comment 1 Ville Skyttä 2005-10-15 11:31:02 UTC
Since the beginning of the spec templates, they use indented "header" tags   
(Name, Version etc).  The indentation in these spec templates (which are used   
by newrpmspec and fedora-init.el) done with spaces, and we want to stay in   
sync with that and avoid mixing spaces/tabs.  As long as the indented  
templates are used, we need to choose between spaces and tabs, and I see no  
reason to change to tabs. 
Applying this to new specfiles only is the intended behaviour.  
So I'm not going to remove that line, but if you want, feel free to submit a  
patch that makes the behaviour easier to customize, and reopen this bug.  

Comment 2 Enrico Scholz 2005-10-15 15:53:20 UTC
Created attachment 120024 [details]
Do not sed `indent-tabs-mode' but tabify buffer on demand

Ok, this patch should solve the templates-do-not-use-tab situation without
adding a complicated customization.


> Applying this to new specfiles only is the intended behaviour.  

I think, it is a broken behavior ;) when keybindings differ between new and
existing files. E.g.

| C-c C-f newfile.spec<CR>   ;	fedora-new-rpm-spec-file-init will be called
| <TAB> -->  lots of spaces will be created
| C-c C-s   ; save
| C-c k     ; close buffer

| C-c C-f newfile.spec<CR>   ; is not 'new' anymore and new-hook not executed
| <TAB> -->  tabs will be created

Comment 3 Ville Skyttä 2005-10-15 16:59:59 UTC
Created attachment 120027 [details]
Simplified version

That patch is broken, testing for 'indent-tabs-mode always yields t since it
tests for the string "indent-tabs-mode", not the value of the variable.

Here's a simplified and fixed version, no need to explicitly load tabify.el
since tabify/untabify are autoloaded functions in in both GNU Emacs and XEmacs.

This still affects new files only, but should preserve consistency in terms of
local settings.  It doesn't help with preserving the existing policy in an
existing opened random specfile, but it didn't do it before either, so no new
breakage here.

Comment 4 Ville Skyttä 2005-10-15 19:53:54 UTC
Ok, I've applied my version of the patch to CVS; let me know if it works for 
you and I'll close this bug and release 1.3 with it soon. 

Comment 5 Enrico Scholz 2005-10-22 09:12:10 UTC
Ok; works for me (indent-tabs-mode is t).

Comment 6 Ville Skyttä 2005-10-27 19:08:14 UTC
Fixed in 1.3-1* 

Note You need to log in before you can comment on or make changes to this bug.