> That works for me. It's simply beautiful to see when all your code
> changes to fit with one command (changing the tabstops in the editor).
Sad though it may be I do join you in this concept of beauty.. Beauty to me
is also seeing all my variable names in neon Blue, function headers in bold
black, hitting the TAB key anywhere in the line and seeing the whole line
skip neatly into place (Ooh). Semicolon creating the next function header
and placing the cursor ready to put in the variable names (Aahh).
I will admit that I get around the problem of complex functions overflowing
by having a big screen!
Maybe Luke will get his editor refactoring nested case clauses into new
functions at a key press soon?
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
> When I opened this can of worms recently I had no idea
> it was an emacs thing, although I probably should have.
> One week I will set work aside and learn emacs. I'm
> sure it will eventually pay off.
>"Vance Shipley" <vances> writes:
>> When I opened this can of worms recently I had no idea it was an
>> emacs thing, although I probably should have.
>A tab is 8 spaces wide. IMO, any attempt to change this will only lead
>to agony, if not for yourself, then for someone else trying to browse
>your code with a different editor/tool than you.
>If you want smaller indents, just use plain spaces.
It depends what you mean by 'tab'. If you mean typing the TAB
character then that usually means "tab to the next tab stop" where the
next tab stop is application dependant. The TAB character in a file
also means "tab to the next tab stop" where the next tab stop is
commonly is the next 8th character position.
Some editors mix the two meanings and change the tabbing by inserting
tab characters into the file and changing the meaning of the tab
character. This is a big lose as it is not portable, even to the same
editor with a different set up.
Emacs, and many other editors, keep the two separate. Pressing the
TAB key moves to the next tab stop by inserting a suitable number of
TAB characters and spaces keeping the "standard" meaning of the TAB
character. This is sensible and portable.
Robert Virding Tel: +46 (0)8 545 55 017
Alteon Web Systems Email: rv
S:t Eriksgatan 44 WWW: http://www.bluetail.com/~rv SE-112 34 Stockholm, SWEDEN
"Folk s?ger att jag inte bryr mig om n?gonting, men det skiter jag i".
> It depends what you mean by 'tab'. If you mean typing the TAB
> character then that usually means "tab to the next tab stop" where
> the next tab stop is application dependant. The TAB character in a
> file also means "tab to the next tab stop" where the next tab stop
> is commonly is the next 8th character position.
True. I was disregarding the tab stop concept...
> Emacs, and many other editors, keep the two separate. Pressing the
> TAB key moves to the next tab stop by inserting a suitable number of
> TAB characters and spaces keeping the "standard" meaning of the TAB
> character. This is sensible and portable.
Yes, but my original point was that, even though your editor acts
sensibly in this regard, if you set the "tab width" to anything not
equal to 8, you will most likely produce text that renders badly for a
majority of people. Especially when it comes to source code.
The most portable approach is of course to setup your editor to
automatically "expand" tabs to spaces when buffers are flushed, as