receive statement in Erlang

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

receive statement in Erlang

Sean Hinde-2
> 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?

 -Sean



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.



Reply | Threaded
Open this post in threaded view
|

editor wars

Vance Shipley-2

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


Reply | Threaded
Open this post in threaded view
|

editor wars

Daniel Néri-2
"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.

> One week I will set work aside and learn emacs.  I'm sure it will
> eventually pay off.

Have fun ;-)


Regards,
   --Daniel

--
Daniel Neri                                      mailto:dn
Sigicom AB, Sweden                              http://www.sigicom.com



Reply | Threaded
Open this post in threaded view
|

editor wars

Hal Snyder-2
In reply to this post by Vance Shipley-2
"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.
>
> One week I will set work aside and learn emacs.  I'm
> sure it will eventually pay off.

I like *both* editors, vi and XEmacs.

and both databases, mnesia and postgresql, etc.


Reply | Threaded
Open this post in threaded view
|

editor wars

Robert Virding-4
In reply to this post by Daniel Néri-2
daniel.neri (Daniel =?iso-8859-1?q?N=E9ri?=) writes:

>"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
--
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".


Reply | Threaded
Open this post in threaded view
|

editor wars

Daniel Néri-2
Robert Virding <rv> writes:

> 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
recommended in

    http://www.jwz.org/doc/tabs-vs-spaces.html



Best wishes,
   --Daniel

--
Daniel Neri                                      mailto:dn
Sigicom AB, Sweden                              http://www.sigicom.com