- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH 1/2] Enabled new interactive prompt and updated some tests.
by Bryan Ischo 24 Feb '09

24 Feb '09

From: Bryan Ischo <bryan(a)ischo.com> Enabled a new prompt to ask the user if they'd like to remove unresolvable packages from the transaction rather than failing it. Many pactest tests that used to fail not return success codes, because pacman now issues a prompt allowing the user to cancel rather than failing many transactions, and the pactest scripts always choose to cancel with no error rather than failing. The only net effect is that the return status of pacman is now 0 in cases where it used to be nonzero. Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- lib/libalpm/alpm.h | 3 ++- lib/libalpm/deps.c | 6 +++--- lib/libalpm/sync.c | 23 ++++++++++++++++++----- pactest/tests/provision020.py | 2 +- pactest/tests/provision022.py | 2 +- pactest/tests/sync1008.py | 2 +- pactest/tests/sync300.py | 2 +- src/pacman/callback.c | 16 ++++++++++++++++ 8 files changed, 43 insertions(+), 13 deletions(-) diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index 7b7ca4e..3836d60 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -371,7 +371,8 @@ typedef enum _pmtransconv_t { PM_TRANS_CONV_REPLACE_PKG = 0x02, PM_TRANS_CONV_CONFLICT_PKG = 0x04, PM_TRANS_CONV_CORRUPTED_PKG = 0x08, - PM_TRANS_CONV_LOCAL_NEWER = 0x10 + PM_TRANS_CONV_LOCAL_NEWER = 0x10, + PM_TRANS_CONV_REMOVE_PKGS = 0x20, } pmtransconv_t; /* Transaction Progress */ diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index 41d2a83..ebcd18d 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -531,8 +531,8 @@ pmpkg_t *_alpm_resolvedep(pmdepend_t *dep, alpm_list_t *dbs, alpm_list_t *exclud !_alpm_pkg_find(excluding, pkg->name)) { if(_alpm_pkg_should_ignore(pkg)) { int install; - QUESTION(handle->trans, PM_TRANS_CONV_INSTALL_IGNOREPKG, pkg, - tpkg, NULL, &install); + QUESTION(handle->trans, PM_TRANS_CONV_INSTALL_IGNOREPKG, + pkg, tpkg, NULL, &install); if(!install) { continue; } @@ -609,7 +609,7 @@ int _alpm_resolvedeps(pmdb_t *local, alpm_list_t *dbs_sync, pmpkg_t *pkg, if(!spkg) { pm_errno = PM_ERR_UNSATISFIED_DEPS; char *missdepstring = alpm_dep_compute_string(missdep); - _alpm_log(PM_LOG_ERROR, _("cannot resolve \"%s\", a dependency of \"%s\"\n"), + _alpm_log(PM_LOG_WARNING, _("cannot resolve \"%s\", a dependency of \"%s\"\n"), missdepstring, tpkg->name); free(missdepstring); if(data) { diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index 5e5ca92..ea903f4 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -442,12 +442,25 @@ int _alpm_sync_prepare(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sync dependencies not already on the list */ } - /* If there were unresolvable top-level packages, fail the - transaction. */ + /* If there were unresolvable top-level packages, prompt the user to + see if they'd like to ignore them rather than failing the sync */ if(unresolvable != NULL) { - /* pm_errno is set by resolvedeps */ - ret = -1; - goto cleanup; + int remove_unresolvable = 0; + QUESTION(handle->trans, PM_TRANS_CONV_REMOVE_PKGS, unresolvable, NULL, NULL, &remove_unresolvable); + if (remove_unresolvable) { + /* User wants to remove the unresolvable packages from the + transaction, so simply drop the unresolvable list. The + packages will be removed from the actual transaction when + the transaction packages are replaced with a + dependency-reordered list below */ + alpm_list_free(unresolvable); + unresolvable = NULL; + } + else { + /* pm_errno is set by resolvedeps */ + ret = -1; + goto cleanup; + } } /* Add all packages which were "pulled" (i.e. weren't already in the diff --git a/pactest/tests/provision020.py b/pactest/tests/provision020.py index 7cb0a01..c9c0ac3 100644 --- a/pactest/tests/provision020.py +++ b/pactest/tests/provision020.py @@ -10,6 +10,6 @@ self.args = "-S %s" % p.name -self.addrule("PACMAN_RETCODE=1") +self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=pkg1") self.addrule("PKG_EXIST=pkg2") diff --git a/pactest/tests/provision022.py b/pactest/tests/provision022.py index 4883d42..190a8b6 100644 --- a/pactest/tests/provision022.py +++ b/pactest/tests/provision022.py @@ -10,6 +10,6 @@ self.args = "-S %s" % p.name -self.addrule("PACMAN_RETCODE=1") +self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=pkg1") self.addrule("PKG_EXIST=pkg2") diff --git a/pactest/tests/sync1008.py b/pactest/tests/sync1008.py index a606459..90c61df 100644 --- a/pactest/tests/sync1008.py +++ b/pactest/tests/sync1008.py @@ -14,6 +14,6 @@ self.args = "-S pkg" -self.addrule("PACMAN_RETCODE=1") +self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=pkg") self.addrule("!PKG_EXIST=cpkg") diff --git a/pactest/tests/sync300.py b/pactest/tests/sync300.py index 31b520a..36d6758 100644 --- a/pactest/tests/sync300.py +++ b/pactest/tests/sync300.py @@ -9,6 +9,6 @@ self.args = "-S %s" % sp1.name -self.addrule("PACMAN_RETCODE=1") +self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=pkg1") self.addrule("!PKG_EXIST=pkg2") diff --git a/src/pacman/callback.c b/src/pacman/callback.c index 6e7930c..d6b5b01 100644 --- a/src/pacman/callback.c +++ b/src/pacman/callback.c @@ -270,6 +270,22 @@ void cb_trans_conv(pmtransconv_t event, void *data1, void *data2, (char *)data2, (char *)data2); break; + case PM_TRANS_CONV_REMOVE_PKGS: + { + alpm_list_t *unresolved = (alpm_list_t *) data1; + alpm_list_t *namelist = NULL, *i; + for (i = unresolved; i; i = i->next) { + namelist = alpm_list_add(namelist, + (char *) alpm_pkg_get_name(i->data)); + } + printf(":: the following package(s) cannot be upgraded due to " + "unresolvable dependencies:\n"); + list_display(" ", namelist); + *response = yesno(_("\nDo you want to skip the above " + "package(s) for this upgrade?")); + alpm_list_free(namelist); + } + break; case PM_TRANS_CONV_LOCAL_NEWER: if(!config->op_s_downloadonly) { *response = yesno(_(":: %s-%s: local version is newer. Upgrade anyway?"), -- 1.6.1

7 45

Re: [pacman-dev] Git's views versus parallel branches (was Re: [PATCH 1/2] Enabled ...)
by Sebastian Nowicki 24 Feb '09

24 Feb '09

On 24/02/2009, at 1:45 PM, Bryan Ischo wrote: > An analogy: using git is kind of like keeping every directory in > your home directory in a separate tar file, except for one untarred > working directory. Whenever you want to cd into a new directory, > you have to tar up the directory you were just in, and then untar > the directory you want to cd into. Although I understand what you're getting at, the analogy is an exaggeration. The workflow you described requires archiving the directory, storing the archive somewhere, then removing the directory, and un-archiving a different archive, then changing to that directory. This is in contrast with a simple "git checkout branch" (possibly with a prior commit, or stash, operation). I.e., five operations as opposed to one or two. > An example of what I can do with parallel branches: if my branch > 'new' and 'old' were stored in two separate subdirectories, then I > could grep through all of the files in both branches with one > command and see collated results; or could diff only files in which > a given identifier appeared only in a file on one branch but not the > corresponding file on another. Given git's flexibility and UNIX philosophy, I'm sure it would be possible to create tools which did this. Most of my development thus far has been either adding features, or modifying small things, so I haven't had a need for this. In general the changes where not conflicting between branches, and I did not need to compare my branches with an upstream master branch. Perhaps this is a workflow issue (doing too many things at once)? > Another problem with git: I have to constantly rebuild stuff when I > stash and unstash because my build directory doesn't stash. I don't see why anyone would want to frequently change directories and compile. When I switch to a branch I tend to work on it for a while before switching to another one. > I'd rather use a paradigm that thousands of tools already depend on, > than the special case paradigm that is git. I don't see how this would improve your workflow in any way whatsoever, but it is possible to simply keep multiple trees, with a specific branch checked out. For instance instead of having one git repository "foobar", you could have a project directory "foobar", and have two repositories "eggs" and "spam", cloned from the same "master" repository, but with the "eggs" and "spam" branches checked out, respectively. You could still do all the other operations with git, if you add the other repositories as remotes, but this adds unnecessary maintenance. I see Dan beat me to pointing this out already. > If anything, git seems messier to me because some files get changed > in-place as you switch branches in git, and some files are ignored > and left as they are (those that aren't actually tracked by git), > and distinguishing between the two types requires git commands and > lots of mental notes. As I mentioned in my previous post, the files simply shouldn't be ignored, they should be added to a temporary commit before switching, otherwise you get confused. This is the downside of switching branches in-place. I don't really have a preference between a directory-based branch structure or an in-place structure. However, git's branches let you have a single tree (working directory), which seems simpler and cleaner. > you can do a grep over multiple branches at once to find identifiers git grep (not sure if it can actually grep over multiple branches) > , you can count line numbers for entire branches if you like to see > how much bigger your code base is in one branch than another git diff my_branch..other_branch --stat > you have to run many git commands Not really. Git is highly scriptable, if you do something often, you can script the git commands to do it (if they don't already exist), and just run the script. This is also what you'd call the UNIX philosophy. > git seems to require keeping a mental model of branches that you > can't even "see" because they aren't in your filesystem anywhere. Indeed, git doesn't track files, it tracks file content. Branches are just labels for a sequence of changes. I'm sure this gives git many advantages over other SCMs, but I'm not familiar enough with the underlying implementation to give any insight. > Except that not only am I getting confused about the state of my > branches as I commit partially complete changes to them for the > purpose of saving state as I switch between branches, the tools that > I use are getting confused as well. This seems to be a consistent theme in your workflow - "I switch branches frequently". This is probably why you're having so much trouble with git, and I suggest you ask yourself _why_ you switch branches so frequently. It seems to me like you're treating branches more like commits - each branch is a single logical change to the tree. Even though branches are cheap, I still only have a few around, and rarely switch between them. They are there to separate related commits, and to provide isolation from other branches. It may be that you're a "hacker" and simply work on unrelated code arbitrarily. I do that a lot too, but I somehow don't have the same problems you're facing. > Do some google searches. File renaming in version control systems > is a big deal, and for good reason. Like this? ;) http://article.gmane.org/gmane.comp.version-control.git/217 > Yes; it's called refactoring. On a well managed project it doesn't > happen often, but it does happen. Reorganization of subtrees of > code is something that source control systems should support well. > It's the merging after such reorganization that tools that don't > track renames have problems with. For examples of git failing in > this, take a look at the simple scripts I sent out to the list > earlier today. I don't see how renames are relevant in this situation. In fact, rename information would probably cause more problems. When you refactor, you're moving content, not files. Typically you also change that content significantly. I don't see why git would have any problem with this - this is actually where git's content tracking shines. > Git doesn't allow you to rename and change contents of a file at the > same time: > > [snip] > > If I 'git commit' it will take the rename of file to file2, but not > the modification of file2. If I try to add file2 before committing, > git status now shows: > > [snip] > > If you check this in, git will not be able to merge changes to file2 > into a branch taken before this change. I just tried a a more complex example that I was sure would result in a merge conflict. I basically created "file" and committed. I created the "move" branch I moved "file" to "file2", and edited it. At this point, `git status` showed something different to your output: $ git mv file file2 $ vi file2 $ git add file2 $ git status # On branch move # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: file -> file2 # $ git commit -m "changed file and renamed as file2" [move]: created 1fe9963: "changed file and renamed as file2" 1 files changed, 6 insertions(+), 8 deletions(-) rename file => file2 (58%) I commited the change, and created a branch "change" from master. I edited the same parts of the file and commited. Now I merged branch "move" into this branch. Naturally I get a conflict: $ git merge move Renaming file => file2 Auto-merging file2 CONFLICT (rename/modify): Merge conflict in file2 Automatic merge failed; fix conflicts and then commit the result. bash-3.2$ git status file2: needs merge # On branch changes # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # deleted: file # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # unmerged: file2 # Even when the file was moved, and a significant amount of it was changed (42%), git managed to see that it was moved, and still merged "file2" from the "move" branch with "file" from the "change" branch. The conflict would have occurred regardless of the move operation. Perhaps in a less contrived example the result would be different, but it would be an edge case where the renamed file's content really doesn't resemble that of the original file. > My impression of git is that it feels very much like what its > history suggests that it is: a tool for managing patches that grew > into a source control system. For better or worse, git feels > 'messy' to me, like it wasn't thought out ahead of time but kind of > organically grew I'm sure it was planned out quite well. Linus knew what he hated about other SCMs, he had some good ideas about how to improve those areas, and he did. Git does everything very well so far, and it's faster than any SCM I know about. > Git has dozens of commands, each with dozens of subtle and tricky > options; that seems like needless complexity to me. Git was made by a developer for developers. Of course the interface won't be nice and shiny. The difference between Git's interface and other SCMs' interfaces is that Git has it's guts exposed. Fortunately there is nice porcelain now. I suggest that you discuss these problems with the people at #git. They seem friendly and they know a _lot_ about git. I'm sure they could either explain how to use git to accommodate your workflow, or perhaps expose "flaws" in your workflow. At the very least you will know if git is for you or not. Sorry for going so off-topic here. This isn't even about pacman anymore :P.

2 1

Re: [pacman-dev] pacman and libalpm translation to kazakh
by Dan McGee 24 Feb '09

24 Feb '09

On Thu, Feb 19, 2009 at 11:11 AM, Baurzhan Muftakhidinov <baurthefirst(a)gmail.com> wrote: > Hi all, this is the latest (final) versions of translation. > > Hugo, I'm sorry, I've send the files to other e-mail, not this > (hugodoria(a)gmail.com) > > > Thanks all for great distro;) Thanks- I've patched this locally and I will push it in the next day or two to the main repository. -Dan

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.2.2-93-g2268981
by dan＠archlinux.org 24 Feb '09

24 Feb '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 2268981ebf562a7dda1e788dbd931e48adf9fabb (commit) via 9d661240fe77127fbede95066f38f12cad598e2d (commit) via f57f8d33862050acc8d131710c100ba47877e675 (commit) via 02685504012a4880e599b15f1060f6bd0bf48797 (commit) via a309a016bfed9f67452f2a6556fb4391fd55b34e (commit) via c8a41b7d6da7f820754a07cb085687ea5e110f85 (commit) via c590ac0997b5c82ddf9115191e9ac5c79efde227 (commit) from 1c4633ea2cbc01cfd7929509724951615827c482 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 2268981ebf562a7dda1e788dbd931e48adf9fabb Merge: 9d661240fe77127fbede95066f38f12cad598e2d a309a016bfed9f67452f2a6556fb4391fd55b34e Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 23 20:40:27 2009 -0600 Merge branch 'maint' commit 9d661240fe77127fbede95066f38f12cad598e2d Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 23 20:40:00 2009 -0600 Update pactest to use hashlib The md5 module is deprecated in favor of hashlib. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f57f8d33862050acc8d131710c100ba47877e675 Author: Bryan Ischo <bryan(a)ischo.com> Date: Sun Feb 22 23:25:32 2009 +1300 Don't prompt the user for unignore of IgnorePkg/IgnoreGroup packages Don't prompt the user for unignore of IgnorePkg/IgnoreGroup packages, except for packages explicitly listed for sync by the user. This eliminates many unnecessary prompts when IgnorePkg/IgnoreGroup is used. Signed-off-by: Bryan Ischo <bryan(a)ischo.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 02685504012a4880e599b15f1060f6bd0bf48797 Author: Bryan Ischo <bryan(a)ischo.com> Date: Sun Feb 22 23:25:31 2009 +1300 Enabled new interactive prompt and updated some tests Enabled a new prompt to ask the user if they'd like to remove unresolvable packages from the transaction rather than failing it. Many pactest tests that used to fail now return success codes, because pacman now issues a prompt allowing the user to cancel rather than failing many transactions, and the pactest scripts always choose to cancel with no error rather than failing. The only net effect is that the return status of pacman is now 0 in cases where it used to be nonzero. Signed-off-by: Bryan Ischo <bryan(a)ischo.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit c8a41b7d6da7f820754a07cb085687ea5e110f85 Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Wed Feb 18 17:15:39 2009 +0100 repo-add : remove realpath usage Rework slightly db_write_entry so that $pkgfile is no longer referenced from the temporary dir. This means $pkgfile can be a relative path and does not need to be converted with realpath anymore. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit c590ac0997b5c82ddf9115191e9ac5c79efde227 Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Wed Feb 18 16:39:31 2009 +0100 repo-add : remove the need of realpath for REPO_DB_FILE REPO_DB_FILE does not need to be an absolute path anymore so no need to call realpath. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/alpm.h | 3 +- lib/libalpm/deps.c | 36 ++++++++++++++----- lib/libalpm/deps.h | 2 +- lib/libalpm/sync.c | 28 +++++++++++---- pactest/tests/ignore001.py | 17 +++++++++ pactest/tests/ignore002.py | 35 +++++++++++++++++++ pactest/tests/ignore003.py | 35 +++++++++++++++++++ pactest/tests/ignore004.py | 46 +++++++++++++++++++++++++ pactest/tests/ignore005.py | 46 +++++++++++++++++++++++++ pactest/tests/provision020.py | 2 +- pactest/tests/provision022.py | 2 +- pactest/tests/sync1008.py | 2 +- pactest/tests/sync300.py | 2 +- pactest/util.py | 6 ++-- scripts/makepkg.sh.in | 2 - scripts/repo-add.sh.in | 76 +++++++++++++++++++---------------------- src/pacman/callback.c | 27 ++++++++++----- 17 files changed, 289 insertions(+), 78 deletions(-) create mode 100644 pactest/tests/ignore001.py create mode 100644 pactest/tests/ignore002.py create mode 100644 pactest/tests/ignore003.py create mode 100644 pactest/tests/ignore004.py create mode 100644 pactest/tests/ignore005.py hooks/post-receive -- The official pacman repository

3 3

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.2.2-9-ga309a01
by dan＠archlinux.org 24 Feb '09

24 Feb '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, maint has been updated via a309a016bfed9f67452f2a6556fb4391fd55b34e (commit) from e7daa59f845f073511c632a972215d047f292f25 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: scripts/makepkg.sh.in | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] Add pkggrp variable for split packages?
by Allan McRae 24 Feb '09

24 Feb '09

Hi all, One of the things that needs fixed in the splitpkg work is the printing of informational messages. I.e. when printing anything to do with $pkgname. Think of the following messages. - "is not available for the ? architecture" - "Making package" - "Finished making" At the moment ${pkgname[0]} is printed, but that may not be good. The same thing occurs with "makepkg --source" and the naming of the source tarball. I propose fixing this by adding a "pkggrp" field that is only valid with split packages and will hold a name to be used when describing a group of packages. If not specified, it will fall back to pkgname[0]. Does this sound reasonable to people? Allan

4 4

[pacman-dev] [PATCH 1/1] makepkg: fix updating pkgrel with pkgver in SCM packages
by Allan McRae 23 Feb '09

23 Feb '09

Commit 1e656c0a introduced the changing of pkgrel to 1 when the pkgver was updated in SCM PKGBUILDs. However, the output in the "Making package:" was wrong. Attempting to fix that created another bug (FS#13416). Interestingly, pkgver was only ever being updated in the fakeroot stage which caused this problem. Now both pkgver and pkgrel are updated after the first devel_check and devel_update. Enjoy the really long explaination for a two line fix... Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index e10c345..52e80d1 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1176,8 +1176,6 @@ devel_check() { if [ -n "$newpkgver" ]; then msg2 "$(gettext "Version found: %s")" "$newpkgver" - pkgver=$newpkgver - pkgrel=1 fi else -- 1.6.1.3

1 0

[pacman-dev] Pacman Disk Space Issues
by Matthew Wood 20 Feb '09

20 Feb '09

Good Evening- In following the posting at: http://bbs.archlinux.org/viewtopic.php?pid=502174#p502174. I was wondering what the status of the disk space issue was and if I could assist in working out a disk space checking function to incorporate into it. According to the afformentioned post, there is some contention as to where the problem lies. Additionally, I would like to be sure I am following the right procedure for submitting changes, as I have not previously done any work for the community, so please forgive any procedural mistakes or dumb questions, thanks. Matt

4 4

[pacman-dev] [translation] kazakh translation for pacman and libalpm
by Hugo Doria 20 Feb '09

20 Feb '09

kazakh translation for pacman and libalpm. Sent from Baurzhan Muftakhidinov. -- Hugo

1 0

[pacman-dev] Code style (was: [PATCH 2/3] Enabled a new prompt...)
by Dan McGee 19 Feb '09

19 Feb '09

On Wed, Feb 18, 2009 at 9:45 PM, Bryan Ischo <bji-keyword-pacman.3644cb(a)www.ischo.com> wrote: > Dan McGee wrote: >> You can wrap this if you want, ignore my earlier weird recommendations. >> > > Are you talking about the line length issues you pointed out before? And > are you saying here that it's OK to wrap the lines to fit 80 columns in my > editor, rather than trying to match another environment? > > I think that's what you're saying. I will henceforth wrap wherever makes > the most sense for me. You hadn't commented on my comments before, but I > think you agree that the pacman code style guidelines unfortunately cause > problems like these. Using tabs for indentation only works for unbroken > lines; as soon as a line is broken and the second half needs to be lined up > on a non-tab-boundary (with function arguments on the second line lining up > with those on the first, for example), Here is the false statement. Lining things up makes for a hellish experience, and never seems to work right, and only encourages the spaces vs. tabs debate. Just let the editor do the hard work for you- I don't want it to line up at all. Two additional tabs is the standard going rate in our codebase, as this is what vim does by default anyways. The only way lining them up makes sense is if your function name is super short- as soon as your function name and return type are more than 30 characters, you are just needlessly cramming everything over to the right. > then it all goes to pot, since the > number of tabs/spaces needed to make these broken lines line up properly is > entirely dependent on your tab width. Exactly why I'm proposing we do this *not* based on tab width at all. Two extra tabs, always, end of story. > The same problem is true for breaking lines to avoid going over 80 columns; > where 80 columns is for a given line depends on your tab width when you use > tab indenting. I use width 4 tab stops, which I think is just about as > "standard" as you can get with tab widths, but if you're using width 2 tab > stops, then you can fit quite a bit more on deeply nested lines than I can. We probably should be using 4-wide tab stops, but as you can see in the files, the modeline currently sets it to 2. If we were to change this we would have an awful lot of ugly code staring at us, and I'm not quite ready to take that plunge yet. -Dan

3 2