[snipped 37 lines]

 sivaram
 --

(where'd I put those notes)

nb

--
vi --the heart of evil!
Support labeling GMOs
<http://www.labelgmos.org/>

1 - My current emacs lisp directory is about 80 mbytes.  Even if it was
stripped to zero, it would hardly affect my disk space.

2 - For professionals, the cost to search the web for one package is far
more than the cost of a 100 gbyte disk.

3 - The risk of installing malware says I want to download software as
infrequently as possible.

IMHO, include every package that's part of the distro.  If I don't use
it, it doesn't matter.

atb

Glyn

(IMHO, in general, far too many people attempt to write or modify multi-threading code than are actually competent to do so.  The hardware and software complexities involved in getting robust memory ordering across processors with good performance are simply beyond the average programmer....)

Cheers,

Mark

Ob.Help:

On 06/25/2012 02:02 PM Sivaram Neelakantan wrote:

People familiar with C say it's a difficult language.  But I guess they
never tried it.  You can pick up a book on it and if you give it a
little bit of time every day, you can learn enough in a week to write
interesting and working programs.  And it's fun.  Shell programming like
bash and ksh are easy and fun too.  C++ too, but to a lesser degree.
But elisp....  I tried repeatedly over more than ten years to learn it,
bought and read a couple books on it, did some tutorials, of course
spent a lot of time in the docs, but it wasn't until just a few years
ago (and with a lot of help from this list) that I was able to write my
first elisp program.  I started a second one last year and I'm still
plodding really slow through it (but not often).  It takes so long to
get things to work that I'm discouraged from spending time on it.  Half
the time I'm trying to figure out the code and moan to myself that, if I
could write this function in C, I would have had it written in one-tenth
the time... or less.  Then, after I've written some working elisp code
and look at, I see it's not that difficult.  So how is it that it took
so long to figure out?  Maybe, if I live to be three hundred, I'll write
an elisp book myself.

Clearly the sweet spot is inbetween: the right number of committed,
capable programers to keep developing refactoring progressing

The thread Tom alluded to earlier http://thread.gmane.org/gmane.emacs.devel/126892
suggests what in systems thinking is called a reinforcing-loop or
vicious cycle: http://www.systems-thinking.org/theWay/sre/re.htm

Too few programmers working on too many new areas
Spread too thin for doing more 'less ciritcal' work
Cant mentor/tutor new wannabie devs
The wannabies feel unwelcome and leave depleting the already depleted
population of devs

And then if you go up the pyramid from elisp code to emacs use it only
gets worse: how many mailing systems are there?

Of course, the crowdfunding model is more suited for contractors who are
used to taking up different projects regularly, so they can easily
choose implementing an Emacs feature as a next project.

But it's also a possible that a skilled developer could make a
permanent living from developing Emacs features, by starting the
next crowdfunded project immediately when he finished
implementing the previous one.

   Too few programmers working on too many new areas
   Spread too thin for doing more 'less ciritcal' work
   Cant mentor/tutor new wannabie devs
   The wannabies feel unwelcome and leave depleting the already depleted
   population of devs

I'd love to see emacsmovies branch out to do internals walkthroughs.
To riff off the most recent production, i imagine episodes:
 - src/buffer.[hc], concentrating on ‘struct buffer’
 -        likewise, for everything else
 - changes to src/buffer.[hc] over the years (repo archeology)
 - demo of CEDET (et al) handling of src/buffer.[hc] (as part of src/*)
 - survey of external gap-buffer implementations in various languages
 - tie in of these episodes to "user level experience" (seminal) episode

The last few are important for newbie hackers who do not yet know
they are newbie hackers.  :-D

[FWIW, the dream for such a series (in text, in Emacs) was the impetus for
<http://www.gnuvola.org/software/personal-elisp/dist/lisp/low-stress/a...>.]

Hey emacsmovies hacker (if you are reading this): What do you say?

C and Pascal are the same.  C or C++ are almost the same (compare Homo
Sapiens Sapiens with Homo Neandertalis).  All the common languages fall
into the Algol category of languages; basically, when you know one, you
know all of them: the semantics are fundamentally the same, only the
unimportant syntax changes.

But beside the Algol category, there are:

- the logical programming category (Prolog, etc),

- the lisp category (eg. Common Lisp, Emacs Lisp, Scheme, and a lot of
  older lisps)

- the functional programming category (Haskell, ML, Ocaml, etc).

and a lot of others.
http://en.wikipedia.org/wiki/List_of_programming_languages_by_type

When you change of language category, the syntax may change or not, but
importantly, it's the semantics that change.  That's where you may be
misled and have to spend more learning time.

For example, syntactically, adding two numbers is written:

     {
        int a=1;
        int b=1111111112;
        int c=1111111113;
        a=b+c;
     }

in C, and:

    (let ((a 1)
          (b 1111111112)
          (c 1111111113))
      (setf a (+ b c)))

in lisp.  But the syntac is irrelevant.  You can easily write a
pre-processor to convert one into the other.
(See for example: http://paste.lisp.org/display/25134)

What's more important to understand the meaning of those programs, is
their semantics.

In a 32-bit C, (ie. a C where int has a 32-bit two-complement
representation), the result would be -2072745071 with some compiler.
(In some other C compilers, it could signal a run-time error, the C
standard doesn't specify what must happen).

In a 64-bit C, (ie. a C where int has a 64-bit two-complement
representation), the result would be 2222222225.

In a 32-bit emacs, which has no bignums and where fixnums are limited to
29-bit two-complement the result would be 74738577.

In a 64-bit emacs, which has still no bignums, but where fixnums are
limited to 61-bit two-complement, the result would be 2222222225.

In a Common Lisp implementation, which therefore has bignums, whatever
the size of the fixnums, the results would be 2222222225.

So you can see that the meaning of a simple operation such as a=b+c or
(setf a (+ b c)):

1- is NOT specified entirely by most programming languages.

2- is specified entirely in some programming languages.

3- when it's specified (be it by the language or by an implementation),
   MAY or MAY NOT mean the same thing (ie. give the same results).

The semantical differences are therefore:

In Common Lisp, + for integers implements the mathematical integer
addition (up to the available memory).

In emacs lisp, + for integers implements the addition modulo 29 or 61
depending on the machine word size.

In C, + for int may implement the addition modulo 32 or 64, or something
else (including signaling a run-time error, or a compilation-time error).

And this is only for the simpliest of the operation.  In the code sample
above, there are other semantic differences, like the fact that in lisp
there are no statement, therefore all expression returns a value.  setf
returns the last value assigned.  let returns the result of the last
expression in its body, so the let form actually returns the result of
the addition, and if you evaluate it in a REPL (read eval print loop),
then this result will be printed too.  On the other hand, {} is a
statement in C, which has no result value and nothing is ever returned
or printed by that code sample.  The let form is a valid lisp expression
as it is.  The {} however does not stand alone: you need to wrap it in a
C program to make it really meaningful.  There's the fact that in C,
types are a property of the variables, while in Lisp types are property
of the values.  The fact that setf is actually a macro, that while it's
provided by the language, could be written by the user if it was
missing, like any other macros, vs. the fact that = is a hard wired C
operator and the user can't add new operators (it's possible for some of
them in C++, but with vastly different mechanisms and semantics than
lisp macros).  Etc.

The conclusion is that to learn a programming language in a different
category of what you know already, you must forget what you know, and
just learn it from the beginning.

And the existance of those different broad categories is also the reason
why you are told to learn different programming languages.  But learning
C and C++ doesn't count.  You must pick one language in each category!

Since you already know C, you should learn at least Prolog, one lisp
(but it's also useful to learn elisp, scheme and Common Lisp),  Haskell,
APL and Smalltalk.

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

nb

--
vi --the heart of evil!
Support labeling GMOs
<http://www.labelgmos.org/>

--
Dustin Hemmerling.

Writing trivial and shitty code is easy. Writing quality code that works
well for the end-user is hard and not fun.

I work in a numerical modeling group of 20 engineers. We all have
graduate degrees. 5 Americans, 15 foreign-born, the youngest American is
late 40s. Americans under age 35 just won't work for a damn thing.
--
In religion and politics, people's beliefs and convictions are in
almost every case gotten at second-hand, and without examination.
-- Mark Twain

When I started learning Emacs, I had to start internalising the
terminology used by Emacs. Frame, Window, Mark, Point etc.  When I
understood that, the manual started to make sense a little bit more.
The more I started missing things in Emacs compared to what I was used
to in other editors, this mailing list along with pointers to the
manual made things clear.

I was given Emacs and the manual, that's where I started and while I
did need help to bootstrap things, I don't know how the documentation
can be improved if the mental model that people have of an editor does
not correspond to the Emacs way of things.  

I mean, what's the point of doing Ctrl C/V (CUA mode?)/Vi keystrokes in
Emacs, if you're not willing to do things the Emacs way.  I think
there is no documentation of Windows HCI guidelines that Emacs
follows.  All I seem to see on the list, "documentation is not
helpful"; well about what?  No answer because I think some posters are
trying to fit the Windows model on this editor.

oh, that asian thing.  I don't/didn't even think of questioning the
way Emacs was built or designed when I first started.  

Emacs.  Learn it.  So I started learning.

This is starting to sound a bit racist and I don't think I got my
point across well too, so I'll stop.

 sivaram
 --

To say its already too complex is silly. You only need to be aware of
the features YOU need.

I think emacs suffers from the old dilemma of trying to be too many
things, almost none of them the best.  slrn is a better newsreader,
irssi is a better IRC client, bash is a better shell.  I use emacs cuz
I like the convenience of a file mgr and editor seamlessly integrated
into one app.  Nobody does this better than emacs, IMO.  

I'm also glad you are happy with the documentation.  As someone who is
actually pretty good at reading manuals and even has some experience
as a technical writer, I think it leaves a lot to be desired and is
often needlessly vague and confusing and assumes too much of the
reader.

I realize emacs would be much more useful if I was a programmer,
particularly a lisp programmer, but I'm not.  Perhaps, one day, I will
be, though not likely.  ;)

nb

--
vi --the heart of evil!
Support labeling GMOs
<http://www.labelgmos.org/>

Regarding bloat, an analogy: if all you ever need is one specific knife blade, a Swiss Army Knife will seem to have a lot of bloat.

Cheers,
Mark

http://www.gnu.org/gnu/rms-lisp.html

    It was Bernie Greenberg, who discovered that it was (5). He wrote a
    version of Emacs in Multics MacLisp, and he wrote his commands in
    MacLisp in a straightforward fashion. The editor itself was written
    entirely in Lisp. Multics Emacs proved to be a great success —
    programming new editing commands was so convenient that even the
    secretaries in his office started learning how to use it. They used
    a manual someone had written which showed how to extend Emacs, but
    didn't say it was a programming. So the secretaries, who believed
    they couldn't do programming, weren't scared off. They read the
    manual, discovered they could do useful things and they learned to
    program.

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

There's a part of me that feels like funding things like "improving
emacs" would be better suited to an organization that is capable of
commissioning developers and/or paying contributing devs for their work
than crowdfunding.

nb  

--
vi --the heart of evil!
Support labeling GMOs
<http://www.labelgmos.org/>

Finally got the domestic side under control. I look after my mother
with Alzheimer's so i needed to get the car sorted to get her
medication. The head gasket had gone and on these cars you've got to
take the engine out... which involves quite a bit of work.

On to emacs.

IT experience: used to do some programming in the 90's and used
wordstar for editing but have an engineering degree not computing.
Ideal choice for me would be to use Joe or E3 editors but they don't
do bookmarks so i was thinking of Vim or emacs. Been using linux
ubuntu for about 4 years and about 18 months ago changed to xubuntu...
just like the minimal approach switching before Unity came along. Have
tried other distros but prefer apt package management. I know my way
around xubuntu fairly well although i'm not as technical as a
programmer - couldn't call myself a ' geek'.

OS: currently using xubuntu 10.04 with emacs 23 installed although i'm
just about to install  12.04 on a new pc which will have emacs 24. I'm
hoping to set things up before i switch over to the new pc.

config files: .emac, .emac.d [i know about hidden files but there are
just comments in these both are bare]..emac.d appears to have an
'auto-save' directory and nothing there.

For me the requirements are; bookmarks, word count, split windows,
wordwrap (linebreak i think it's called (but not saving in that form
like nano/pico does)) if possible to remove some of the programming
features and things like calculator in order to have a faster app for
using with Alpine mail. [I know one can use MH but i don't know that
it's as fast as Alpine - i did have a look at it about a year ago but
i got lost somewhere setting it up].

Hope that's enough info for the moment.

thanks
james