* tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compiler, docstrings, and suggestions) [not found] <mailman.11468.1413655061.1147.help-gnu-emacs@gnu.org> @ 2014-11-07 0:05 ` Emanuel Berg 2014-11-13 1:17 ` Robert Thorpe 0 siblings, 1 reply; 3+ messages in thread From: Emanuel Berg @ 2014-11-07 0:05 UTC (permalink / raw) To: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > In my opinion it's better to work this way: * Write > a script to remove all of the tabs in all your > personal file. Do that as a one-off operation * Set > indent-tabs-mode so Emacs never generates new tabs. > * Don't untab files before saving them. > > The advantage of this is that your own stuff will > always be tab-clean but you can still cooperate with > others who use VC. Good general point, but as for me I didn't do anything with other people since my first years at the university. It sure is lonesome at the top... *sob* But speaking even more broadly, why would anyone want whitespace after the "end" of lines, or whitespace after the "end" of files, or for that matter tabs instead of whitespace? I know tabs are needed in Makefiles but I suspect that to be something implementation-related. I don't think it would be impossible to program make to not have that requirement. Perhaps someone already tried or even succeeded... If it doesn't make sense to have, why should the guy who removes it adapt to the people who stick with it, and not the other way around? -- underground experts united ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compiler, docstrings, and suggestions) 2014-11-07 0:05 ` tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compiler, docstrings, and suggestions) Emanuel Berg @ 2014-11-13 1:17 ` Robert Thorpe 0 siblings, 0 replies; 3+ messages in thread From: Robert Thorpe @ 2014-11-13 1:17 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > Robert Thorpe <rt@robertthorpeconsulting.com> writes: > >> In my opinion it's better to work this way: * Write >> a script to remove all of the tabs in all your >> personal file. Do that as a one-off operation * Set >> indent-tabs-mode so Emacs never generates new tabs. >> * Don't untab files before saving them. >> >> The advantage of this is that your own stuff will >> always be tab-clean but you can still cooperate with >> others who use VC. > > Good general point, but as for me I didn't do anything > with other people since my first years at the > university. It sure is lonesome at the top... *sob* I'm sure you'll soon have to work with others, we all do. > But speaking even more broadly, why would anyone want > whitespace after the "end" of lines, or whitespace > after the "end" of files Generally, they wouldn't. But, removing it causes problems for version-control systems. It marks lines as being changed, when in reality nothing of significance was changed. It's best to require everyone who makes a change to remove extraneous whitespace. But, once code is in the repository it's best not to remove extraneous whitespace because it makes using blame/annotate more difficult. (Git has a switch to prevent this problem, other systems don't. Even Git just fake it, it still versions the change, it just skips past it when presenting data to the user). >, or for that matter tabs > instead of whitespace? I know one advocate of tabs, I'll explain it the way he does.... He says that a tab means "indent here". It doesn't prescribe a particular number of spaces to indent by. Instead it allows the programmer to decide how many spaces he wants to see for an indentation level by configuring his editor. I disagree with this view, but it isn't obviously incorrect. > If it doesn't make sense to have, why should the guy > who removes it adapt to the people who stick with it, > and not the other way around? The issue is more about not creating phantom changes in version control. Generally every project has a convention on tabs-versus-spaces, which should be followed. The group that should "adapt" to the other are the group that aren't following the project's convention. There are three possibilities not two. One is to remove all tabs and replace them with spaces as you advocate. That creates phantom changes. The second is to replace spaces with tabs, that also creates phantom changes. The third is to live with some mistakes and make no whitespace changes. I'm advocating the third. If you read emacs-devel you'll see that Eric Raymond has converted the Emacs version-control repository from Bazaar to Git. He's done this using a tool he wrote called reposurgeon which can make changes to version-controlled files that don't show up in version control history. Perhaps the long term answer is something like this. To fix all the whitespace in a way that makes the records show it was never wrong. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <mailman.13521.1415841476.1147.help-gnu-emacs@gnu.org>]
* Re: tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compiler, docstrings, and suggestions) [not found] <mailman.13521.1415841476.1147.help-gnu-emacs@gnu.org> @ 2014-11-15 19:14 ` Emanuel Berg 0 siblings, 0 replies; 3+ messages in thread From: Emanuel Berg @ 2014-11-15 19:14 UTC (permalink / raw) To: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > I'm sure you'll soon have to work with others, we > all do. Really? You think so?! <3 ;) > Generally, they wouldn't. But, removing it causes > problems for version-control systems. It marks lines > as being changed, when in reality nothing of > significance was changed. It's best to require > everyone who makes a change to remove extraneous > whitespace. But, once code is in the repository it's > best not to remove extraneous whitespace because it > makes using blame/annotate more difficult. (Git has > a switch to prevent this problem, other systems > don't. Even Git just fake it, it still versions the > change, it just skips past it when presenting data > to the user). Yes, I understood the first time :) > I know one advocate of tabs, I'll explain it the way > he does.... He says that a tab means "indent here". > It doesn't prescribe a particular number of spaces > to indent by. Instead it allows the programmer to > decide how many spaces he wants to see for an > indentation level by configuring his editor. I > disagree with this view, but it isn't obviously > incorrect. No, it is not. > If you read emacs-devel you'll see that Eric Raymond > has converted the Emacs version-control repository > from Bazaar to Git. He's done this using a tool he > wrote called reposurgeon which can make changes to > version-controlled files that don't show up in > version control history. Perhaps the long term > answer is something like this. To fix all the > whitespace in a way that makes the records show it > was never wrong. Cool that the veterans are still around. How about a forth idea: the compiler will somehow determine if the changes in whitespace are "only" cosmetical - "only" within quotation marks because that matters to the programmer, it can matter a lot actually, and if he is happy the way it looks he'll write better code. Not only will the VC program not report changes in whitespace, it won't do anything about it - that way every programmer can have their own indentation! -- underground experts united ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-11-15 19:14 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <mailman.11468.1413655061.1147.help-gnu-emacs@gnu.org> 2014-11-07 0:05 ` tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compiler, docstrings, and suggestions) Emanuel Berg 2014-11-13 1:17 ` Robert Thorpe [not found] <mailman.13521.1415841476.1147.help-gnu-emacs@gnu.org> 2014-11-15 19:14 ` Emanuel Berg
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.