I couldn't help but notice the following changelog on the gnus cvslog group: * many files: Remove trailing whitespaces, replace spc+tab with tab, replace leading whitespaces with tabs. Does this change suggest that gnus source code should be indented with only tabs, not spaces, in the future? I wasn't aware of any gnus code conventions, but this sure looks like a step in that direction. I think that by default, both emacsen generate a mixture of tabs and spaces when the user hits the TAB key to indent in emacs-lisp-mode. It is my understanding that using only tabs in emacs-lisp-mode would (speaking for GNU emacs now) require changes to the variable `tab-width' and `tab-stop-list'. In other words, if all gnus developers had to start using the "only indent using tabs" convention, then it would require that every developer customized their emacs-lisp-mode-hook, for example. I'm just wondering, are there any gnus code conventions that pertain to the "indent with tabs vs. spaces" issue, and if so, what are they? -- Benjamin
I couldn't help but notice the following changelog on the gnus cvslog group: * many files: Remove trailing whitespaces, replace spc+tab with tab, replace leading whitespaces with tabs. Does this change suggest that gnus source code should be indented with only tabs, not spaces, in the future? I wasn't aware of any gnus code conventions, but this sure looks like a step in that direction. I think that by default, both emacsen generate a mixture of tabs and spaces when the user hits the TAB key to indent in emacs-lisp-mode. It is my understanding that using only tabs in emacs-lisp-mode would (speaking for GNU emacs now) require changes to the variable `tab-width' and `tab-stop-list'. In other words, if all gnus developers had to start using the "only indent using tabs" convention, then it would require that every developer customized their emacs-lisp-mode-hook, for example. I'm just wondering, are there any gnus code conventions that pertain to the "indent with tabs vs. spaces" issue, and if so, what are they? -- Benjamin
>>>>> In <wc38z9nmqwa.fsf@gamma.cis.ohio-state.edu> >>>>> Benjamin Rutt <rutt+news@cis.ohio-state.edu> wrote: > I couldn't help but notice the following changelog on the gnus cvslog > group: > * many files: Remove trailing whitespaces, replace spc+tab with > tab, replace leading whitespaces with tabs. `replace leading whitespaces with tabs' does not mean using only tabs. I've replaced ssssssss -> t sssssssst -> tt and so on. I've never done something like: ttss -> ttt It is natural on the condition that the option `indent-tabs-mode' is t (by default). Could you see the actual Gnus source files? -- Katsumi Yamaoka <yamaoka@jpl.org>
>>>>> In <wc38z9nmqwa.fsf@gamma.cis.ohio-state.edu> >>>>> Benjamin Rutt <rutt+news@cis.ohio-state.edu> wrote: > I couldn't help but notice the following changelog on the gnus cvslog > group: > * many files: Remove trailing whitespaces, replace spc+tab with > tab, replace leading whitespaces with tabs. `replace leading whitespaces with tabs' does not mean using only tabs. I've replaced ssssssss -> t sssssssst -> tt and so on. I've never done something like: ttss -> ttt It is natural on the condition that the option `indent-tabs-mode' is t (by default). Could you see the actual Gnus source files? -- Katsumi Yamaoka <yamaoka@jpl.org>
Katsumi Yamaoka <yamaoka@jpl.org> writes: >> * many files: Remove trailing whitespaces, replace spc+tab with >> tab, replace leading whitespaces with tabs. > > `replace leading whitespaces with tabs' does not mean using only > tabs. I've replaced > > ssssssss -> t > sssssssst -> tt > > and so on. I've never done something like: ttss -> ttt OK. That wasn't obvious from your Changelog, since you mention "spc+tab" which generally sounds like "all combinations of spaces and tabs" being replaced with tab. > It is natural on the condition that the option `indent-tabs-mode' is > t (by default). Could you see the actual Gnus source files? OK, I cvs updated one file, and saved the old version first (gnus-dired.el, a file I wrote not too long ago) to see the diffs. What is the motivation for this change? When I wrote gnus-dired.el, the last thing I did before submitting it for inclusion was M-x mark-whole-buffer and M-x indent-region, and I've never customized any of the indention variables in emacs-lisp-mode either. So, gnus-dired.el was originally indented using emacs's default indentation in emacs-lisp-mode. Is there any way I could have coded it differently to avoid requiring your whitespace modification? If not, then I think you're going to have to repeat the changes you made again and again as new code is submitted using emacs-lisp-mode's default indentation rules. -- Benjamin
Katsumi Yamaoka <yamaoka@jpl.org> writes: >> * many files: Remove trailing whitespaces, replace spc+tab with >> tab, replace leading whitespaces with tabs. > > `replace leading whitespaces with tabs' does not mean using only > tabs. I've replaced > > ssssssss -> t > sssssssst -> tt > > and so on. I've never done something like: ttss -> ttt OK. That wasn't obvious from your Changelog, since you mention "spc+tab" which generally sounds like "all combinations of spaces and tabs" being replaced with tab. > It is natural on the condition that the option `indent-tabs-mode' is > t (by default). Could you see the actual Gnus source files? OK, I cvs updated one file, and saved the old version first (gnus-dired.el, a file I wrote not too long ago) to see the diffs. What is the motivation for this change? When I wrote gnus-dired.el, the last thing I did before submitting it for inclusion was M-x mark-whole-buffer and M-x indent-region, and I've never customized any of the indention variables in emacs-lisp-mode either. So, gnus-dired.el was originally indented using emacs's default indentation in emacs-lisp-mode. Is there any way I could have coded it differently to avoid requiring your whitespace modification? If not, then I think you're going to have to repeat the changes you made again and again as new code is submitted using emacs-lisp-mode's default indentation rules. -- Benjamin
Benjamin Rutt <rutt+news@cis.ohio-state.edu> writes:
> When I wrote gnus-dired.el, the last thing I did before submitting it
> for inclusion was M-x mark-whole-buffer and M-x indent-region, and
> I've never customized any of the indention variables in
> emacs-lisp-mode either. So, gnus-dired.el was originally indented
> using emacs's default indentation in emacs-lisp-mode. Is there any
> way I could have coded it differently to avoid requiring your
> whitespace modification? If not, then I think you're going to have to
> repeat the changes you made again and again as new code is submitted
> using emacs-lisp-mode's default indentation rules.
Maybe the value of indent-tabs-mode also plays a role here. Hm.
kai
--
~/.signature is: umop 3p!sdn (Frank Nobis)
Benjamin Rutt <rutt+news@cis.ohio-state.edu> writes:
> When I wrote gnus-dired.el, the last thing I did before submitting it
> for inclusion was M-x mark-whole-buffer and M-x indent-region, and
> I've never customized any of the indention variables in
> emacs-lisp-mode either. So, gnus-dired.el was originally indented
> using emacs's default indentation in emacs-lisp-mode. Is there any
> way I could have coded it differently to avoid requiring your
> whitespace modification? If not, then I think you're going to have to
> repeat the changes you made again and again as new code is submitted
> using emacs-lisp-mode's default indentation rules.
Maybe the value of indent-tabs-mode also plays a role here. Hm.
kai
--
~/.signature is: umop 3p!sdn (Frank Nobis)
>>>>> In <wc34rkblyn5.fsf@gamma.cis.ohio-state.edu> >>>>> Benjamin Rutt <rutt+news@cis.ohio-state.edu> wrote: > OK. That wasn't obvious from your Changelog, since you mention > "spc+tab" which generally sounds like "all combinations of spaces and > tabs" being replaced with tab. Nope. I said literally SPACE and TAB. It can be replaced with single tab if it does not have the special meaning (e.g. a line commented out with leading ";; "). And we can save one byte in disk space. >> It is natural on the condition that the option `indent-tabs-mode' >> is t (by default). Could you see the actual Gnus source files? > OK, I cvs updated one file, and saved the old version first > (gnus-dired.el, a file I wrote not too long ago) to see the diffs. > What is the motivation for this change? I made sure of the differences between latest gnus-dired.el and old one (I've CVS checkd out it using -D '2 days ago'). I found I've removed traling spaces in seven lines and I've removed spaces from one line that there were only spaces in the line. I am using develock-mode[1] in lisp files, ChangeLog, etc. It does highlight such garbages loudly. [1] ftp://ftp.jpl.org/pub/elisp/develock.el.gz > When I wrote gnus-dired.el, the last thing I did before submitting it > for inclusion was M-x mark-whole-buffer and M-x indent-region, and > I've never customized any of the indention variables in > emacs-lisp-mode either. See: nnmaildir.el | 2124 ++++++++++++++++++++++++++--------------------------- and see what I've done on it. Maybe the author of this file has set the option `indent-tabs-mode' to nil. It makes source files fat needlessly. I must apologize to the author if there is the special sense, but I don't think so. I've modified it using Develock and advised commands as it has written under the default condition that `indent-tabs-mode' is t. > So, gnus-dired.el was originally indented > using emacs's default indentation in emacs-lisp-mode. Is there any > way I could have coded it differently to avoid requiring your > whitespace modification? If not, then I think you're going to have to > repeat the changes you made again and again as new code is submitted > using emacs-lisp-mode's default indentation rules. We only have to do just the right thing. We should never modify the basic options in the public space. We should take care that we don't leave garbages in the Gnus files. You don't have to use Develock, but it may help you to keep source files clean. -- Katsumi Yamaoka <yamaoka@jpl.org>
>>>>> In <wc34rkblyn5.fsf@gamma.cis.ohio-state.edu> >>>>> Benjamin Rutt <rutt+news@cis.ohio-state.edu> wrote: > OK. That wasn't obvious from your Changelog, since you mention > "spc+tab" which generally sounds like "all combinations of spaces and > tabs" being replaced with tab. Nope. I said literally SPACE and TAB. It can be replaced with single tab if it does not have the special meaning (e.g. a line commented out with leading ";; "). And we can save one byte in disk space. >> It is natural on the condition that the option `indent-tabs-mode' >> is t (by default). Could you see the actual Gnus source files? > OK, I cvs updated one file, and saved the old version first > (gnus-dired.el, a file I wrote not too long ago) to see the diffs. > What is the motivation for this change? I made sure of the differences between latest gnus-dired.el and old one (I've CVS checkd out it using -D '2 days ago'). I found I've removed traling spaces in seven lines and I've removed spaces from one line that there were only spaces in the line. I am using develock-mode[1] in lisp files, ChangeLog, etc. It does highlight such garbages loudly. [1] ftp://ftp.jpl.org/pub/elisp/develock.el.gz > When I wrote gnus-dired.el, the last thing I did before submitting it > for inclusion was M-x mark-whole-buffer and M-x indent-region, and > I've never customized any of the indention variables in > emacs-lisp-mode either. See: nnmaildir.el | 2124 ++++++++++++++++++++++++++--------------------------- and see what I've done on it. Maybe the author of this file has set the option `indent-tabs-mode' to nil. It makes source files fat needlessly. I must apologize to the author if there is the special sense, but I don't think so. I've modified it using Develock and advised commands as it has written under the default condition that `indent-tabs-mode' is t. > So, gnus-dired.el was originally indented > using emacs's default indentation in emacs-lisp-mode. Is there any > way I could have coded it differently to avoid requiring your > whitespace modification? If not, then I think you're going to have to > repeat the changes you made again and again as new code is submitted > using emacs-lisp-mode's default indentation rules. We only have to do just the right thing. We should never modify the basic options in the public space. We should take care that we don't leave garbages in the Gnus files. You don't have to use Develock, but it may help you to keep source files clean. -- Katsumi Yamaoka <yamaoka@jpl.org>
Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> It is natural on the condition that the option
> `indent-tabs-mode' is t (by default).
Maybe that setting should be specified in a Local Variables comment in
all the Gnus source files? That way, people who normally have it set
to nil (such as me) won't accidentally reintroduce spaces by
forgetting to run M-x tabify RET on the changed region.
paul
Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> It is natural on the condition that the option
> `indent-tabs-mode' is t (by default).
Maybe that setting should be specified in a Local Variables comment in
all the Gnus source files? That way, people who normally have it set
to nil (such as me) won't accidentally reintroduce spaces by
forgetting to run M-x tabify RET on the changed region.
paul
Benjamin Rutt <rutt+news@cis.ohio-state.edu> wrote:
>>> * many files: Remove trailing whitespaces, replace spc+tab with
>>> tab, replace leading whitespaces with tabs.
> What is the motivation for this change?
Reduced file size, I think.
paul
Benjamin Rutt <rutt+news@cis.ohio-state.edu> wrote:
>>> * many files: Remove trailing whitespaces, replace spc+tab with
>>> tab, replace leading whitespaces with tabs.
> What is the motivation for this change?
Reduced file size, I think.
paul
>>>>> In <m3sn7u8ki5.fsf@multivac.cwru.edu> >>>>> prj@po.cwru.edu (Paul Jarc) wrote: > Katsumi Yamaoka <yamaoka@jpl.org> wrote: > > It is natural on the condition that the option > > `indent-tabs-mode' is t (by default). > Maybe that setting should be specified in a Local Variables comment in > all the Gnus source files? That way, people who normally have it set > to nil (such as me) won't accidentally reintroduce spaces by > forgetting to run M-x tabify RET on the changed region. Using tabify is quite dangerous. It might modify string codes in lisp files. -- Katsumi Yamaoka <yamaoka@jpl.org>
>>>>> In <m3sn7u8ki5.fsf@multivac.cwru.edu> >>>>> prj@po.cwru.edu (Paul Jarc) wrote: > Katsumi Yamaoka <yamaoka@jpl.org> wrote: > > It is natural on the condition that the option > > `indent-tabs-mode' is t (by default). > Maybe that setting should be specified in a Local Variables comment in > all the Gnus source files? That way, people who normally have it set > to nil (such as me) won't accidentally reintroduce spaces by > forgetting to run M-x tabify RET on the changed region. Using tabify is quite dangerous. It might modify string codes in lisp files. -- Katsumi Yamaoka <yamaoka@jpl.org>
Katsumi Yamaoka <yamaoka@jpl.org> wrote: > nnmaildir.el | 2124 ++++++++++++++++++++++++++--------------------------- > > and see what I've done on it. Maybe the author of this file has > set the option `indent-tabs-mode' to nil. Yep. > It makes source files fat needlessly. It's needless only if you assume everyone uses the same tab width. So maybe tab-width and indent-tabs-mode should both be set in the Local Variables. > I must apologize to the author if there is the special sense, but I > don't think so. No, I don't mind. I was surprised to find that someone had modified it, with no mention of nnmaildir by name in the ChangeLog, but the end result is that I now know how to retrieve particular versions of files with CVS and how to remove the sticky tag. :) paul
Katsumi Yamaoka <yamaoka@jpl.org> wrote: > nnmaildir.el | 2124 ++++++++++++++++++++++++++--------------------------- > > and see what I've done on it. Maybe the author of this file has > set the option `indent-tabs-mode' to nil. Yep. > It makes source files fat needlessly. It's needless only if you assume everyone uses the same tab width. So maybe tab-width and indent-tabs-mode should both be set in the Local Variables. > I must apologize to the author if there is the special sense, but I > don't think so. No, I don't mind. I was surprised to find that someone had modified it, with no mention of nnmaildir by name in the ChangeLog, but the end result is that I now know how to retrieve particular versions of files with CVS and how to remove the sticky tag. :) paul
Katsumi Yamaoka <yamaoka@jpl.org> writes:
> We only have to do just the right thing.
Your opinion on what the right thing is just that, an opinion.
Without code conventions, it is every gnus developer's right to
(setq indent-tabs-mode nil)
in emacs-lisp-mode. Your changes were so massive that it looked like
gnus code conventions had materialized. Evidently that is not the
case. Rather, it looks like one person's opinion of the "right thing"
spread throughout all the source code.
--
Benjamin
Katsumi Yamaoka <yamaoka@jpl.org> writes:
> We only have to do just the right thing.
Your opinion on what the right thing is just that, an opinion.
Without code conventions, it is every gnus developer's right to
(setq indent-tabs-mode nil)
in emacs-lisp-mode. Your changes were so massive that it looked like
gnus code conventions had materialized. Evidently that is not the
case. Rather, it looks like one person's opinion of the "right thing"
spread throughout all the source code.
--
Benjamin
>>>>> In <wc3vgcqjov0.fsf@gamma.cis.ohio-state.edu> >>>>> Benjamin Rutt <rutt+news@cis.ohio-state.edu> wrote: > Katsumi Yamaoka <yamaoka@jpl.org> writes: >> We only have to do just the right thing. > Your opinion on what the right thing is just that, an opinion. Yes, that is my opinion, developers don't have to follow me. :-) > Without code conventions, it is every gnus developer's right to > (setq indent-tabs-mode nil) > in emacs-lisp-mode. Your changes were so massive that it looked like > gnus code conventions had materialized. Evidently that is not the > case. Rather, it looks like one person's opinion of the "right thing" > spread throughout all the source code. I'm never a fascist, I'll accept a majority opinion. I think removing garbages and reducing file size are good things, but if many people don't consider so, I'll never do that in future. I know some people have changed `tab-width' and `tab-stop-list' globally. They are free to do anything. However, since almost all Gnus files use tabs (and possibly following spaces, of course) for the indentation and it seems that they assume the value of `tab-width' is eight, modifying `tab-width' is against their own interests. If it is correct, using only spaces for the indentation has only an effect on increasing file size. I think so and I've done those changes. -- Katsumi Yamaoka <yamaoka@jpl.org>
>>>>> In <wc3vgcqjov0.fsf@gamma.cis.ohio-state.edu> >>>>> Benjamin Rutt <rutt+news@cis.ohio-state.edu> wrote: > Katsumi Yamaoka <yamaoka@jpl.org> writes: >> We only have to do just the right thing. > Your opinion on what the right thing is just that, an opinion. Yes, that is my opinion, developers don't have to follow me. :-) > Without code conventions, it is every gnus developer's right to > (setq indent-tabs-mode nil) > in emacs-lisp-mode. Your changes were so massive that it looked like > gnus code conventions had materialized. Evidently that is not the > case. Rather, it looks like one person's opinion of the "right thing" > spread throughout all the source code. I'm never a fascist, I'll accept a majority opinion. I think removing garbages and reducing file size are good things, but if many people don't consider so, I'll never do that in future. I know some people have changed `tab-width' and `tab-stop-list' globally. They are free to do anything. However, since almost all Gnus files use tabs (and possibly following spaces, of course) for the indentation and it seems that they assume the value of `tab-width' is eight, modifying `tab-width' is against their own interests. If it is correct, using only spaces for the indentation has only an effect on increasing file size. I think so and I've done those changes. -- Katsumi Yamaoka <yamaoka@jpl.org>
I think it is ok to assume that tab-width is 8 for Gnus, that assumption is everywhere in the Emacs code. On the other hand, I don't think it is worth saving a few bytes to change existing spaces to tabs, when it doesn't affect indentation. The price of potential merge conflicts is too high. You can of course safely convert spaces to tabs when you modify the code, since that will lead to not additional conflicts. On the gripping hand, Katsumi Yamaoka's should not be undone, as that would just lead to even more conflicts. In short: set tab-width to 8, and don't worry about space/tabs otherwise.
Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> in emacs-lisp-mode. Your changes were so massive that it looked like
>> gnus code conventions had materialized. Evidently that is not the
>> case. Rather, it looks like one person's opinion of the "right thing"
>> spread throughout all the source code.
>
> I'm never a fascist, I'll accept a majority opinion. I think
> removing garbages and reducing file size are good things, but if
> many people don't consider so, I'll never do that in future.
I think it's a good idea to do these things once in a while, to
"normalize" the whitespace in the files. I've done so myself a
couple of times before.
It's much better to do it in one big gulp than to parcel out the
whitespace cleanups here and there, because that tends to hide which
changes are whitespace cleanups, and which are actual code changes.
So doing, say, a yearly total cleanup is quite nice.
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen