Re: Emacs users a dying breed?

Re: Emacs users a dying breed?

[Pascal J. Bourguignon]

S Boucher <stbya@yahoo.com> writes:

> I've been using emacs since as far back as 18.59.  Still use it daily.
>
> However, I often wonder where Emacs is heading.  Most places I work,
> I'm in the minority - and that's an understatement - as an Emacs user.
>
> I learned Lisp because of Emacs and it's a cool language, but almost
> no one cares to learn Lisp.
>
> I can't live without Emacs, but in some areas Emacs tend to be
> lacking.
>
> As I just noticed that Emacs 24 is now stable it still amazes me that
> there's still a lot of development going on, considering my sense of
> isolation as an Emacs user, and the impression that Emacs users is a
> dying breed.
>
> Since this is a help group, am I required to end with a question mark?
> :-)

All the people who matter do use emacs.

It's not so much that there are not a lot of emacs users, as that there
are a lot of computer users in general.   When you increase the number
of computer users up to the population of the planet, you cannot expect
emacs users to increase proportionnaly.   So yes, in a random
group of people, it's almost certain you will be the only emacs user.
But in absolute number there are a lot of emacs users, and enough to
feed its continuing develpment.


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

Re: Emacs users a dying breed?

[djc]

Using emacs for more than 30 years.  The emacs users I know are among the 
most imaginative and competent people I know.  Like many who read this 
list, they *use* the things that distinguish emacs from other editors: 
extensibility, macros, network access, subshells, process control, and the 
many available environments (by which I mean to include mail, Usenet, IDEs, 
etc.).

I'm deeply appreciative of the people who continue to work on emacs.  I 
couldn't live without it, and if development ever comes to a halt, I'll 
probably just keep using the last version forever.

djc

Re: Emacs users a dying breed?

[Pascal J. Bourguignon]

djc <newsg@resiak.org> writes:

> Using emacs for more than 30 years.  The emacs users I know are among
> the most imaginative and competent people I know.  Like many who read
> this list, they *use* the things that distinguish emacs from other
> editors: extensibility, macros, network access, subshells, process
> control, and the many available environments (by which I mean to
> include mail, Usenet, IDEs, etc.).
>
> I'm deeply appreciative of the people who continue to work on emacs.
> I couldn't live without it, and if development ever comes to a halt,
> I'll probably just keep using the last version forever.

We'll just keep maintaining it ourselves.


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

Re: Emacs users a dying breed?

[Ken Goldman]

On 6/18/2012 5:32 AM, djc wrote:
>
> I'm deeply appreciative of the people who continue to work on emacs.
> I couldn't live without it, and if development ever comes to a halt,
> I'll probably just keep using the last version forever.

I agree.  It's been stable for as long as I can remember.

For me, the big change came at 19 (X windows support and colors).  I 
think that was when the Windows version came along as well.  Everything 
after that was polish, since I don't use international character sets or 
images.

Re: Emacs users a dying breed?

[rusi]

Thanks for asking this question -- its of much concern to me also.

On Jun 18, 7:32 am, S Boucher <st...@yahoo.com> wrote:
> I've been using emacs since as far back as 18.59.  Still use it daily.


I started gnu-emacs in 93 or so (must have been version
19.something).  Earlier ('88) with pc-scheme I used edwin which was
like a cut-down emacs.

>
> However, I often wonder where Emacs is heading.  Most places I work, I'm in the minority - and that's an understatement - as an Emacs user.
>
> I learned Lisp because of Emacs and it's a cool language, but almost no one cares to learn Lisp.
>
> I can't live without Emacs, but in some areas Emacs tend to be lacking.
>
> As I just noticed that Emacs 24 is now stable it still amazes me that there's still a lot of development going on, considering my sense of isolation as an Emacs user, and the impression that Emacs users is a dying breed.
>
> Since this is a help group, am I required to end with a question mark? :-)
>
> Regards,

Do you think it may be good to trifurcate your 'question-mark' into
these 3?
1. Revitalizing the emacs user base
2. Revitalizing the developer base
3. In the light of the huge changes in technology and 'demographic
profile' of computers and their usage from 1980s to now, rethinking
the priorities/direction of emacs

Re: Emacs users a dying breed?

[Tom]

rusi <rustompmody <at> gmail.com> writes:

> 
> Do you think it may be good to trifurcate your 'question-mark' into
> these 3?
> 1. Revitalizing the emacs user base
> 2. Revitalizing the developer base
> 3. In the light of the huge changes in technology and 'demographic
> profile' of computers and their usage from 1980s to now, rethinking
> the priorities/direction of emacs
> 
> 

There were discussions about this in the past. Apparently, the emacs
developers consider attracting more users/developers less of a priority
than keeping emacs as it is, that is they are not willing to overhaul 
emacs just to attract users who are used to modern IDEs.

http://thread.gmane.org/gmane.emacs.devel/126892

Re: Emacs users a dying breed?

[Jeremiah Dodds]

Tom <adatgyujto@gmail.com> writes:

> rusi <rustompmody <at> gmail.com> writes:
>
>> 
>> Do you think it may be good to trifurcate your 'question-mark' into
>> these 3?
>> 1. Revitalizing the emacs user base
>> 2. Revitalizing the developer base
>> 3. In the light of the huge changes in technology and 'demographic
>> profile' of computers and their usage from 1980s to now, rethinking
>> the priorities/direction of emacs
>> 
>> 
>
> There were discussions about this in the past. Apparently, the emacs
> developers consider attracting more users/developers less of a priority
> than keeping emacs as it is, that is they are not willing to overhaul 
> emacs just to attract users who are used to modern IDEs.
>
> http://thread.gmane.org/gmane.emacs.devel/126892

I think it's more like "attracting more users is less of a priority than
appealing to what others are used to", there's plenty of improvement and
development of Emacs going on.

Re: Emacs users a dying breed?

[Tom]

Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
> 
> I think it's more like "attracting more users is less of a priority than
> appealing to what others are used to", there's plenty of improvement and
> development of Emacs going on.
> 

Yes, but if we take Google Trends as an indicator interest in Emacs
is decreasing:

http://www.google.com/trends/?q=emacs

Shouldn't it be a concern? Shouldn't those kinds of improvements
be given more priority which can increase the interest in Emacs?

Re: Emacs users a dying breed?

[Bastien]

Tom <adatgyujto@gmail.com> writes:

> Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
>> 
>> I think it's more like "attracting more users is less of a priority than
>> appealing to what others are used to", there's plenty of improvement and
>> development of Emacs going on.
>> 
>
> Yes, but if we take Google Trends as an indicator interest in Emacs
> is decreasing:
>
> http://www.google.com/trends/?q=emacs
>
> Shouldn't it be a concern? 

I don't think so.  The decrease is relative to the rest of available
requests/content, which weight and diversity is rapidly increasing.

BTW "Eclipse IDE" is decreasing too:

  http://www.google.com/trends/?q=eclipse+ide

-- 
 Bastien

Re: Emacs users a dying breed?

[Andreas Röhler]

Am 22.06.2012 13:07, schrieb Bastien:
> Tom <adatgyujto@gmail.com> writes:
>
>> Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
>>>
>>> I think it's more like "attracting more users is less of a priority than
>>> appealing to what others are used to", there's plenty of improvement and
>>> development of Emacs going on.
>>>
>>
>> Yes, but if we take Google Trends as an indicator interest in Emacs
>> is decreasing:
>>
>> http://www.google.com/trends/?q=emacs
>>
>> Shouldn't it be a concern?
>
> I don't think so.  The decrease is relative to the rest of available
> requests/content, which weight and diversity is rapidly increasing.
>
> BTW "Eclipse IDE" is decreasing too:
>
>    http://www.google.com/trends/?q=eclipse+ide
>

so what does vim better then Emacs?

Re: Emacs users a dying breed?

[James Freer]

> so what does vim better then Emacs?

I've just read through this topic's threads. I'd like to make the
following points. Firstly i use a text editor for editing writing text
as an author of several newsletters not as a programmer. Recently i
decided to have a look at emacs and vi/vim as i've been using gedit,
bluefish and one or two other GUI editors.

Several of you have made the point emacs is declining on google
trends... i don't think that's fair. Try vim it is also declining...
yet nvi is level and vi is increasing, bluefish decreasing...gedit i
can't remember now. How has google trends worked out it's statistics?

My uses are different to those of a programmer. I need linebreak [word
line wrapping or softwrap i think it's sometimes called], spell
checking, word count, auto indent, and bookmarking. Basics in fact and
yet few editors that can actually do this. Just Jedit, bluefish,
gedit, vim and emacs. Also use alpine for mail so want to use the
alternative editor rather than pico. Not that i'm knocking pico - it
has a lovely feature that few editors have... when getting towards the
bottom of the screen it automatically scrolls up half a screen - for
writing that's lovely.

Emacs and vim do what i want. Emacs i struggle with as it is still
slow if using with alpine and the VM and Rmail take too long to set up
[for me... bit like trying to set up Mutt - managed to do it and then
forgot what i did and got fed up with it]. For me emacs is large does
a lot well and does a lot badly. mg - a light version of emacs doesn't
do quite enough. The emacs book is still quite hard to follow and that
lets emacs down - i even tried xemacs and it just flickered and it
seems they haven't moved forward with that project. VIm  it has the
vimbook and it's very good - if someone wants to learn they want to
get on with it... that is much in it's favour. But i agree with what
folk have said - a modal editor is an 'odd animal'. Emacs is a bit
like Jedit to many it's impregnable which puts folk off.

I wish a lite version of emacs was available that left out some of the
bloat to be honest. Forget email, calendar etc things which it does
badly. vim/vi gets it's popularity as it's easier to get started on...
albeit with this modal setup. I used to use wordstar and so you could
say my natural choice would be Joe but it doesn't do bookmarks that
well and other things i need. Nano is a very odd set up in that the
linebreak works but then you can't convert a file back to continuous
lines.

What do i use at present while i'm still trying to get used to vim or
emacs - pico for email and bluefish. Both vim and emacs development
have gone down strange routes and yet both are popular.

james

give emacs --daemon / emacsclient a try (was: Re: Emacs users a dying breed?)

[Gregor Zattler]

Hi James,
* James Freer <jessejazza@gmail.com> [25. Jun. 2012]:
> Emacs i struggle with as it is still slow if using with alpine
> and the VM and Rmail take too long to set up [for me... bit
> like trying to set up Mutt - managed to do it and then forgot
> what i did and got fed up with it].

You know you can start 

emacs --daemon 

and later connect to it with

emacsclient

?  Then the editor you call (e.g. via the EDITOR or VISUAL
environment variables) ist emacsclient.  Almost no startup time
any more.

Ciao; Gregor

Emacs for writers (was Emacs users a dying breed?)

[rusi]

On Jun 25, 4:19 am, James Freer <jesseja...@gmail.com> wrote:
<snipped>
> What do i use at present while i'm still trying to get used to vim or
> emacs - pico for email and bluefish. Both vim and emacs development
> have gone down strange routes and yet both are popular.
>
> james

Ok James lets see if we can get you off the ground with emacs.
To start with are you on linux? If not whats your OS?
Next whats your emacs version? To find out do M-x emacs-version RETURN
where M-x is emacs-funnyspeak for Alt-x or Escape-x.
Next whats in your init file? Beginners are usually recommended to
use .emacs (note the .)
I recommend .emacs.d/init.el
If all this is trivial to you please excuse; no intent to be
patronizing here; just dont know at what level you are stuck

Re: Emacs for writers (was Emacs users a dying breed?)

[James Freer]

On 25 June 2012 03:58, rusi <rustompmody@gmail.com> wrote:
> On Jun 25, 4:19 am, James Freer <jesseja...@gmail.com> wrote:
> <snipped>
>> What do i use at present while i'm still trying to get used to vim or
>> emacs - pico for email and bluefish. Both vim and emacs development
>> have gone down strange routes and yet both are popular.
>>
>> james
>
> Ok James lets see if we can get you off the ground with emacs.
> To start with are you on linux? If not whats your OS?
> Next whats your emacs version? To find out do M-x emacs-version RETURN
> where M-x is emacs-funnyspeak for Alt-x or Escape-x.
> Next whats in your init file? Beginners are usually recommended to
> use .emacs (note the .)
> I recommend .emacs.d/init.el
> If all this is trivial to you please excuse; no intent to be
> patronizing here; just dont know at what level you are stuck

Rusi

I really appreciate your reply and offer of help. At present i've got
to get a car sorted out so i'll leave it for a couple of days and then
i can be focussed and look these things up.

thanks
james

Re: Emacs for writers (was Emacs users a dying breed?)

[James Freer]

On 25 June 2012 10:38, James Freer <jessejazza@gmail.com> wrote:
> On 25 June 2012 03:58, rusi <rustompmody@gmail.com> wrote:
>> On Jun 25, 4:19 am, James Freer <jesseja...@gmail.com> wrote:
>> <snipped>
>>> What do i use at present while i'm still trying to get used to vim or
>>> emacs - pico for email and bluefish. Both vim and emacs development
>>> have gone down strange routes and yet both are popular.
>>>
>>> james
>>
>> Ok James lets see if we can get you off the ground with emacs.
>> To start with are you on linux? If not whats your OS?
>> Next whats your emacs version? To find out do M-x emacs-version RETURN
>> where M-x is emacs-funnyspeak for Alt-x or Escape-x.
>> Next whats in your init file? Beginners are usually recommended to
>> use .emacs (note the .)
>> I recommend .emacs.d/init.el
>> If all this is trivial to you please excuse; no intent to be
>> patronizing here; just dont know at what level you are stuck
>
> Rusi
>
> I really appreciate your reply and offer of help. At present i've got
> to get a car sorted out so i'll leave it for a couple of days and then
> i can be focussed and look these things up.
>
> thanks
> james

Hi Rusi

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

Re: Emacs for writers (was Emacs users a dying breed?)

[rusi]

On Jun 27, 2:47 am, James Freer <jesseja...@gmail.com> wrote:
> On 25 June 2012 10:38, James Freer <jesseja...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 25 June 2012 03:58, rusi <rustompm...@gmail.com> wrote:
> >> On Jun 25, 4:19 am, James Freer <jesseja...@gmail.com> wrote:
> >> <snipped>
> >>> What do i use at present while i'm still trying to get used to vim or
> >>> emacs - pico for email and bluefish. Both vim and emacs development
> >>> have gone down strange routes and yet both are popular.
>
> >>> james
>
> >> Ok James lets see if we can get you off the ground with emacs.
> >> To start with are you on linux? If not whats your OS?
> >> Next whats your emacs version? To find out do M-x emacs-version RETURN
> >> where M-x is emacs-funnyspeak for Alt-x or Escape-x.
> >> Next whats in your init file? Beginners are usually recommended to
> >> use .emacs (note the .)
> >> I recommend .emacs.d/init.el
> >> If all this is trivial to you please excuse; no intent to be
> >> patronizing here; just dont know at what level you are stuck
>
> > Rusi
>
> > I really appreciate your reply and offer of help. At present i've got
> > to get a car sorted out so i'll leave it for a couple of days and then
> > i can be focussed and look these things up.
>
> > thanks
> > james
>
> Hi Rusi
>
> 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.

O my!

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

Geek enough to have an intelligible and intelligent conversation

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

I guess you are misspelling these?  Should be .emacs and .emacs.d/
init.el
If the first is useless throw it out (ie rm .emacs) If you have
something useful there 'mv' it to the second.

Once thats done make sure its 'reached.'
I do that by making an obvious syntax error -- eg a single opening '('
without closing ')'  and make sure you get a lisp syntax error on
starting emacs. [Usually this just works on linux and gives all kinds
of hell on windows]
There are many different things to set up specifically for your needs
-- many of them I dont know about.
For now lets use one example -- wordwrap/linebreak -- to understand
the workflow.
In emacs there are two commands longlines-mode and visual-line-mode
for this.
To try these do M-x (I guess you know M-x is Alt-x)
longlines-modeRET
Start playing with tab-expansion: type longTAB and see it expand etc
You turn it off by running the same command again.
Try both; the current fashion is visual-line-mode but it does not seem
t respect fill-column as longlines does.

Play around with both and decide which you like.
Now comes the next stage -- getting it into your standard config --
ie .emacs.d/init.el.
Now what goes in there is elisp corresponding to the command you want.
If say you want the command longlines then the corresponding elisp is
this line

(longlines-mode)

But its important to understand how to get there.
Do
C-h f
You should see the cursor at the bottom (its called the minibuffer)
Type longlines-mode (get used to using tab expansion)
RET
You should see something like

longlines-mode is an interactive compiled Lisp function in
`longlines.el'.
---------------------------------------------
(longlines-mode &optional ARG)

Toggle Long Lines mode.
In Long Lines mode, long lines are wrapped if they extend beyond
`fill-column'.  The soft newlines used for line wrapping will not
show up when the text is yanked or saved to disk.

If the variable `longlines-auto-wrap' is non-nil, lines are
automatically
wrapped whenever the buffer is changed.  You can always call
`fill-paragraph' to fill individual paragraphs.

If the variable `longlines-show-hard-newlines' is non-nil, hard
newlines
are indicated with a symbol.

--------------------------------------------------
Read it
Whats the ARG?? God knows -- seems to be a doc-bug (Interesting
considering this thread :-) )
Anyhow its optional so we can try dropping it and so we get from the
'command'
M-x longlines-mode
to the elisp
(longlines-mode)

Put it into your emacs and restart emacs.  Check that its now your own
new personal default.
----------------------------------------------------
There are other stops in the hacking and checking of emacs/elisp like
using eval-expression, using the scratch buffer etc.  But for now this
much should be just right.

Get this much running and post back here preferably with specific
questions on where you are stuck.

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

Re: Emacs users a dying breed?

[Tom]

Bastien <bzg <at> gnu.org> writes:
> 
> BTW "Eclipse IDE" is decreasing too:
> 
>   http://www.google.com/trends/?q=eclipse+ide
> 

The search "Eclipse IDE" does not give a good measurement,
because it's unlikely there is generally less interest in
Eclipse than in Emacs:

http://www.google.com/trends/?q=eclipse+ide,emacs&ctab=0&geo=all&date=all&sort=0

Re: Emacs users a dying breed?

[Jay Belanger]

Tom <adatgyujto@gmail.com> writes:
...
> The search "Eclipse IDE" does not give a good measurement,
> because it's unlikely there is generally less interest in
> Eclipse than in Emacs:

Perhaps I'm misreading this, but it looks like you disregard this
because you don't like the result?

Re: Emacs users a dying breed?

[Tom]

Jay Belanger <jay.p.belanger <at> gmail.com> writes:

> 
> 
> Tom <adatgyujto <at> gmail.com> writes:
> ...
> > The search "Eclipse IDE" does not give a good measurement,
> > because it's unlikely there is generally less interest in
> > Eclipse than in Emacs:
> 
> Perhaps I'm misreading this, but it looks like you disregard this
> because you don't like the result?
> 

I would love this result if this were really the case, but this
does not take into account the mentions of Eclipse without the
word IDE.

Here's the same comparison without using the word IDE, but removing
results with the word SOLAR (solar eclipse), TWILIGHT 
(something to do with the novel), COMICS (Eclipse comics), NASA,
GPS:

http://www.google.com/trends/?q=eclipse+-solar+-twilight+-comics+-nasa+-gps
+,emacs&ctab=0&geo=all&date=all&sort=0

Feel free to remove additional words which you feel are irrelevant 
for Eclipse and test the result.

Re: Emacs users a dying breed?

[John Bokma]

Tom <adatgyujto@gmail.com> writes:

> Jay Belanger <jay.p.belanger <at> gmail.com> writes:
>
>> 
>> 
>> Tom <adatgyujto <at> gmail.com> writes:
>> ...
>> > The search "Eclipse IDE" does not give a good measurement,
>> > because it's unlikely there is generally less interest in
>> > Eclipse than in Emacs:
>> 
>> Perhaps I'm misreading this, but it looks like you disregard this
>> because you don't like the result?
>> 
>
> I would love this result if this were really the case, but this
> does not take into account the mentions of Eclipse without the
> word IDE.
>
> Here's the same comparison without using the word IDE, but removing
> results with the word SOLAR (solar eclipse), TWILIGHT 
> (something to do with the novel), COMICS (Eclipse comics), NASA,
> GPS:
>
> http://www.google.com/trends/?q=eclipse+-solar+-twilight+-comics+-nasa+-gps
> +,emacs&ctab=0&geo=all&date=all&sort=0
>
> Feel free to remove additional words which you feel are irrelevant 
> for Eclipse and test the result.

https://www.google.com/search?q=eclipse%20ide%20sucks
About 209,000 results (0.11 seconds)

https://www.google.com/search?q=emacs%20sucks
About 237,000 results

Which clearly shows that Emacs is the better editor /and/ you can vacuum
your house with it.

-- 
John Bokma                                                               j3b

Blog: http://johnbokma.com/        Perl Consultancy: http://castleamber.com/
Perl for books:    http://johnbokma.com/perl/help-in-exchange-for-books.html

Re: Emacs users a dying breed?

[Jeremiah Dodds]

Tom <adatgyujto@gmail.com> writes:

> Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
>> 
>> I think it's more like "attracting more users is less of a priority than
>> appealing to what others are used to", there's plenty of improvement and
>> development of Emacs going on.
>> 
>
> Yes, but if we take Google Trends as an indicator interest in Emacs
> is decreasing:
>
> http://www.google.com/trends/?q=emacs
>
> Shouldn't it be a concern? Shouldn't those kinds of improvements
> be given more priority which can increase the interest in Emacs?

No, why should Emacs and users and developers of Emacs be concerned with
increasing the interest in Emacs? It's already a name that practically
everyone who writes software has heard of, and the type of people that
like it stick with it.

Re: Emacs users a dying breed?

[Andreas Röhler]

Am 22.06.2012 13:17, schrieb Jeremiah Dodds:
> Tom <adatgyujto@gmail.com> writes:
>
>> Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
>>>
>>> I think it's more like "attracting more users is less of a priority than
>>> appealing to what others are used to", there's plenty of improvement and
>>> development of Emacs going on.
>>>
>>
>> Yes, but if we take Google Trends as an indicator interest in Emacs
>> is decreasing:
>>
>> http://www.google.com/trends/?q=emacs
>>
>> Shouldn't it be a concern? Shouldn't those kinds of improvements
>> be given more priority which can increase the interest in Emacs?
>
> No, why should Emacs and users and developers of Emacs be concerned with
> increasing the interest in Emacs? [ ... ]

Because it might exists reasons for the decline, which are to discuss before it's to late.
IMO it is late already...

Cheers,

Andreas

Re: Emacs users a dying breed?

[Richard Riley]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Am 22.06.2012 13:17, schrieb Jeremiah Dodds:
>> Tom <adatgyujto@gmail.com> writes:
>>
>>> Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
>>>>
>>>> I think it's more like "attracting more users is less of a priority than
>>>> appealing to what others are used to", there's plenty of improvement and
>>>> development of Emacs going on.
>>>>
>>>
>>> Yes, but if we take Google Trends as an indicator interest in Emacs
>>> is decreasing:
>>>
>>> http://www.google.com/trends/?q=emacs
>>>
>>> Shouldn't it be a concern? Shouldn't those kinds of improvements
>>> be given more priority which can increase the interest in Emacs?
>>
>> No, why should Emacs and users and developers of Emacs be concerned with
>> increasing the interest in Emacs? [ ... ]
>
> Because it might exists reasons for the decline, which are to discuss before it's to late.
> IMO it is late already...

Agreed. Some basic tidying and emacs would/might get a new lease of
life. mixed mode, java, auto completion, some tutorial on how to actually
use cedet without a degree in compiler design :)

Re: Emacs users a dying breed?

[Jonathan Groll]

On Fri, 22 Jun 2012 14:21:27 +0200, Richard Riley <rileyrg@gmail.com> wrote:
> Agreed. Some basic tidying and emacs would/might get a new lease of
> life. mixed mode, java, auto completion, some tutorial on how to actually
> use cedet without a degree in compiler design :)
> 

Or simply shipping a version with a lot of the elisp packages already
activated and a more pleasant set of defaults. Something like

https://github.com/technomancy/emacs-starter-kit

Cheers,
Jonathan
--
jjg: Jonathan J. Groll : groll co za
has_one { :blog => "http://bloggroll.com" }
"Men always want to be a woman's first love. Women have a more subtle
 instinct: What they like is to be a man's last romance." ~ Oscar Wilde

Re: Emacs users a dying breed?

[Philipp Haselwarter]

I very much disagree, one of the things emacs is most frequently accused
of is bloat. Overhauling some of the defaults might be worth discussing,
but adding even more code to the core distribution seems to be the wrong
approach. IMO Emacs should focus on providing the core - an editing
engine and a lisp interpreter - and let the user decide which plugins he
wants to run.

I'd even go as far as claiming that currently there's already too much
stuff included by default. 24.1 has package.el included, there's no good
reason to ship every copy of emacs with several mail clients, org-mode,
two irc clients, and many other very domain-specific features. Don't
misinterpret this, I'm glad these packages exist and use them heavily,
but most occasional emacs users I know don't.

The question "what should Emacs be?" has been raised many times, and no
consensus could be reached. So cutting it down to the core and letting
each user decide seems like a reasonable consequence.


-- 
Philipp Haselwarter

Re: Emacs users a dying breed?

[Teemu Likonen]

Philipp Haselwarter [2012-06-23 13:33:30 +0200] wrote:

> I very much disagree, one of the things emacs is most frequently
> accused of is bloat. Overhauling some of the defaults might be worth
> discussing, but adding even more code to the core distribution seems
> to be the wrong approach. IMO Emacs should focus on providing the core
> - an editing engine and a lisp interpreter - and let the user decide
> which plugins he wants to run.

The Emacs distribution (.tar.gz) contains all bells and whistles but not
everything is loaded into memory. What is loaded by default is pretty
much only the Emacs Lisp interpreter and the editing core and autoload
definitions for other features.

And Emacs is a very light-weight program by today's standards. I think
it was bloated in the 80's.

From the point of view of code maintenance it might be good idea to have
more code on a (semi-)official package repository. If I maintained an
official Emacs package I'd prefer using my own version control system
etc. and just upload releases to official package archive.

Re: Emacs users a dying breed?

[Philipp Haselwarter]

On Sat, Jun 23 2012 14:05 (@1340453147), Teemu Likonen wrote:

> Philipp Haselwarter [2012-06-23 13:33:30 +0200] wrote:
>
>> I very much disagree, one of the things emacs is most frequently
>> accused of is bloat. Overhauling some of the defaults might be worth
>> discussing, but adding even more code to the core distribution seems
>> to be the wrong approach. IMO Emacs should focus on providing the core
>> - an editing engine and a lisp interpreter - and let the user decide
>> which plugins he wants to run.
>
> The Emacs distribution (.tar.gz) contains all bells and whistles but not
> everything is loaded into memory. What is loaded by default is pretty
> much only the Emacs Lisp interpreter and the editing core and autoload
> definitions for other features.

I don't know for a fact what is loaded by default, but the distribution
surely contains a lot of elisp programs that are not of interest for
most users.

> And Emacs is a very light-weight program by today's standards. I think
> it was bloated in the 80's.

On my 64bit linux system the emacs executable weights in at 13M, feel
free to comparing that to any other interpreter.

> From the point of view of code maintenance it might be good idea to have
> more code on a (semi-)official package repository. If I maintained an
> official Emacs package I'd prefer using my own version control system
> etc. and just upload releases to official package archive.

ELPA allows you to do just that. Maybe some of the packages distributed
with emacs would see some more attention and patches if they had their
own repos and communities instead of living in the emacs tree.

-- 
Philipp Haselwarter

Re: Emacs users a dying breed?

[Eli Zaretskii]

> From: Philipp Haselwarter <philipp@haselwarter.org>
> Date: Sat, 23 Jun 2012 14:35:58 +0200
> 
> > The Emacs distribution (.tar.gz) contains all bells and whistles but not
> > everything is loaded into memory. What is loaded by default is pretty
> > much only the Emacs Lisp interpreter and the editing core and autoload
> > definitions for other features.
> 
> I don't know for a fact what is loaded by default

You can see that in loadup.el.

> but the distribution surely contains a lot of elisp programs that
> are not of interest for most users.

So what?  They are just taking some disk space, that's all.

> > And Emacs is a very light-weight program by today's standards. I think
> > it was bloated in the 80's.
> 
> On my 64bit linux system the emacs executable weights in at 13M, feel
> free to comparing that to any other interpreter.

Not because of preloaded packages; those take maybe 30% of the size.

Re: Emacs users a dying breed?

[S Boucher]

>On my 64bit linux system the emacs executable weights in at 13M, feel
>free to comparing that to any other interpreter.


For emacs 23.3, STRIPPED, it weighs in at 10M.  If you look at temacs STRIPPED, then it weighs in at 5M.

So, it all depends what you measure.

But I've always wondered what was so dramatic about that.  What would I gain if Emacs is shrunk to 1M?


I kind of like Emacs helping me with vc (svn, git, p4, rcs, cvs).  I kind of like being able to diff revision without having to use another tool.  Emacs seems the right place to do this.

I wish emacs' gdb ui was better (I haven't checked emacs 24 yet).

It's nice to be able to write some lisp to massage/reformat some log output.  I've done this with a log file that had some unformated xml.  Search for the xml, create an indirect buffer, switch to xml mode, and reindent the (indirect) buffer, and get rid of the indirect buffer, and voila! a readable log file :-) (well, relatively speaking, since xml is not exactly human readable :-))

I've stopped using Emacs for mail and news a long time ago. mail and news have become too multimedia oriented for emacs to do things well.

Re: Emacs users a dying breed?

[suvayu ali]

Hi Teemu,

On Sat, Jun 23, 2012 at 2:05 PM, Teemu Likonen <tlikonen@iki.fi> wrote:
> And Emacs is a very light-weight program by today's standards. I think
> it was bloated in the 80's.
>

That might be true when compared with most of the modern gui editors,
but Vim seems to be much more effective in being light weight.

> From the point of view of code maintenance it might be good idea to have
> more code on a (semi-)official package repository. If I maintained an
> official Emacs package I'd prefer using my own version control system
> etc. and just upload releases to official package archive.

This would be a great change IMO. package.el already provides the
background for it.

Just my 2 cents.

-- 
Suvayu

Open source is the future. It sets us free.

Re: Emacs users a dying breed?

[Ken Goldman]

On 6/23/2012 7:33 AM, Philipp Haselwarter wrote:
> I very much disagree, one of the things emacs is most frequently accused
> of is bloat. ...
> I'd even go as far as claiming that currently there's already too much
> stuff included by default.

Arguments against:

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.

Re: Emacs users a dying breed?

[S Boucher]

----- Original Message -----

> Agreed. Some basic tidying and emacs would/might get a new lease of
> life. mixed mode, java, auto completion, some tutorial on how to actually
> use cedet without a degree in compiler design :)

I think the biggest problem with cedet is not cedet itself.

When you create a VisualStudio project, VS controls everything, and therefore it is easy to hook into the compiler to maintain the xref DBs.

When you have an endless number of build systems out there, it's a lost cause for cedet to be tightly integrated with the build system (which is pretty much a requirement to have decent xref facilities).  I don't see how a simple tutorial can be written on how to setup cedet.

You can probably set things up well on your own little project, but try to setup cedet on top of, say, webkit... good luck (heck, webkit itself has more than one build system :-)).

Re: Emacs users a dying breed?

[Thien-Thi Nguyen]

() Andreas Röhler <andreas.roehler@easy-emacs.de>
() Fri, 22 Jun 2012 14:03:29 +0200

   Because it might exists reasons for the decline,
   which are to discuss before it's to late.

Emacs is self-documenting, so perhaps that aspect
has improved such that the (IMHO) meaningless metric
of "query term frequency" becomes even more so.

If a day arrives when no one asks Google about Emacs,
i would do a little dance and drink a little water...

Re: Emacs users a dying breed?

[Andreas Röhler]

Am 22.06.2012 14:46, schrieb Thien-Thi Nguyen:
> () Andreas Röhler <andreas.roehler@easy-emacs.de>
> () Fri, 22 Jun 2012 14:03:29 +0200
>
>     Because it might exists reasons for the decline,
>     which are to discuss before it's to late.
>
> Emacs is self-documenting, so perhaps that aspect
> has improved such that the (IMHO) meaningless metric
> of "query term frequency" becomes even more so.
>
> If a day arrives when no one asks Google about Emacs,
> i would do a little dance and drink a little water...
>


While awaiting the day, let me tell you the sad story of a FUN company's decease, which declared it's code
free while adopting the mistake.

All the tools Eclipse provides existed in Emacs for years before: ECB, CEDET, projects and the like.
What slowed down it's integration?
A shortage of fresh water? :)

Cheers,

Andreas

RE: Emacs users a dying breed?

[Doug Lewan]

No, emacs users are not a dying breed.
Well, emacs is not an endangered species; it exceeds every potential competitor in too many ways.

Here are a few points.

1. It is ubiquitous. (This is largely true of all Free Software.)
   No matter what platform I work on emacs is there.
   In the last 10 years I've had the chance to work on 
       • 3 flavors of Solaris
       • 2 flavors of HP-UX
       • AIX
       • CYGWIN
       • Windows Vista and Windows 7
   About 10 years ago I counted the different OSes and versions thereof
   where emacs ran and I think it was over 200.
   Nothing non-Free can match that.

2. It's an editor for just about everything you need.
   A quick glance in lisp/progmodes gets about 80 programming languages.
   There's also LaTex, HTML, etc., etc.
   (Even troff! Hey! It's free to ship support code. Why not do it?)

3. It's comes with a zillion application.
   Calendar, organizers, a file manager, etc.

4. There are a zillion more applications freely available too.

5. It's consistent.¹
   If I change version control systems my UI doesn't change.
   When I change debuggers my UI doesn't change.
   When I want help for another Free application, Info works just the same.

6. The help is integrated.
   I don't mean when you click on "Help"
   you get help in a different documentation system.
   (A browser, Word, whatever. That's not integration.)
   You get it right there.
   No change. No moving focus. No distraction with the mouse.

7. It's its own development environment.
   As with Help, it's fully integrated.²

8. And it's the most portable working/development environment ever.
   If you write an application for emacs on Windows,
   it'll still run on AIX.

9. To incorporate all of the above:
   It's hardly just an editor -- it's an operating system.
   Windows, HP-UX, Linux, whatever is your BIOS if you're an emacs user.
   Using it makes you one of the most flexible, adaptable people
   in the computer world by removing the unnecessary distractions
   that our industry calls "innovation" (no matter how trivial they are).

Thank you for your time.

I know I've missed much.
The flexibility and responsiveness of the development community.
International support.
Much, much more. Please add.

________________________________________________________________
¹It's a little clunky, but wildly consistent.
I'd rather have clunky consistency than 10 super-modern variations
all of which are slightly different.
If you're going to do something differently,
then please, /please/, PLEASE do it much, much better.
Give me a big reason to want your difference.

²OK, I admit it. To say that emacs Lisp is integrated with emacs
is not just and understatement, it's upside down.

Re: Emacs users a dying breed?

[Tom]

Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
> 
> No, why should Emacs and users and developers of Emacs be concerned with
> increasing the interest in Emacs? It's already a name that practically
> everyone who writes software has heard of, and the type of people that
> like it stick with it.
> 

The problem is the decreasing interest indicates that emacs is a
less useful tool in some areas and people choose the better tool
available. People don't necessarily choose other tools, becasue
they are nice and shiny. I heard lots of time from people that
they would use Emacs if it supported Java development as well as
Eclipse.

If I had to do Android development then I'd also choose Eclipse,
because the support it gives for developing with big Java
libraries is such a big advantage that Emacs' superior text editing
cannot compensate. I've been using Emacs for more than 15 years,
but I don't use it religiously, I use it if it is best tool for
the task.

One can say emacs is still useful for developing in C and stuff
and it's true, but I'd like to use it for Android and other
development, and that's why the decreasing interest is
important, because it says Emacs lags behind the competition in
important areas.

If this lagging behind is not addressed then Emacs will become
more and more a niche tool and less of a generally useful and
capable tool which can be efficienly used for most kinds of
tasks.

Re: Emacs users a dying breed?

[Mihamina Rakotomandimby]

On 06/22/2012 04:09 PM, Tom wrote:
> If I had to do Android development then I'd also choose Eclipse,
> because the support it gives for developing with big Java
> libraries is such a big advantage that Emacs' superior text editing
> cannot compensate. I've been using Emacs for more than 15 years,
> but I don't use it religiously, I use it if it is best tool for
> the task.

Yes.

And by the way, developping for Android has some words about Emacs:
http://www.google.com/search?q=android+tutorial+emacs
http://www.google.com/search?q=emacs+android+mode

Unfortunately, I had not time to test how heavy it is compared to using 
Eclipse. The main reason: I dont use Eclipse :-).


-- 
RMA.

Issues with emacs (was Emacs users a dying breed?)

[rusi]

On Jun 18, 7:32 am, S Boucher <st...@yahoo.com> wrote:
> I've been using emacs since as far back as 18.59.  Still use it daily.
>
> However, I often wonder where Emacs is heading.

Ive been collecting some posts on this list that seemingly are
questions about emacs but in fact point to deficiencies. Does one,
two, hundred deficiencies make for a 'dying breed?'  Perhaps not and
the question of S Boucher needs to be dealt with more conceptually/
philosophically.  Unfortunately such a discussion invariably
degenerates into flaming/trolling.  So heres my bottom up list


* Intro
  Started [2011-01-08 Sat] Idea is to keep a record of emacs mailing
  list queries that are really emacs problems
* Problems
*** No package management
    http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00293.html
*** Low grade dependency management in elisp
    http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/1070abe0f19e5476#
    (change to other mailinglist)
*** CL badly integrated
    http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00288.html
*** Horizontal scrolling
    http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/686c0fa47a48a7e2#
*** elisp is a lisp-2
    http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00270.html
*** Poor customizability of Tabstop behavior
    http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00043.html
*** JDE does not work
    http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg03183.html
*** Poor Project Management
    http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg02878.html
*** Half baked server
    http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/f1c59047b8f4b294#
*** Spurious choices
***** email
      http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg03080.html
***** folding
      http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg02939.html
***** Template
***** Python
      http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg02534.html
***** merge/diff
      http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/819655b0b5a81bba#
*** Obsolete
***** read-from-minibuffer vs read-string
      http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/5925179885835e1d#

Re: Issues with emacs

[Pascal J. Bourguignon]

rusi <rustompmody@gmail.com> writes:

> On Jun 18, 7:32 am, S Boucher <st...@yahoo.com> wrote:
>> I've been using emacs since as far back as 18.59.  Still use it daily.
>>
>> However, I often wonder where Emacs is heading.
>
> Ive been collecting some posts on this list that seemingly are
> questions about emacs but in fact point to deficiencies. Does one,
> two, hundred deficiencies make for a 'dying breed?'  Perhaps not and
> the question of S Boucher needs to be dealt with more conceptually/
> philosophically.  Unfortunately such a discussion invariably
> degenerates into flaming/trolling.  So heres my bottom up list


Some are contradictory.  Eg. reproaching lisp-2 and wanting more CL
support (of course, they're not made by the same people).

lisp-2 is a good thing IMO.  
http://www.nhplace.com/kent/Papers/Technical-Issues.html


What's bad, is that the promise of having different embedded languages
in emacs failed so far.  IMO because of lack of lexical binding/closures
(but this is resolved in emacs-24), and to a lesser degree, lack of a
usable namespace system (in this case, the obarray mechanism is there to
be used by language implementors).  But with emacs-24, it could be
possible to implement a scheme, a javascript and finish the emacs-cl
implementation, java, etc, so that people could use and program emacs in
their favorite programming language.



> * Intro
>   Started [2011-01-08 Sat] Idea is to keep a record of emacs mailing
>   list queries that are really emacs problems
> * Problems
> *** No package management
>     http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00293.html
> *** Low grade dependency management in elisp
>     http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/1070abe0f19e5476#
>     (change to other mailinglist)
> *** CL badly integrated
>     http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00288.html
> *** Horizontal scrolling
>     http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/686c0fa47a48a7e2#
> *** elisp is a lisp-2
>     http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00270.html
> *** Poor customizability of Tabstop behavior
>     http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00043.html
> *** JDE does not work
>     http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg03183.html
> *** Poor Project Management
>     http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg02878.html
> *** Half baked server
>     http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/f1c59047b8f4b294#
> *** Spurious choices
> ***** email
>       http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg03080.html
> ***** folding
>       http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg02939.html
> ***** Template
> ***** Python
>       http://lists.gnu.org/archive/html/help-gnu-emacs/2010-12/msg02534.html
> ***** merge/diff
>       http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/819655b0b5a81bba#
> *** Obsolete
> ***** read-from-minibuffer vs read-string
>       http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/5925179885835e1d#

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

Re: Issues with emacs

[rusi]

On Jun 22, 8:26 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> rusi <rustompm...@gmail.com> writes:
> > On Jun 18, 7:32 am, S Boucher <st...@yahoo.com> wrote:
> >> I've been using emacs since as far back as 18.59.  Still use it daily.
>
> >> However, I often wonder where Emacs is heading.
>
> > Ive been collecting some posts on this list that seemingly are
> > questions about emacs but in fact point to deficiencies. Does one,
> > two, hundred deficiencies make for a 'dying breed?'  Perhaps not and
> > the question of S Boucher needs to be dealt with more conceptually/
> > philosophically.  Unfortunately such a discussion invariably
> > degenerates into flaming/trolling.  So heres my bottom up list
>
> Some are contradictory.  Eg. reproaching lisp-2 and wanting more CL
> support (of course, they're not made by the same people).
>
> lisp-2 is a good thing IMO.  http://www.nhplace.com/kent/Papers/Technical-Issues.html

Thanks for that link... whether it actually says that lisp-2 is better
is another matter <wink>

>
> What's bad, is that the promise of having different embedded languages
> in emacs failed so far.  IMO because of lack of lexical binding/closures
> (but this is resolved in emacs-24), and to a lesser degree, lack of a
> usable namespace system (in this case, the obarray mechanism is there to
> be used by language implementors).  But with emacs-24, it could be
> possible to implement a scheme, a javascript and finish the emacs-cl
> implementation, java, etc, so that people could use and program emacs in
> their favorite programming language.

Yes this is one of the important issues.  If emacs were programmable
in one of today's popular languages its developer-base would leap up.
I believe however that trying to implement everything within emacs
(elisp) itself is a much more ambitious project than simply providing
bridges to existing implementations (eg python via pymacs)

Re: Issues with emacs

[Pascal J. Bourguignon]

rusi <rustompmody@gmail.com> writes:

> On Jun 22, 8:26 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>> What's bad, is that the promise of having different embedded languages
>> in emacs failed so far.  IMO because of lack of lexical binding/closures
>> (but this is resolved in emacs-24), and to a lesser degree, lack of a
>> usable namespace system (in this case, the obarray mechanism is there to
>> be used by language implementors).  But with emacs-24, it could be
>> possible to implement a scheme, a javascript and finish the emacs-cl
>> implementation, java, etc, so that people could use and program emacs in
>> their favorite programming language.
>
> Yes this is one of the important issues.  If emacs were programmable
> in one of today's popular languages its developer-base would leap up.
> I believe however that trying to implement everything within emacs
> (elisp) itself is a much more ambitious project than simply providing
> bridges to existing implementations (eg python via pymacs)

It's a question of VM.

That's the reason why I'd like a rewrite of emacs (C code) into Common
Lisp: there are various CL implementations providing various different
VMs, including ix86.

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

RE: Issues with emacs (was Emacs users a dying breed?)

[Drew Adams]

> http://groups.google.com/group/gnu.emacs.help/browse_thread/th
> read/686c0fa47a48a7e2#
> *** elisp is a lisp-2

lisp-1 and lisp-2 each have their advantages.
http://www.nhplace.com/kent/Papers/Technical-Issues.html

Re: Issues with emacs (was Emacs users a dying breed?)

[Bastien]

The good news is that, whether Emacs users are a dying breed
or not, the only remedy to this hypothetical issue is to have
more Emacs developers.

Patches welcome!

-- 
 Bastien

Re: Issues with emacs (was Emacs users a dying breed?)

[Tom]

Bastien <bzg <at> gnu.org> writes:

> 
> The good news is that, whether Emacs users are a dying breed
> or not, the only remedy to this hypothetical issue is to have
> more Emacs developers.
> 

But how to have more developers. I see 3 possibilites:

1. Motivate more users to be volunteer developers? Any idea how
to do that?

2. Attracting more users. Volunteer developers are some small
percent of the active user base, so if Emacs can be mode more
attractive to users then the bigger user base will bring more
volunteer developers too. The problem is in order to be more
attractive Emacs needs new features which other editors/IDEs have
and which make users to choose those editors/IDEs instead of
Emacs, and to implement those more competitive features Emacs
needs more developers.

3. Crowdfunding. If we don't have enough volunteer developers
then we need to motivate developers with something else. For
example, paying for their work. For this model to work there
should be some public exposure of this idea, so potential
developers know they can potentially make a living while
contributing to Emacs. This kind of public exposure could be done
by RMS who could mention this development model in every
interview he gives. He has the voice which can reach lots of
ears, including potential developer ears.

Re: Issues with emacs (was Emacs users a dying breed?)

[Eric Abrahamsen]

On Sun, Jun 24 2012, Tom wrote:

> Bastien <bzg <at> gnu.org> writes:
>
>> 
>> The good news is that, whether Emacs users are a dying breed
>> or not, the only remedy to this hypothetical issue is to have
>> more Emacs developers.
>> 
>
> But how to have more developers. I see 3 possibilites:
>
> 1. Motivate more users to be volunteer developers? Any idea how
> to do that?

One possibility: if a pure-Lisp implementation of Emacs became the
"main" implementation, I wonder if many Elisp-gurus who aren't
particularly enthusiastic about C programming would be encouraged to
expand their hacking into the Emacs basics.

If the line between programming Emacs packages and programming Emacs
guts were blurred or erased altogether, I'll bet you'd get a lot more
people able and willing to contribute work on fundamentals like the
display engine or multi-threading.

Just a thought,

E

-- 
GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-06-11 on pellet

RE: Issues with emacs (was Emacs users a dying breed?)

[Drew Adams]

> One possibility: if a pure-Lisp implementation of Emacs became the
> "main" implementation, I wonder if many Elisp-gurus who aren't
> particularly enthusiastic about C programming would be encouraged to
> expand their hacking into the Emacs basics.
> 
> If the line between programming Emacs packages and programming Emacs
> guts were blurred or erased altogether, I'll bet you'd get a lot more
> people able and willing to contribute work on fundamentals like the
> display engine or multi-threading.
> 
> Just a thought,

+1

RE: Issues with emacs (was Emacs users a dying breed?)

[Ludwig, Mark]

> From: Eric Abrahamsen
> Sent: Sunday, June 24, 2012 6:38 AM
> To: help-gnu-emacs@gnu.org
> Subject: Re: Issues with emacs (was Emacs users a dying breed?)
> 
> On Sun, Jun 24 2012, Tom wrote:
> 
> > Bastien <bzg <at> gnu.org> writes:
> >
> >>
> >> The good news is that, whether Emacs users are a dying breed
> >> or not, the only remedy to this hypothetical issue is to have
> >> more Emacs developers.
> >>
> >
> > But how to have more developers. I see 3 possibilites:
> >
> > 1. Motivate more users to be volunteer developers? Any idea how
> > to do that?
> 
> One possibility: if a pure-Lisp implementation of Emacs became the
> "main" implementation, I wonder if many Elisp-gurus who aren't
> particularly enthusiastic about C programming would be encouraged to
> expand their hacking into the Emacs basics.
> 
> If the line between programming Emacs packages and programming Emacs
> guts were blurred or erased altogether, I'll bet you'd get a lot more
> people able and willing to contribute work on fundamentals like the
> display engine or multi-threading.

Perhaps in the abstract this is a good idea, but it's not at all clear to me that you want a bigger crowd of people working on either of those two areas, in particular.  They're very tender areas, and it's likely that a worker needs a lot of context in order to successfully modify these things.  Learning the context takes time and I believe our do-everything-faster culture does not particularly reward the slow learning processes necessary in order to learn complex programming contexts such as these.  Some of the context comes from bug reports.

(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: 

Re: Issues with emacs

[Pascal J. Bourguignon]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On Sun, Jun 24 2012, Tom wrote:
>
>> Bastien <bzg <at> gnu.org> writes:
>>
>>> 
>>> The good news is that, whether Emacs users are a dying breed
>>> or not, the only remedy to this hypothetical issue is to have
>>> more Emacs developers.
>>> 
>>
>> But how to have more developers. I see 3 possibilites:
>>
>> 1. Motivate more users to be volunteer developers? Any idea how
>> to do that?
>
> One possibility: if a pure-Lisp implementation of Emacs became the
> "main" implementation, I wonder if many Elisp-gurus who aren't
> particularly enthusiastic about C programming would be encouraged to
> expand their hacking into the Emacs basics.
>
> If the line between programming Emacs packages and programming Emacs
> guts were blurred or erased altogether, I'll bet you'd get a lot more
> people able and willing to contribute work on fundamentals like the
> display engine or multi-threading.
>
> Just a thought,

Indeed.


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

Re: Issues with emacs

[Dan Espen]

Tom <adatgyujto@gmail.com> writes:

> Bastien <bzg <at> gnu.org> writes:
>
>> 
>> The good news is that, whether Emacs users are a dying breed
>> or not, the only remedy to this hypothetical issue is to have
>> more Emacs developers.
>> 
>
> But how to have more developers. I see 3 possibilites:
>
> 1. Motivate more users to be volunteer developers? Any idea how
> to do that?
>
> 2. Attracting more users. Volunteer developers are some small
> percent of the active user base, so if Emacs can be mode more
> attractive to users then the bigger user base will bring more
> volunteer developers too. The problem is in order to be more
> attractive Emacs needs new features which other editors/IDEs have
> and which make users to choose those editors/IDEs instead of
> Emacs, and to implement those more competitive features Emacs
> needs more developers.
>
> 3. Crowdfunding. If we don't have enough volunteer developers
> then we need to motivate developers with something else. For
> example, paying for their work. For this model to work there
> should be some public exposure of this idea, so potential
> developers know they can potentially make a living while
> contributing to Emacs. This kind of public exposure could be done
> by RMS who could mention this development model in every
> interview he gives. He has the voice which can reach lots of
> ears, including potential developer ears.

4. Have a whole bunch of missing functionality.

-- 
Dan Espen

Re: Issues with emacs

[Pascal J. Bourguignon]

Dan Espen <despen@verizon.net> writes:

> Tom <adatgyujto@gmail.com> writes:
>
>> Bastien <bzg <at> gnu.org> writes:
>>
>>> 
>>> The good news is that, whether Emacs users are a dying breed
>>> or not, the only remedy to this hypothetical issue is to have
>>> more Emacs developers.
>>> 
>>
>> But how to have more developers. I see 3 possibilites:
>>
>> 1. Motivate more users to be volunteer developers? Any idea how
>> to do that?
>>
>> 2. Attracting more users. Volunteer developers are some small
>> percent of the active user base, so if Emacs can be mode more
>> attractive to users then the bigger user base will bring more
>> volunteer developers too. The problem is in order to be more
>> attractive Emacs needs new features which other editors/IDEs have
>> and which make users to choose those editors/IDEs instead of
>> Emacs, and to implement those more competitive features Emacs
>> needs more developers.
>>
>> 3. Crowdfunding. If we don't have enough volunteer developers
>> then we need to motivate developers with something else. For
>> example, paying for their work. For this model to work there
>> should be some public exposure of this idea, so potential
>> developers know they can potentially make a living while
>> contributing to Emacs. This kind of public exposure could be done
>> by RMS who could mention this development model in every
>> interview he gives. He has the voice which can reach lots of
>> ears, including potential developer ears.

It'd be nice to have some reliable statistics, such as:

    - absolute number of users of emacs.

    - % of non-programmer users of emacs.

    - histogram of programming languages (or in general modes) edited in
      emacs.




> 4. Have a whole bunch of missing functionality.

:-)

But it looks like there could be some improvements indeed.

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

Re: Issues with emacs

[ken]

On 06/23/2012 07:49 PM Dan Espen wrote:
> Tom<adatgyujto@gmail.com>  writes:
>
>> Bastien<bzg<at>  gnu.org>  writes:
>>
>>>
>>> The good news is that, whether Emacs users are a dying breed
>>> or not, the only remedy to this hypothetical issue is to have
>>> more Emacs developers.
>>>
>>
>> But how to have more developers. I see 3 possibilites:
>>
>> 1. Motivate more users to be volunteer developers? Any idea how
>> to do that?
>>
>> 2. Attracting more users. Volunteer developers are some small
>> percent of the active user base, so if Emacs can be mode more
>> attractive to users then the bigger user base will bring more
>> volunteer developers too. The problem is in order to be more
>> attractive Emacs needs new features which other editors/IDEs have
>> and which make users to choose those editors/IDEs instead of
>> Emacs, and to implement those more competitive features Emacs
>> needs more developers.
>>
>> 3. Crowdfunding. If we don't have enough volunteer developers
>> then we need to motivate developers with something else. For
>> example, paying for their work. For this model to work there
>> should be some public exposure of this idea, so potential
>> developers know they can potentially make a living while
>> contributing to Emacs. This kind of public exposure could be done
>> by RMS who could mention this development model in every
>> interview he gives. He has the voice which can reach lots of
>> ears, including potential developer ears.
>
> 4. Have a whole bunch of missing functionality.

5. Make the elisp documentation and tutorials so easy and fun to learn 
that tons of people actually want to write code.

Re: Issues with emacs

[Sivaram Neelakantan]

On Sun, Jun 24 2012,ken  wrote:


[snipped 37 lines]

> 5. Make the elisp documentation and tutorials so easy and fun to learn
> that tons of people actually want to write code.
>

That'll be the day! :-)




 sivaram
 -- 

becoming a developer [was: Re: Issues with emacs]

[ken]

On 06/25/2012 02:02 PM Sivaram Neelakantan wrote:
> On Sun, Jun 24 2012,ken  wrote:
>
>
> [snipped 37 lines]
>
>> 5. Make the elisp documentation and tutorials so easy and fun to learn
>> that tons of people actually want to write code.
>>
>
> That'll be the day! :-)
>
>
>
>
>   sivaram

Sivaram,

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.

Re: becoming a developer [was: Re: Issues with emacs]

[rusi]

On Jun 26, 8:03 am, ken <geb...@mousecar.com> wrote:
> On 06/25/2012 02:02 PM Sivaram Neelakantan wrote:
>
> > On Sun, Jun 24 2012,ken  wrote:
>
> > [snipped 37 lines]
>
> >> 5. Make the elisp documentation and tutorials so easy and fun to learn
> >> that tons of people actually want to write code.
>
> > That'll be the day! :-)
>
> >   sivaram
>
> Sivaram,
>
> 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.

Hi Ken
It would be great if you could explicate a little how/where/why you
get stuck.
Me? I am probably in a similar situation to you but I guess for
complementary reasons:
Lisp as a language and paradigm are fine and the docs are (usually)
better than average but I usually get hit by 40 years of crud, eg:
- how many different keybinding syntaxes are there?
- how many variations on assignment: setq, setq-default, defvar,
customize etc

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

Re: becoming a developer [was: Re: Issues with emacs]

[antoine no]

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

Hello Ken
You talk about your second try on e-lisp but you don't say what it is?
Could you, to see if i can figure it out in e-lisp?
Thanks

[-- Attachment #2: Type: text/html, Size: 158 bytes --]

Re: becoming a developer [was: Re: Issues with emacs]

[Aurélien Aptel]

Hi,

You should definitely start by looking at Xah Lee's tutorials, they're
the ones that got me started.

http://ergoemacs.org/emacs/elisp.html

Re: becoming a lisp developer

[Pascal J. Bourguignon]

ken <gebser@mousecar.com> writes:

> 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?

The fact is, there are big categories of languages. 

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.



> Maybe, if I live to be three hundred, I'll write an elisp book myself.

Usually it comes much fater.

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

Re: becoming a lisp developer

[ken]

On 06/26/2012 08:29 AM Pascal J. Bourguignon wrote:
> ken<gebser@mousecar.com>  writes:
>
>> 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?
>
> The fact is, there are big categories of languages.
>
> 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)

Yes, the latter sort of expression, where the operand is at the 
beginning of the expression, is called reverse-polish.  There was at 
least one hand-held scientific calculator which came out in the 
mid-1970s which used this notation.  Though it took only a few seconds 
to adjust one's thinking to this syntax, that sort of syntax on such 
devices pretty much died out (AFAIA), people, not surprisingly, 
preferring a notation which conformed more closely to natural language. 
  Conforming to natural language has long been a goal of cyber-language 
developers, for understandable reasons: less attention to syntactic 
anomolies allows for more attention to logic and so too then probably 
better applications.

But, yes, just this once instance is trivial.  Back in the 1980s I wrote 
an expression parser (in C).  I remember being quite surprised how 
little code it required, just ten or twelve lines IIRC.  It was so 
pleasing in its terseness and elegance that I assigned the same task to 
my college students to exercise our discussion on recursion.  (To make 
it a homework assignment they could do in a week, their C code needn't 
perform error checking, but rather assume that all expressions their 
programs would read in were well formed, nor would they need consider 
critically heavy burdens on the stack due to very deep nesting.)  This 
function/program was intended to parse C-style syntax (e.g., "(2 + (5 * 
3))"), but it would be trivial to alter it to parse reverse-polish, or 
vice versa-- which offers up the question, why require text to be parsed 
to conform to one syntactical ruleset as opposed to another?  The code 
for the parser is nigh identical... so why not cut developers a small 
break by conforming more closely to natural language?


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

Thank goodness such concerns are seldom central to applications 
developers, systems developers having for the most part isolated app 
developers from hardware vagaries (as von Neuman intended).  This 
however has long been an area requiring more co-operation between 
hardware and systems folks.


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

Yes, if these were the only barriers to understanding, for all practical 
purposes, there effectively be no barriers at all.



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

One thing you seem to be implying is that elisp is more consistent in 
its syntax than C in many regards.  Consistency, however, can lead to 
ambiguity.



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

I wouldn't say, "forget what you know" but rather "don't make 
assumptions about one language based solely on knowledge from another 
language."  As you pointed out above, while there are many differences, 
there are also many similarities.  We don't really want to forget and 
then have to relearn the similarities.


>
> 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!

My goal in life isn't to experience every category of programming 
language.  I'd just like to contribute code to perform tasks which in my 
estimation seem to need coding... where and when I'm able to.


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

Too much samsara.  :)


>> Maybe, if I live to be three hundred, I'll write an elisp book myself.
>
> Usually it comes much fater.

Thanks for the encouragement... and for the conversation.  But it will 
depend on understanding, which doesn't conform itself in any way to 
calendars.

Re: becoming a lisp developer

[PJ Weisberg]

On Wed, Jun 27, 2012 at 8:36 AM, ken <gebser@mousecar.com> wrote:
>
>
> On 06/26/2012 08:29 AM Pascal J. Bourguignon wrote:
...
>>     (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)
>
>
> Yes, the latter sort of expression, where the operand is at the beginning of
> the expression, is called reverse-polish.  There was at least one hand-held
> scientific calculator which came out in the mid-1970s which used this
> notation.  Though it took only a few seconds to adjust one's thinking to
> this syntax, that sort of syntax on such devices pretty much died out
> (AFAIA), people, not surprisingly, preferring a notation which conformed
> more closely to natural language.  Conforming to natural language has long
> been a goal of cyber-language developers, for understandable reasons: less
> attention to syntactic anomolies allows for more attention to logic and so
> too then probably better applications.
>
> But, yes, just this once instance is trivial.  Back in the 1980s I wrote an
> expression parser (in C).  I remember being quite surprised how little code
> it required, just ten or twelve lines IIRC.  It was so pleasing in its
> terseness and elegance that I assigned the same task to my college students
> to exercise our discussion on recursion.  (To make it a homework assignment
> they could do in a week, their C code needn't perform error checking, but
> rather assume that all expressions their programs would read in were well
> formed, nor would they need consider critically heavy burdens on the stack
> due to very deep nesting.)  This function/program was intended to parse
> C-style syntax (e.g., "(2 + (5 * 3))"), but it would be trivial to alter it
> to parse reverse-polish, or vice versa-- which offers up the question, why
> require text to be parsed to conform to one syntactical ruleset as opposed
> to another?  The code for the parser is nigh identical... so why not cut
> developers a small break by conforming more closely to natural language?

a = b + c * d - e

What happens first?  Do you go left to right, assign b to a, add c to
the result, multiply by d, and subtract e?  No, in fact the assignment
happens last, for mostly obvious reasons, and the multiplication
happens first, because of some arbitrary convention.

(setf a (- (+ b
              (* c d))
           e))

It's different from natural language, but it's completely unambiguous,
and in fact it's structured just like the tree you would have parsed
the C-style expression into.  Plus, it's exactly like the list data
structure, which makes it easy for code to write code at runtime.
Macros.  You can define your own syntax.  If you really wanted to, you
could write a macro, call it `cparse', that would transform

(cparse
    a = b + c * d - e)

into

(setf a (- (+ b
              (* c d))
           e))

Load your macro at the beginning of the file, and you can use C-style
expressions all you want.

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

Re: becoming a lisp developer

[Pascal J. Bourguignon]

ken <gebser@mousecar.com> writes:

> Yes, the latter sort of expression, where the operand is at the
> beginning of the expression, is called reverse-polish.  

Of course not.

> There was at
> least one hand-held scientific calculator which came out in the
> mid-1970s which used this notation.  

No, it used the Reverse Polish Notation ("RPN"), in which, the arguments
are first, and the operators are suffixed.

    12  45  +  --> 57

In Lisp, we use the fully parenthesized Polish Notation!

   (+ 12 45)    --> 57

The reasons we use parentheses is that:

1- it allows us to deal easily with variadic operations

      (+ 1 2 3 4)    ; lisp

      + + + 1 2 3 4  ; Polish

2- it allows us to deal with fixed-arity operations WITHOUT HAVING TO
   KNOW what their arity is.  This is important to be able to write
   macros easily.


> Though it took only a few seconds
> to adjust one's thinking to this syntax, that sort of syntax on such
> devices pretty much died out (AFAIA), people, not surprisingly,
> preferring a notation which conformed more closely to natural
> language.

Not at all.  Discriminating user of hand-held calculators still prefer
HP calculators for its RPN.
http://welcome.hp.com/country/us/en/prodserv/calculator.html


> Conforming to natural language has long been a goal of
> cyber-language developers, for understandable reasons: less attention
> to syntactic anomolies allows for more attention to logic and so too
> then probably better applications.

And this has been a failure in all case, because natural language is by
nature ambiguous, which is a deal breaker for algorithmics and
programming languages.


> But, yes, just this once instance is trivial.  Back in the 1980s I
> wrote an expression parser (in C).  I remember being quite surprised
> how little code it required, just ten or twelve lines IIRC.  It was so
> pleasing in its terseness and elegance that I assigned the same task
> to my college students to exercise our discussion on recursion.  (To
> make it a homework assignment they could do in a week, their C code
> needn't perform error checking, but rather assume that all expressions
> their programs would read in were well formed, nor would they need
> consider critically heavy burdens on the stack due to very deep
> nesting.)  This function/program was intended to parse C-style syntax
> (e.g., "(2 + (5 * 3))"), but it would be trivial to alter it to parse
> reverse-polish, or vice versa-- which offers up the question, why
> require text to be parsed to conform to one syntactical ruleset as
> opposed to another?  The code for the parser is nigh identical... so
> why not cut developers a small break by conforming more closely to
> natural language?

That's the wrong question (see above).  The right question would be, why
the editors wouldn't present the same Sexp-based representation of
program sources, in the syntax the user prefers.

In emacs you could easily unparse sexp files into any kind of syntax,
and parse it again upon saving to write back sexps.

That's exactly what lisp does, but lisp programmers (in general) just
like to write directly the sexps, instead of dealing with artificial and
useless syntax layer.


>> 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.
>>
>> ....
>
> Thank goodness such concerns are seldom central to applications
> developers, systems developers having for the most part isolated app
> developers from hardware vagaries (as von Neuman intended).  This
> however has long been an area requiring more co-operation between
> hardware and systems folks.

You mean, to Common Lisp application developers.
But not to

1- emacs application developers,

2- C or C++ application developers,

3- any other language that doesn't provide bignums,

4- any programming language (included Common Lisp!) that doesn't provide
   real Real numbers (eg. using the reallib library). 
   http://www.daimi.au.dk/~barnie/RealPractical.pdf


Otherwise, given that there's still no cl-reallib, and that most other
programming language don't have bignums for integers, then it's
obviously a central concern for any application developers!  Just try to
write a program to compute the US debt!  Or the next Fed quantitative easing!




>> 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).
>
> Yes, if these were the only barriers to understanding, for all
> practical purposes, there effectively be no barriers at all.

That wasn't my point.  My point was that since even for the simpliest
operation there are big semantics difference, you can expect that
learning a language in a different category of language be something
that either:

1- is hard, or

2- require that you empty your mind and start from a blank slate.




>> 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.
>
> I wouldn't say, "forget what you know" but rather "don't make
> assumptions about one language based solely on knowledge from another
> language."  

You may express it like that.  But it looks like for most people it
would be easier to forget than to keep knowledge about different things
separate.

> As you pointed out above, while there are many differences, there are
> also many similarities.  We don't really want to forget and then have
> to relearn the similarities.

    It is practically impossible to teach good programming to students
    that have had a prior exposure to BASIC: as potential programmers
    they are mentally mutilated beyond hope of regeneration. 

http://www.cs.virginia.edu/~cs655/readings/ewd498.html


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

Re: Issues with emacs

[notbob]

On 2012-06-25, Sivaram Neelakantan <nsivaram.net@gmail.com> wrote:
> On Sun, Jun 24 2012,ken  wrote:
>
>
> [snipped 37 lines]
>
>> 5. Make the elisp documentation and tutorials so easy and fun to learn
>> that tons of people actually want to write code.
>>
>
> That'll be the day! :-)

Actually, the lisp tutorial the comes with emacs is pretty damn well
written.  One of the better programming tuts I've run across.  Now, if
I can only recall how to access it.  ;)  

(where'd I put those notes)

nb


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

Re: Issues with emacs

[Glyn Millington]

notbob <notbob@nothome.com> writes:

> On 2012-06-25, Sivaram Neelakantan <nsivaram.net@gmail.com> wrote:
>> On Sun, Jun 24 2012,ken wrote:
>>
>> [snipped 37 lines]
>>
>>> 5. Make the elisp documentation and tutorials so easy and fun to
>>> learn that tons of people actually want to write code.
>>>
>> That'll be the day! :-)
>
> Actually, the lisp tutorial the comes with emacs is pretty damn well
> written.  One of the better programming tuts I've run across.  Now, if
> I can only recall how to access it.  ;)



C-h t 





atb

Glyn

Re: Issues with emacs

[rusi]

On Jun 24, 7:39 am, ken <geb...@mousecar.com> wrote:

> 5. Make the elisp documentation and tutorials so easy and fun to learn
> that tons of people actually want to write code.

When I first started reading the emacs/elisp docs around 93 I found
them a model of clarity.
Has that changed much? I dont think so

Whats changed?  The fact that we are in 2012.
In those days it was completely natural to expect that somebody who
used a computer read a manual
Today thats a strange requirement to say the least.

Would a modern kid using a new phone/car expect to read a manual? The
fact is they dont (whereas oldies like me struggle to find them :-) )

And so you give them emacs along with a manual and they look at you
funny.

By chance they look inside and they find:
- there's  a key called Meta? Whazzat?
- C-p and C-n do up and down? Really?! (and whatever is C- ?)
- And when you tell them arrow keys work just fine they are ready with
a lock and key to put you away somewhere

tl;dr version: Saying that emacs manuals are not fun and easy to learn
is wrong.  Its just that reading them feels like 1980

Re: Issues with emacs

[Corentin Henry]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

Sorry, but I think the emacs documentation IS hard for a beginner like me.

   - At the very beginning, I didn't know where to search ! I was
   navigating through pages an pages, and the more I read, the more I had to
   read.
   - There is no "how to", whereas that's what people want nowadays. I
   don't want to spend time reading and understanding how emacs works, through
   pages of documentation (even if it is well written) ! I want to be told how
   to do what I want.
   - The online manual is ugly... HTML is cool, but a little bit of CSS
   would improve the manual a lot.


2012/6/24 rusi <rustompmody@gmail.com>

> On Jun 24, 7:39 am, ken <geb...@mousecar.com> wrote:
>
> > 5. Make the elisp documentation and tutorials so easy and fun to learn
> > that tons of people actually want to write code.
>
> When I first started reading the emacs/elisp docs around 93 I found
> them a model of clarity.
> Has that changed much? I dont think so
>
> Whats changed?  The fact that we are in 2012.
> In those days it was completely natural to expect that somebody who
> used a computer read a manual
> Today thats a strange requirement to say the least.
>
> Would a modern kid using a new phone/car expect to read a manual? The
> fact is they dont (whereas oldies like me struggle to find them :-) )
>
> And so you give them emacs along with a manual and they look at you
> funny.
>
> By chance they look inside and they find:
> - there's  a key called Meta? Whazzat?
> - C-p and C-n do up and down? Really?! (and whatever is C- ?)
> - And when you tell them arrow keys work just fine they are ready with
> a lock and key to put you away somewhere
>
> tl;dr version: Saying that emacs manuals are not fun and easy to learn
> is wrong.  Its just that reading them feels like 1980
>

[-- Attachment #2: Type: text/html, Size: 2210 bytes --]

Re: Issues with emacs

[Andreas Röhler]

Am 24.06.2012 09:01, schrieb Corentin Henry:
> Sorry, but I think the emacs documentation IS hard for a beginner like me.
>
>     - At the very beginning, I didn't know where to search ! I was
>     navigating through pages an pages, and the more I read, the more I had to
>     read.


very important point, thanks

Luckily there are a lot of tutorial suitable for beginners in the net.


>     - There is no "how to", whereas that's what people want nowadays. I
>     don't want to spend time reading and understanding how emacs works, through
>     pages of documentation (even if it is well written) ! I want to be told how
>     to do what I want.

[ ... ]

also focus should shift from teaching keys to mnemonic command-names.

Andreas

Re: Issues with emacs

[Eli Zaretskii]

> Date: Sun, 24 Jun 2012 09:55:29 +0200
> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> 
> Luckily there are a lot of tutorial suitable for beginners in the net.

As well as bundled with the distribution, so no need to go look for
them on the net.

Re: Issues with emacs

[Andreas Röhler]

Am 24.06.2012 18:04, schrieb Eli Zaretskii:
>> Date: Sun, 24 Jun 2012 09:55:29 +0200
>> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
>>
>> Luckily there are a lot of tutorial suitable for beginners in the net.
>
> As well as bundled with the distribution, so no need to go look for
> them on the net.
>
>
>

hmm, can't see it. May you point me to?

Well, should you have in mind what's visible from emacs -q, that's just not so suitable for beginners IMO,
that's non-didactic hard-core key-stroke lesson.

Anyway, my thanks for Emacs,

Andreas

Re: Issues with emacs

[Eli Zaretskii]

> Date: Sun, 24 Jun 2012 19:38:28 +0200
> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> 
> Am 24.06.2012 18:04, schrieb Eli Zaretskii:
> >> Date: Sun, 24 Jun 2012 09:55:29 +0200
> >> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> >>
> >> Luckily there are a lot of tutorial suitable for beginners in the net.
> >
> > As well as bundled with the distribution, so no need to go look for
> > them on the net.
> 
> hmm, can't see it. May you point me to?

"C-h t" or "C-u C-h t".

> Well, should you have in mind what's visible from emacs -q, that's just not so suitable for beginners IMO,
> that's non-didactic hard-core key-stroke lesson.

Then suggesting improvements for it is the best way to help
beginners.  TIA.

Re: Issues with emacs

[notbob]

On 2012-06-24, Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> also focus should shift from teaching keys to mnemonic command-names.

I don't know about that.  I jes wrote my own cheat sheet as I learned
new commands and keystokes.  I mean, yer already in a text editor,
ferchrysakes!   ;) 

nb

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

Re: Issues with emacs

[Deniz Dogan]

On 2012-06-24 14:17,, notbob wrote:
> On 2012-06-24, Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
>
>> also focus should shift from teaching keys to mnemonic command-names.
>
> I don't know about that.  I jes wrote my own cheat sheet as I learned
> new commands and keystokes.  I mean, yer already in a text editor,
> ferchrysakes!   ;)
>

Wouldn't it be very useful to have a QUICKSTART or HOWTO shipped with 
Emacs?  Something really short and concise and containing something like 
this:

Notation:

* C- means Control
* M- means Meta (or Alt if you don't have a Meta key)
* C-M- means Control and Meta


Movement:

C-n - Move to the next line
C-p - Move to the previous line
C-v - Move one screen downwards
M-v - Move one screen upwards


Editing:

C-x C-f - Open a file
C-x b - Switch to another buffer
C-x C-s - Save the current buffer to a file
C-w - Cut the current selection ("killing" and deleting)
M-w - Copy the current selection ("killing" but not deleting)
C-y - Paste ("yanking" killed text)
C-/ - Undo


Searching/replacing:

C-s - Search
M-% - Search and replace
C-M-% - Search and replace (regular expressions)


Miscellaneous:

M-x - Execute a command that doesn't necessarily have a key binding
C-x C-c - Exit Emacs
C-g - Abort unfinished key sequence
ESC ESC ESC - If you messed up somehow and want to hide in a corner and 
hope for it to go away

Re: Issues with emacs

[Yuri Khan]

On Sun, Jun 24, 2012 at 8:24 PM, Deniz Dogan <deniz@dogan.se> wrote:

> Wouldn't it be very useful to have a QUICKSTART or HOWTO shipped with Emacs?
>  Something really short and concise and containing something like this:
>
> Movement:
>
> C-n - Move to the next line
> C-p - Move to the previous line
> C-v - Move one screen downwards
> M-v - Move one screen upwards

A beginner user does not need or want to know about these shortcuts
and will be satisfied with “Arrow keys, Page Up/Down and Home/End Just
Work as you would expect”. Home-row-accessible shortcuts could be the
subject of a more in-depth “Using Emacs efficiently” article, along
with key macros and key binding customizations.

Re: Issues with emacs

[Gregory Benjamin]

Here's my off-the-top-of-my-head variation on your idea:

> Wouldn't it be very useful to have a QUICKSTART or HOWTO shipped
> with Emacs?  Something really short and concise and containing
> something like this:
> 
> Notation:
> 
> * C- means Control
> * M- means Meta (or Alt if you don't have a Meta key)
> * C-M- means Control and Meta
> 
> 
> Movement:
> 

I don't use any of these four in day-to-day use, though I did learn
them initially.

> C-n - Move to the next line
> C-p - Move to the previous line
> C-v - Move one screen downwards
> M-v - Move one screen upwards

I use these instead. I prefer to simply hold down the up or down arrow
key to scroll since, on modern computers, this moves through the text
at about 15 lines per second.

Arrow keys - work as expected
C-a - Move to beginning of line
C-e - Move to end of line
M-< - Move to beginning of buffer (requires shift)
M-> - Move to end of buffer (requires shift)

I class C-s and C-r as cursor movement keys.

C-s - Search/Jump forward
C-r - Search/Jump backward

> Editing:
> 
> C-x C-f - Open a file
> C-x b - Switch to another buffer
> C-x C-s - Save the current buffer to a file

C-d - delete character
M-d - delete "word"

My ~/.emacs has: (setq kill-whole-line t) so that:

C-k - delete from point to EOL or entire line if point is in col 1.

Setting kill-whole-line t makes C-k comfortable for deleteing blocks
of text. Just type C-a, then C-k as many times as desired. In cases
where I want to cut/paste more than a few lines of text:

C-space - Start marking region to cut/paste

> C-w - Cut the current selection ("killing" and deleting)
> M-w - Copy the current selection ("killing" but not deleting)
> C-y - Paste ("yanking" killed text)
> C-/ - Undo
> 
> 
> Searching/replacing:
> 
> C-s - Search
> M-% - Search and replace
> C-M-% - Search and replace (regular expressions)
> 
> 
> Miscellaneous:
> 
> M-x - Execute a command that doesn't necessarily have a key binding
> C-x C-c - Exit Emacs
> C-g - Abort unfinished key sequence
> ESC ESC ESC - If you messed up somehow and want to hide in a corner
> and hope for it to go away

Re: Issues with emacs

[Deniz Dogan]

On 2012-06-24 17:08,, Gregory Benjamin wrote:
> Here's my off-the-top-of-my-head variation on your idea:
>
>> Wouldn't it be very useful to have a QUICKSTART or HOWTO shipped
>> with Emacs?  Something really short and concise and containing
>> something like this:
>>
>> Notation:
>>
>> * C- means Control
>> * M- means Meta (or Alt if you don't have a Meta key)
>> * C-M- means Control and Meta
>>
>>
>> Movement:
>>
>
> I don't use any of these four in day-to-day use, though I did learn
> them initially.
>

My whole e-mail was just an example.  You get the gist.

Re: Issues with emacs

[Eli Zaretskii]

> Date: Sun, 24 Jun 2012 15:24:14 +0200
> From: Deniz Dogan <deniz@dogan.se>
> Cc: help-gnu-emacs@gnu.org
> 
> Wouldn't it be very useful to have a QUICKSTART or HOWTO shipped with 
> Emacs?  Something really short and concise and containing something like 
> this:
> 
> Notation:
> 
> * C- means Control
> * M- means Meta (or Alt if you don't have a Meta key)
> * C-M- means Control and Meta
> 
> 
> Movement:
> 
> C-n - Move to the next line
> C-p - Move to the previous line
> C-v - Move one screen downwards
> M-v - Move one screen upwards

How is this different from the reference card we have already in the
distro?

Re: Issues with emacs

[Deniz Dogan]

On 2012-06-24 18:24,, Eli Zaretskii wrote:
>> Date: Sun, 24 Jun 2012 15:24:14 +0200
>> From: Deniz Dogan <deniz@dogan.se>
>> Cc: help-gnu-emacs@gnu.org
>>
>> Wouldn't it be very useful to have a QUICKSTART or HOWTO shipped with
>> Emacs?  Something really short and concise and containing something like
>> this:
>>
>> Notation:
>>
>> * C- means Control
>> * M- means Meta (or Alt if you don't have a Meta key)
>> * C-M- means Control and Meta
>>
>>
>> Movement:
>>
>> C-n - Move to the next line
>> C-p - Move to the previous line
>> C-v - Move one screen downwards
>> M-v - Move one screen upwards
>
> How is this different from the reference card we have already in the
> distro?
>

I didn't know we shipped Emacs with reference cards, I just found them 
once you told me they existed.  They look good!  It would be very nice 
to have it as an alternative to the tutorial, easily accessible, like C-h t.

Re: Issues with emacs

[Richard Riley]

notbob <notbob@nothome.com> writes:

> On 2012-06-24, Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
>
>> also focus should shift from teaching keys to mnemonic command-names.
>
> I don't know about that.  I jes wrote my own cheat sheet as I learned
> new commands and keystokes.  I mean, yer already in a text editor,
> ferchrysakes!   ;) 
>
> nb

Using key strokes is silly. They change and/or/are customised. And its
also trivial for the user to learn to learn by querying the doc string
for the command and also then seeing the key chords which invoke it were
applicable.

Re: Issues with emacs

[notbob]

On 2012-06-24, Deniz Dogan <deniz@dogan.se> wrote:
> On 2012-06-24 14:17,, notbob wrote:

> Wouldn't it be very useful to have a QUICKSTART or HOWTO shipped with 
> Emacs?  Something really short and concise and containing something like 
> this:
>
> Notation:
>
> * C- means Control
> * M- means Meta (or Alt if you don't have a Meta key)
> * C-M- means Control and Meta

It already exists.  It's called the emacs tutorial:

C-h t

...and is presented every time you start general emacs.  IOW, not in
dired or an existing file.

nb

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

Re: Issues with emacs

[Eli Zaretskii]

> Date: Sun, 24 Jun 2012 15:01:25 +0800
> From: Corentin Henry <corentinhenry@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
>    - At the very beginning, I didn't know where to search ! I was
>    navigating through pages an pages, and the more I read, the more I had to
>    read.
>    - There is no "how to", whereas that's what people want nowadays. I
>    don't want to spend time reading and understanding how emacs works, through
>    pages of documentation (even if it is well written) ! I want to be told how
>    to do what I want.

I guess you never read the tutorial, which comes with Emacs.  That
should have given you both the initial "how to" and the key to reading
the rest of the documentation efficiently (as opposed to reading the
whole manual chapter after chapter).

Re: Issues with emacs

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/06/12 08:39, rusi wrote:
> On Jun 24, 7:39 am, ken <geb...@mousecar.com> wrote:
> 
>> 5. Make the elisp documentation and tutorials so easy and fun to learn that tons of people
>> actually want to write code.
> 
> When I first started reading the emacs/elisp docs around 93 I found them a model of clarity. 
> Has that changed much? I dont think so
> 
> Whats changed?  The fact that we are in 2012. In those days it was completely natural to expect
> that somebody who used a computer read a manual Today thats a strange requirement to say the
> least.
> 
> Would a modern kid using a new phone/car expect to read a manual? The fact is they dont
> (whereas oldies like me struggle to find them :-) )
> 
> And so you give them emacs along with a manual and they look at you funny.
> 
> By chance they look inside and they find: - there's  a key called Meta? Whazzat? - C-p and C-n
> do up and down? Really?! (and whatever is C- ?) - And when you tell them arrow keys work just
> fine they are ready with a lock and key to put you away somewhere


And I this is a very important point: one advantage I think many of us see in emacs (you can
(probably even have to) do everything with keyboarsd shortcut / sequences) is the point where new
users omost often struggle - and I speak of experience. I started using emacs because of ESS-mode
for writing R programs - but I regularly tried eclipse because of its

1) more "convential" (read: GUI) look
2) the possibility to do everything with eh mouse.

but I always went back to emacs because simply ESS was much better.

Then I started, for a bigger project in R, to use org-mode for literate programming, and I thought
after some time again about eclipse, but: there is nothing like org mode.

So in a nutshell: I had to dig my way through the

a) "conservative look" (Which I really like by now!) and, more difficult,
b) the un-usual (in the eyes of most non-emacs users) keyboard shortcuts.

So two (probably three) points spring to mind which *could* make emacs more attractive for new
users to reach that "point of no return" where they realize: there is nothing like amacs!

1) improve the menu to live up to "moderm" menu standards, so that efffectually everything could
be done by using the mouse (*but most definitely keep the keyboard shortcuts!!!!!!!). I know that
this is not possible for all additional packages, but at least the emacs core should be usable
completely via mouse.

2) improve the GUI look, to conform more with a "modern" look

3) change the menu, so that there the new users learns to do the stuff by using the mose (and
introduce the keyboard e.g. in brackets).

- From my experience: when (or in many cases "if") the new user manages to accept and use way of
using emacs (now via initially *very strange* keyboard shortcuts) to reach the brilliant features
and tha land off possibilities hidden behind, they will stay. If the initial crossing of the
border can be done easier, more users will discover the wonders of emacs.

Cheers,

Rainer






> 
> tl;dr version: Saying that emacs manuals are not fun and easy to learn is wrong.  Its just that
> reading them feels like 1980
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/m6KEACgkQoYgNqgF2egq1zgCeJ0lcrcQP/K4ThL++kqAPWCMn
xLgAn2Nf0P3OCW3HbDj0V7JvVwBhOLS8
=MRnE
-----END PGP SIGNATURE-----

RE: Issues with emacs

[Drew Adams]

> 1) improve the menu to live up to "moderm" menu standards, so 
> that efffectually everything could
> be done by using the mouse (*but most definitely keep the 
> keyboard shortcuts!!!!!!!). I know that
> this is not possible for all additional packages, but at 
> least the emacs core should be usable
> completely via mouse.
> 
> 2) improve the GUI look, to conform more with a "modern" look
> 
> 3) change the menu, so that there the new users learns to do 
> the stuff by using the mose (and
> introduce the keyboard e.g. in brackets).
> 
> - From my experience: when (or in many cases "if") the new 
> user manages to accept and use way of
> using emacs (now via initially *very strange* keyboard 
> shortcuts) to reach the brilliant features
> and tha land off possibilities hidden behind, they will stay. 
> If the initial crossing of the
> border can be done easier, more users will discover the 
> wonders of emacs.

1. FWIW, I agree with this.  Menus are a great way to discover.  They need to be
well organized, of course.  But given good organization, that organization can
be a tremendous learning aid (and a memory aid).

In my libraries I generally spend time trying to (a) put more stuff on menus,
(b) get the menu item terminology right, and (c) organize the menus well.  Not
that I always succeed (yes, it takes time, thought, and practice using the
resulting menus), but I try.

This is also a motivation behind La Carte (easier keyboard access to menus) and
Icicles (combined with La Carte, access menu items at any level using
substrings, regexps etc.).

http://www.emacswiki.org/emacs/LaCarte
http://www.emacswiki.org/emacs/EmacsNewbieWithIcicles#toc7

2. Likewise, the mouse.  A direct-access pointing device is a tremendous asset
to human-machine interaction.

(That notion is anathema to some Emacs folk, though you would think that brief
reflection on tape-vs-disk access would be enough to turn on the light.  Yes, of
course Emacs has direct-access key sequences, but a mouse gives you direct
access _anywhere_: look, point to a destination, bam!)

3. There is a place for _both_ (a) in-depth documentation and (b) well designed
keyboard shortcuts, on the one hand, and (c) well designed menus and (d) mouse
interaction, on the other hand.

4. Emacs has moved from only doc and only keyboard (and only console - no
frames) toward incorporation of more "modern" GUI stuff.

But most of that movement happened long, long ago, when those things first
became possible to add to Emacs (back when X Window and window managers in
general were new).  And most of it happened outside the GNU Emacs development
stream and was only incorporated later (and sometimes not too enthusiastically).
Epoch and XEmacs get kudos here, to mention just two.

And yes, there is still a long way to go.

5. If you are interested in going further, please contribute and participate.
It is (as has amply been demonstrated) not enough to whine that Emacs is not
"modern" enough, and to expect the old guard to step up to the plate and do what
you think should be done.  Whether what you want gets done depends on you.

Improving the use of menus and improving doc/help access is approachable by
nearly anyone.  Menu implementation is a bit complicated, and so are keymaps.
But once past the initial hurdle it is not hard to make a concrete
implementation improvement/proposal.  Whether a particular proposal gets adopted
is another story.  But your chances are much higher with code than with abstract
expectations or whining about "modern" and "nowadays" this or that.

Re: Issues with emacs

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/06/12 16:18, Drew Adams wrote:
>> 1) improve the menu to live up to "moderm" menu standards, so that efffectually everything
>> could be done by using the mouse (*but most definitely keep the keyboard shortcuts!!!!!!!). I
>> know that this is not possible for all additional packages, but at least the emacs core
>> should be usable completely via mouse.
>> 
>> 2) improve the GUI look, to conform more with a "modern" look
>> 
>> 3) change the menu, so that there the new users learns to do the stuff by using the mose
>> (and introduce the keyboard e.g. in brackets).
>> 
>> - From my experience: when (or in many cases "if") the new user manages to accept and use way
>> of using emacs (now via initially *very strange* keyboard shortcuts) to reach the brilliant
>> features and tha land off possibilities hidden behind, they will stay. If the initial
>> crossing of the border can be done easier, more users will discover the wonders of emacs.
> 
> 1. FWIW, I agree with this.  Menus are a great way to discover.  They need to be well
> organized, of course.  But given good organization, that organization can be a tremendous
> learning aid (and a memory aid).
> 
> In my libraries I generally spend time trying to (a) put more stuff on menus, (b) get the menu
> item terminology right, and (c) organize the menus well.  Not that I always succeed (yes, it
> takes time, thought, and practice using the resulting menus), but I try.
> 
> This is also a motivation behind La Carte (easier keyboard access to menus) and Icicles
> (combined with La Carte, access menu items at any level using substrings, regexps etc.).
> 
> http://www.emacswiki.org/emacs/LaCarte 
> http://www.emacswiki.org/emacs/EmacsNewbieWithIcicles#toc7
> 
> 2. Likewise, the mouse.  A direct-access pointing device is a tremendous asset to human-machine
> interaction.
> 
> (That notion is anathema to some Emacs folk, though you would think that brief reflection on
> tape-vs-disk access would be enough to turn on the light.  Yes, of course Emacs has
> direct-access key sequences, but a mouse gives you direct access _anywhere_: look, point to a
> destination, bam!)
> 
> 3. There is a place for _both_ (a) in-depth documentation and (b) well designed keyboard
> shortcuts, on the one hand, and (c) well designed menus and (d) mouse interaction, on the other
> hand.
> 
> 4. Emacs has moved from only doc and only keyboard (and only console - no frames) toward
> incorporation of more "modern" GUI stuff.
> 
> But most of that movement happened long, long ago, when those things first became possible to
> add to Emacs (back when X Window and window managers in general were new).  And most of it
> happened outside the GNU Emacs development stream and was only incorporated later (and
> sometimes not too enthusiastically). Epoch and XEmacs get kudos here, to mention just two.
> 
> And yes, there is still a long way to go.
> 
> 5. If you are interested in going further, please contribute and participate. It is (as has
> amply been demonstrated) not enough to whine that Emacs is not "modern" enough, and to expect
> the old guard to step up to the plate and do what you think should be done.  Whether what you
> want gets done depends on you.
> 
> Improving the use of menus and improving doc/help access is approachable by nearly anyone.
> Menu implementation is a bit complicated, and so are keymaps. But once past the initial hurdle
> it is not hard to make a concrete implementation improvement/proposal.  Whether a particular
> proposal gets adopted is another story.  But your chances are much higher with code than with
> abstract expectations or whining about "modern" and "nowadays" this or that.

Ups - I just hope that this refers to me: I definitely did not "whine that emacs is not modern
enough", nor did I want to complain tat emacs is not "modern" enough for "nowadays" computer users.

I just gave my opinion why I think, from personal experience, many people do prefer other editors.
I do not complain about this - I though this thread was about raising points why not more people
are using emacs? If this was wrong, my apologies.

Although I do not have the time nor the knowledge to improve emacs in this regard, I think this is
an important point which should be kept in mind.

And I am looking forward to my next project which will again involve again lots of "old fashioned
emacs use".

Cheers,


Rainer


> 
> 
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/nNT4ACgkQoYgNqgF2egr+QgCeIolTH6GKhuaa0um/ukmke2F4
/hAAnjA1ww3bg0x34odVVB1xFnr+Vqx2
=U1gv
-----END PGP SIGNATURE-----

RE: Issues with emacs

[Drew Adams]

> > Improving the use of menus and improving doc/help access is 
> > approachable by nearly anyone.  Menu implementation is a bit
> > complicated, and so are keymaps. But once past the initial
> > hurdle it is not hard to make a concrete implementation 
> > improvement/proposal.  Whether a particular proposal gets
> > adopted is another story.  But your chances are much higher
> > with code than with abstract expectations or whining about
> > "modern" and "nowadays" this or that.
> 
> Ups - I just hope that this refers to me: I definitely did 
> not "whine that emacs is not modern enough", nor did I want to
> complain tat emacs is not "modern" enough for "nowadays" computer
> users.

No, Rainer, not at all.  I was not referring to anything said by anyone in this
thread.  I was speaking generally, based on lots of threads and other
discussions over the years.

And let me be clearer: There is _nothing wrong with complaining_, whether or not
someone has a positive suggestion or, better, a proposed code change - as long
as readers are respected as people and not insulted or attacked personally,
obviously.

The closer feedback is to a concrete suggestion, code patch, or reasoned
technical argument, the more useful it is likely to be.  That's all.

No one, including me, should discourage feedback that does not necessarily make
a concrete proposal.  Complaints, no matter how expressed or how vague, have
their place and can be constructive in the end - and no matter how they might be
received.

The point is not for anyone to avoid complaining.  It is just to suggest that if
you _can_ be concrete, give reasons, and maybe even suggest code changes, then
the chances of consideration generally improve.  Just advice/suggestion.

And as I tried to make clear, even a well reasoned, concrete proposal based on a
good idea and with a clean code patch is far from a guarantee of acceptance.
Just because you express your idea well and you are convinced that it represents
an improvement, that does not mean that others will see things the same way. ;-)
Don't take such rejection personally, and don't let it dissuade you from
continuing to try to improve things.

Those who decide have been wrong about many things over the years.  And they
have also been right about many things.  If they are wrong about about a
suggestion you make, so be it.

Re: Issues with emacs

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/06/12 18:07, Drew Adams wrote:
>>> Improving the use of menus and improving doc/help access is approachable by nearly anyone.
>>> Menu implementation is a bit complicated, and so are keymaps. But once past the initial 
>>> hurdle it is not hard to make a concrete implementation improvement/proposal.  Whether a
>>> particular proposal gets adopted is another story.  But your chances are much higher with
>>> code than with abstract expectations or whining about "modern" and "nowadays" this or
>>> that.
>> 
>> Ups - I just hope that this refers to me: I definitely did not "whine that emacs is not
>> modern enough", nor did I want to complain tat emacs is not "modern" enough for "nowadays"
>> computer users.
> 
> No, Rainer, not at all.  I was not referring to anything said by anyone in this thread.  I was
> speaking generally, based on lots of threads and other discussions over the years.
> 
> And let me be clearer: There is _nothing wrong with complaining_, whether or not someone has a
> positive suggestion or, better, a proposed code change - as long as readers are respected as
> people and not insulted or attacked personally, obviously.
> 
> The closer feedback is to a concrete suggestion, code patch, or reasoned technical argument,
> the more useful it is likely to be.  That's all.
> 
> No one, including me, should discourage feedback that does not necessarily make a concrete
> proposal.  Complaints, no matter how expressed or how vague, have their place and can be
> constructive in the end - and no matter how they might be received.
> 
> The point is not for anyone to avoid complaining.  It is just to suggest that if you _can_ be
> concrete, give reasons, and maybe even suggest code changes, then the chances of consideration
> generally improve.  Just advice/suggestion.
> 
> And as I tried to make clear, even a well reasoned, concrete proposal based on a good idea and
> with a clean code patch is far from a guarantee of acceptance. Just because you express your
> idea well and you are convinced that it represents an improvement, that does not mean that
> others will see things the same way. ;-) Don't take such rejection personally, and don't let it
> dissuade you from continuing to try to improve things.
> 
> Those who decide have been wrong about many things over the years.  And they have also been
> right about many things.  If they are wrong about about a suggestion you make, so be it.

Good points and lets hope that this discussion will help to make emacs even wider accepted as it
is now.

Cheers,

Rainer


> 
> 
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/nRMsACgkQoYgNqgF2egrfJgCeI7z08K4O9QWbfUSTIUbPN4QR
ocAAn0sSdyjQ+PNIcME2UJSR0sESkY/6
=s7+f
-----END PGP SIGNATURE-----

Re: Issues with emacs

[notbob]

On 2012-06-24, Corentin Henry <corentinhenry@gmail.com> wrote:

>    - There is no "how to"..........

Yes, there is.  It's called Learning Gnu Emacs and is published by
O'Reilly press.  Worth every cent if yer serious about emacs.


>    - The online manual is ugly... HTML is cool......

Not in a newsgroup, it's not.  Don't include it again.

[snip offending html crap]

nb

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

RE: Issues with emacs

[Drew Adams]

> In those days it was completely natural to expect that somebody who
> used a computer read a manual.  Today thats a strange requirement
> to say the least.

And in those days more computer users programmed computers.  "Using a computer"
does not mean quite the same thing now, in general.

> Would a modern kid using a new phone/car expect to read a manual? The
> fact is they dont (whereas oldies like me struggle to find them :-) )

:-D  Indeed we do.

> And so you give them emacs along with a manual and they look at you
> funny.

Or as Henry Corentin put it here, "I don't want to spend time reading and
understanding how emacs works, through pages of documentation (even if it is
well written)!"

Giving the tendency you describe as a reason, there is some argument in the
technical documentation world to de-emphasize in-depth doc and instead emphasize
support for so-called "information snacking".  Tweet-doc, so to speak.

The argument is not just that users now want instant, short help (which would be
an addition, a plus), but that they do not, will not, or cannot read.

Or even that they do not need to or want to understand how something works.
Task-oriented doc can be aligned to this.  Instead of conceptual explanation of
how something works, provide (only) a list of common user tasks.

Did I hear "Gag!?"  On n'arrete pas le progres...

A propos, there was a program on (US) PBS recently about multi-tasking, and one
of the studies indicated that students nowadays (again, in the US) were still
writing more or less coherent paragraphs, but often those paragraphs were
unrelated - there was no overall coherent argument or thread in the student
compositions.  It was as if a single paragraph was the only degree of
composition they would or could muster.

Re: Issues with emacs

[ken]

On 06/24/2012 02:39 AM rusi wrote:
> On Jun 24, 7:39 am, ken<geb...@mousecar.com>  wrote:
>
>> 5. Make the elisp documentation and tutorials so easy and fun to learn
>> that tons of people actually want to write code.
>
> When I first started reading the emacs/elisp docs around 93 I found
> them a model of clarity.
> Has that changed much? I dont think so
>
> ....
>
> tl;dr version: Saying that emacs manuals are not fun and easy to learn
> is wrong.  Its just that reading them feels like 1980

I got into computers long before 1980... and read computer manuals back 
in the '70s just for fun-- even though I didn't then have a computer or 
access to one.

That said, please note that I was referring to *elisp* and never 
mentioned *emacs*.  These are two quite different subjects and equating 
them and/or their documentation-- to borrow a phrase-- is just wrong.

The topic was emacs development and how to encourage it.  This requires 
a knowledge of /elisp/.  In the confusion the point I made was lost, so 
I'll say it again: To encourage development, there could be better elisp 
documentation and tutorials.

Re: Issues with emacs

[rusi]

On Jun 25, 8:54 am, ken <geb...@mousecar.com> wrote:
> On 06/24/2012 02:39 AM rusi wrote:
>
> > On Jun 24, 7:39 am, ken<geb...@mousecar.com>  wrote:
>
> >> 5. Make the elisp documentation and tutorials so easy and fun to learn
> >> that tons of people actually want to write code.
>
> > When I first started reading the emacs/elisp docs around 93 I found
> > them a model of clarity.
> > Has that changed much? I dont think so
>
> > ....
>
> > tl;dr version: Saying that emacs manuals are not fun and easy to learn
> > is wrong.  Its just that reading them feels like 1980
>
> I got into computers long before 1980... and read computer manuals back
> in the '70s just for fun-- even though I didn't then have a computer or
> access to one.

I learnt lisp in 84; implemented my own lisp interpreter in 86 (that
was almost the required right-of-passage those days), teaching-
assisted scheme in 88 to a 'CS101' class, taught my own CS101 using
scheme in 91, then in order Miranda, gofer and (in this century)
python. So whether I am considered to be capable in lisp I dont know;
in any case scheme was for me one of the most happy and I can say
epiphanic experiences.

>
> That said, please note that I was referring to *elisp* and never
> mentioned *emacs*.  These are two quite different subjects and equating
> them and/or their documentation-- to borrow a phrase-- is just wrong.
>
> The topic was emacs development and how to encourage it.  This requires
> a knowledge of /elisp/.  In the confusion the point I made was lost, so
> I'll say it again: To encourage development, there could be better elisp
> documentation and tutorials.

I believe that one of the biggest obstacles to widespread emacs
adoption is (e)lisp.
Unfortunately at this point the discussion invariably degenerates into
a bad miscombination of  technical and sociological framing.

If the issue is technical, then encouraging development is out-of-
bounds
If the issue is social -- how to get today's kids interested in emacs
-- and I start with the slogan LEARN ELISP -- I need to go to
marketing kindergarten

Re: Issues with emacs

[Helmut Eller]

* rusi [2012-06-25 05:51] writes:

> I believe that one of the biggest obstacles to widespread emacs
> adoption is (e)lisp.
> Unfortunately at this point the discussion invariably degenerates into
> a bad miscombination of  technical and sociological framing.
>
> If the issue is technical, then encouraging development is out-of-
> bounds
> If the issue is social -- how to get today's kids interested in emacs
> -- and I start with the slogan LEARN ELISP -- I need to go to
> marketing kindergarten

I have my doubts that "kids" will make a better Emacs.  IMO good
programs are usually built by experienced and skilled developers.  I
don't think that it's accident that RMS wrote Emacs and GCC.  To make a
better Emacs, we would need highly skilled (and probably well paid)
people.  This is probably also the reason why Eclipse is successful: IBM
essentially killed the Smalltalk division for Eclipse.  Those people
already knew what is needed for a good IDE before they came to Eclipse.

Helmut

Re: Issues with emacs

[Tom]

Helmut Eller <eller.helmut <at> gmail.com> writes:
> 
> I have my doubts that "kids" will make a better Emacs.  IMO good
> programs are usually built by experienced and skilled developers.

Some of today's kids will be experienced and skilled developers
someday, but they will only use their skill to improve emacs if
they get to like it first as "kids".
  I
> To make a
> better Emacs, we would need highly skilled (and probably well paid)
> people.  

I think there are quite a few skilled developers who'd like to
spend their time on hacking Emacs instead of on some boring
business software, only they can't afford it to do it for free.

That's where crowdfunding could help and I don't think the payment
necessarily has to match what they earn working on a business software,
because if people have a motivation to work on something more
interesting then they often willing to accept lower payment
if they gain more professional satisfication from working
on the more interesting project.

Re: Issues with emacs

[Jeremiah Dodds]

Tom <adatgyujto@gmail.com> writes:

> Helmut Eller <eller.helmut <at> gmail.com> writes:
>> 
>> I have my doubts that "kids" will make a better Emacs.  IMO good
>> programs are usually built by experienced and skilled developers.
>
> Some of today's kids will be experienced and skilled developers
> someday, but they will only use their skill to improve emacs if
> they get to like it first as "kids".
>   I
>> To make a
>> better Emacs, we would need highly skilled (and probably well paid)
>> people.  
>
> I think there are quite a few skilled developers who'd like to
> spend their time on hacking Emacs instead of on some boring
> business software, only they can't afford it to do it for free.
>
> That's where crowdfunding could help and I don't think the payment
> necessarily has to match what they earn working on a business software,
> because if people have a motivation to work on something more
> interesting then they often willing to accept lower payment
> if they gain more professional satisfication from working
> on the more interesting project.

I, for one, would gladly work on emacs full time if I was making enough
to pay my (frugal) bills from it. 

Re: Issues with emacs

[Tom]

Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
> >
> > That's where crowdfunding could help and I don't think the payment
> > necessarily has to match what they earn working on a business software,
> > because if people have a motivation to work on something more
> > interesting then they often willing to accept lower payment
> > if they gain more professional satisfication from working
> > on the more interesting project.
> 
> I, for one, would gladly work on emacs full time if I was making enough
> to pay my (frugal) bills from it. 
> 

And what's holding you back from giving it a try? The
crowdfunding infrastructure is there (Kickstarter and co.), and
it's well proven for other projects.

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.

Re: Issues with emacs

[Jeremiah Dodds]

Tom <adatgyujto@gmail.com> writes:

> Jeremiah Dodds <jeremiah.dodds <at> gmail.com> writes:
>> >
>> > That's where crowdfunding could help and I don't think the payment
>> > necessarily has to match what they earn working on a business software,
>> > because if people have a motivation to work on something more
>> > interesting then they often willing to accept lower payment
>> > if they gain more professional satisfication from working
>> > on the more interesting project.
>> 
>> I, for one, would gladly work on emacs full time if I was making enough
>> to pay my (frugal) bills from it. 
>> 
>
> And what's holding you back from giving it a try? The
> crowdfunding infrastructure is there (Kickstarter and co.), and
> it's well proven for other projects.
>
> 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.

I actually may give it a try in the future, I'm working on launching a
kickstarter for a project that I've wanted to complete for a long time,
and the idea of crowdfunding specific features for a piece of software
and implementing them is a pretty interesting idea.

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.

Re: Issues with emacs

[notbob]

On 2012-06-26, Tom <adatgyujto@gmail.com> wrote:


> But it's also a possible that a skilled developer could make a
> permanent living from developing Emacs features.

Does emacs REALLY need MORE features!?  It's already so complex, now,
as to seem almost unfathomable to many.  What emacs needs is some
refining, perhaps even some simplification.  I use slrn cuz it's much
easier to follow, use, and config than gnus, even though they're
basically the same utility.  Another thing that can't hurt is better
documentation.  The only thing more arcane and vague than the official
emacs manual are those geeky man pages.  One could also make some
money off documentation.  I paid hard cash for the emacs O'Reilly books
and consider it money well spent.  In fact, I need to buy the 3rd
edition and probably will.

nb

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

Re: Issues with emacs

[Dustin Hemmerling]

notbob <notbob@nothome.com> writes:

> On 2012-06-26, Tom <adatgyujto@gmail.com> wrote:
>
>
>> But it's also a possible that a skilled developer could make a
>> permanent living from developing Emacs features.
>
> Does emacs REALLY need MORE features!?  It's already so complex, now,
> as to seem almost unfathomable to many.  What emacs needs is some
> refining, perhaps even some simplification.  I use slrn cuz it's much
> easier to follow, use, and config than gnus, even though they're
> basically the same utility.  Another thing that can't hurt is better
> documentation.  The only thing more arcane and vague than the official
> emacs manual are those geeky man pages.  One could also make some
> money off documentation.  I paid hard cash for the emacs O'Reilly books
> and consider it money well spent.  In fact, I need to buy the 3rd
> edition and probably will.
>
> nb

I'm glad to hear you had success with the O'Reilly book, because I had
the exact opposite experience.  I found it totally superficial compared
to both the official Emacs and Elisp Info manuals, outdated, and far
below O'Reilly's often very meagre standards.  I read my copy at the
library, because I wouldn't pay hard, soft, cold, or hot cash for
anything even tangentially connected to esr.  The integrated manuals and
the self-documenting features are some of my favourite features of
Emacs, personally.

-- 
Dustin Hemmerling.

Re: Issues with emacs

[Sivaram Neelakantan]

On Tue, Jun 26 2012,notbob  wrote:

> On 2012-06-26, Tom <adatgyujto@gmail.com> wrote:
>
>
>> But it's also a possible that a skilled developer could make a
>> permanent living from developing Emacs features.
>
> Does emacs REALLY need MORE features!?  It's already so complex, now,
> as to seem almost unfathomable to many.  What emacs needs is some
> refining, perhaps even some simplification.  I use slrn cuz it's much
> easier to follow, use, and config than gnus, even though they're
> basically the same utility.  Another thing that can't hurt is better
> documentation.  The only thing more arcane and vague than the official
> emacs manual are those geeky man pages.  One could also make some
> money off documentation.  I paid hard cash for the emacs O'Reilly books
> and consider it money well spent.  In fact, I need to buy the 3rd
> edition and probably will.
>

I don't get this better documentation part; tangentially, it might be
an asian thing.

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

Re: Issues with emacs

[Richard Riley]

notbob <notbob@nothome.com> writes:

> On 2012-06-26, Tom <adatgyujto@gmail.com> wrote:
>
>> But it's also a possible that a skilled developer could make a
>> permanent living from developing Emacs features.
>
> Does emacs REALLY need MORE features!?  It's already so complex, now,
> as to seem almost unfathomable to many.  What emacs needs is some

are features supported out of the box by other top end editors : proper
syntax/semantic based completion and code navigation that works "out of
the box" (cedet one day I hope), mixed mode editing (a must despite many
purists sneering at it)and decent java support to the level of eclipse.

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

Re: Issues with emacs

[Tom]

Richard Riley <rileyrg <at> gmail.com> writes:

> >
> > Does emacs REALLY need MORE features!?  It's already so complex, now,
> > as to seem almost unfathomable to many.  What emacs needs is some
> 
> are features supported out of the box by other top end editors : proper
> syntax/semantic based completion and code navigation that works "out of
> the box" (cedet one day I hope), mixed mode editing (a must despite many
> purists sneering at it)and decent java support to the level of eclipse.
> 

There is a discussion of an article on Reddit on Java development in Emacs
vs. IntelliJ IDEA. The article is a bit misguided (doesn't know about
etags), but in the comments there are some useful comparisons.

For example:

   I haven't used ctags in a few years, but it would have to improve
   significantly for me to want to switch back. It's hard to compare
   the two once you've used IntelliJ on a large project for a while.
   
   - The Parsing was very basic (a glorified regex?) in ctags. It
     had limited-to-no knowledge of the context of a variable, and I
     don't rememeber it being useful for much other than global
     names. A variable that is private to a class or package
     hierarchy, and given a name that is used in many other classes
     of the project (like "id") can still be navigated-to or renamed
     instantly and safely.
   
   - Support for embedding languages inside others. Javascript
     inside HTML? SQL inside Java? CSS inside HTML inside a template
     language? You can still use navigation, completion and
     refactoring. IntelliJ supports a bunch of (templating,
     programming and scripting) languages and can usually embed (and
     parse) them fairly arbitrarily (You can even tell it "this java
     string contains Javascript" and it will syntax highlight, provide
     completion and (potentially) allow navigation within it.
   
   - Find Usages. You can reliably and instantly view where a
     property or class is being used. It doesn't matter if there are
     other variables of the same name in other packages, classes or
     contexts. It will also show where the variable is used in
     templates files (or "SQL" if you're using a supported ORM like
     Hibernate).

http://www.reddit.com/r/programming/comments/vqb9l/
programmer_productivity_emacs_versus_intellij_idea/


It would be nice to see similar features in emacs. The question
is why it is not happening. My guess is those who have to do
heavy Java development have moved to Eclipse/IDEA and other tools
already and those who still use Emacs for C, Lisp, orgmode, etc.
don't care about Java development or see it as wasted time to
implement such features in Emacs when other more capable tools
exist.

The problem is this decreases the overall usefulness of emacs,
because Java development is lost ground and due to lack of
motivation/resources there is no real effort to make emacs a
competitive tool again for Java development.

Re: Issues with emacs

[notbob]

On 2012-06-26, Richard Riley <rileyrg@gmail.com> wrote:

> To say its already too complex is silly. 

Granted, but like my view, yours is only opinion, not fact.  

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.

> You only need to be aware of the features YOU need.  

I don't need a lot of things.  I don't need about 90% of what emacs
can do.  In fact, quite often I use something else cuz emacs is not
always the best choice.  Piling on more features instead of improving
the ones it already has is not always in the best interest of the
software package, as a whole.  There's a less flattering term for that
sort of approach.  It's called bloat.

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/>

RE: Issues with emacs

[Ludwig, Mark]

> From: notbob
> Sent: Tuesday, June 26, 2012 2:28 PM
> To: help-gnu-emacs@gnu.org
> Subject: Re: Issues with emacs
> 
> I realize emacs would be much more useful if I was a programmer,
> particularly a lisp programmer, but I'm not.  

This summarizes the split among the Emacs user community that I see in this discussion thread.  Those of us who are programmer types are probably a lot happier with Emacs as it is (and as it has been since its start many decades ago) than those who aren't programmer types.  Partly it's mindset, but also gets to depth of knowledge about how to use the tool -- and how to change what it does/how it works.

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

Re: Issues with emacs

[Pascal J. Bourguignon]

"Ludwig, Mark" <ludwig.mark@siemens.com> writes:

>> From: notbob
>> Sent: Tuesday, June 26, 2012 2:28 PM
>> To: help-gnu-emacs@gnu.org
>> Subject: Re: Issues with emacs
>> 
>> I realize emacs would be much more useful if I was a programmer,
>> particularly a lisp programmer, but I'm not.  
>
> This summarizes the split among the Emacs user community that I see in
> this discussion thread.  Those of us who are programmer types are
> probably a lot happier with Emacs as it is (and as it has been since
> its start many decades ago) than those who aren't programmer types.
> Partly it's mindset, but also gets to depth of knowledge about how to
> use the tool -- and how to change what it does/how it works.
>
> 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.

This hasn't to be.  As RMS shown us, even secretaries can like emacs, if
we just NOT tell them they have to program it: just tell them about
"configuring" it.  Don't ever mention the words "program",
"programming", etc.

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 {}.

Re: Issues with emacs

[PJ Weisberg]

On Tue, Jun 26, 2012 at 12:49 PM, Ludwig, Mark <ludwig.mark@siemens.com> wrote:
>> From: notbob
>> Sent: Tuesday, June 26, 2012 2:28 PM
>> To: help-gnu-emacs@gnu.org
>> Subject: Re: Issues with emacs
>>
>> I realize emacs would be much more useful if I was a programmer,
>> particularly a lisp programmer, but I'm not.
>
> This summarizes the split among the Emacs user community that I see in this discussion thread.  Those of us who are programmer types are probably a lot happier with Emacs as it is (and as it has been since its start many decades ago) than those who aren't programmer types.  Partly it's mindset, but also gets to depth of knowledge about how to use the tool -- and how to change what it does/how it works.

http://notinventedhe.re/on/2010-1-18
http://notinventedhe.re/on/2010-1-19
http://notinventedhe.re/on/2010-1-20
http://notinventedhe.re/on/2010-1-28

Someone in this thread mentioned the M-< and M-> keys to go to the
beginning and end of the buffer.  I never knew about those, but I
wrote my own command bound to C-e that goes to the end of the line
when invoked once, then to the end of the buffer if invoked twice in a
row*.  And I was very happy with the result.  I use IDEs that provide
more functionality, but I'm always annoyed when I want to redefine a
command and I can't.  I understand that this is very atypical of
today's computer user, but I still have difficulty putting myself into
the mindset of someone who isn't even interested in learning how to
modify a program's behavior.

*The C-a version might need to be tapped three times to go to the
beginning of the buffer, because it makes a stop at the first
non-whitespace character on the line with the first tap.

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

http://www.swisstechtools.com/proddetail.aspx?pid=5

It's about the size of a small knife, but it's also a screwdriver and
a bottle opener and fits nicely on my key chain (a bit bigger than my
house key and much smaller than my car key).

My point is that you can have lots of features and as long as they
stay hidden and don't take up much space when you're not using them,
they cost nothing.  I've never used the bottle opener, but I have no
desire to get rid of it, and maybe some day I'll need to open a
bottle.  I've never used Gnus, but it's never gotten in my way either.

Re: Issues with emacs

[John Wiegley]

>>>>> PJ Weisberg <pj@irregularexpressions.net> writes:

> Someone in this thread mentioned the M-< and M-> keys to go to the beginning
> and end of the buffer.  I never knew about those, but I wrote my own command
> bound to C-e that goes to the end of the line when invoked once, then to the
> end of the buffer if invoked twice in a row*.  And I was very happy with the
> result.  I use IDEs that provide more functionality, but I'm always annoyed
> when I want to redefine a command and I can't.  I understand that this is
> very atypical of today's computer user, but I still have difficulty putting
> myself into the mindset of someone who isn't even interested in learning how
> to modify a program's behavior.

allout.el offers this same C-a/C-e functionality.  You can use it even if you
don't have an outline in the buffer: M-x allout-mode.

John

Re: Issues with emacs

[notbob]

On 2012-06-26, Ludwig, Mark <ludwig.mark@siemens.com> wrote:
>
> 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.

You seen SAKs lately?  Bloat is exactly what they have a lot of.  I
have two blades on my Champ that I didn't have a clue what they were
intended for.  I was even more dismayed when I finally did learn their
purpose and decided they were still pretty much useless.  That's
bloat.  ;)

nb  

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

Re: Issues with emacs

[John Wiegley]

>>>>> notbob  <notbob@nothome.com> writes:

> Does emacs REALLY need MORE features!?  It's already so complex, now, as to
> seem almost unfathomable to many.  What emacs needs is some refining,
> perhaps even some simplification.

Bear in mind that Emacs is layered, with much of that layering in Lisp and
completely optional.

If you built and ran only "temacs" (which gets built when you "make" in the
Emacs build tree), I think that would satisfy every desire you ever had for
Emacs to be simple -- to a fault.

John

re: temacs

[Jambunathan K]

"John Wiegley" <johnw@newartisans.com> writes:

> If you built and ran only "temacs" (which gets built when you "make" in the
> Emacs build tree), I think that would satisfy every desire you ever had for
> Emacs to be simple -- to a fault.

ISTM there is a perceived need for emacs-lite - may be temacs would be
the right candidate.  Can temacs be distributed as a binary for various
platforms.

For git commits, rebases etc I use jemacs as EDITOR.  Can I use temacs
for such simple editing jobs?

What would the faults be?
-- 

Re: temacs

[Ken Goldman]

On 6/27/2012 5:23 AM, Jambunathan K wrote:
> "John Wiegley"<johnw@newartisans.com>  writes:
>
>> If you built and ran only "temacs" (which gets built when you "make" in the
>> Emacs build tree), I think that would satisfy every desire you ever had for
>> Emacs to be simple -- to a fault.
>
> ISTM there is a perceived need for emacs-lite - may be temacs would be
> the right candidate.  Can temacs be distributed as a binary for various
> platforms.
>
> For git commits, rebases etc I use jemacs as EDITOR.  Can I use temacs
> for such simple editing jobs?
>
> What would the faults be?

The 'fault' would be a fork in emacs.

What's the perceived need?  The executable isn't big by today's 
standards.  If you don't use a feature like email, browser, or debugger, 
it doesn't get in the way.

I use emacs for commits.  It pops up a frame, I add some comments and 
exit.  I can't imagine how it could be simpler.

Re: temacs

[John Wiegley]

>>>>> Ken Goldman <kgoldman@us.ibm.com> writes:

> What's the perceived need?  The executable isn't big by today's standards.
> If you don't use a feature like email, browser, or debugger, it doesn't get
> in the way.

emacs -Q uses 10MB RSS on my machine.  Also, it will do just about anything
faster than temacs, since temacs needs to load in even the most rudimentary
functions as it runs.

Thus, Emacs is already as simple as you need it to be.  Just don't load
anything in your .emacs.

John

Re: temacs

[Bastien]

"John Wiegley" <johnw@newartisans.com> writes:

> Thus, Emacs is already as simple as you need it to be.  Just don't load
> anything in your .emacs.

Which points at the trap many newbies fall in: adding to many stuff to
their .emacs.  Some of them are just experimental, then get forgotten,
then you wake up one day wondering why launching Emacs takes too long.

One thing I would need myself: a tool that detects duplicates in
.emacs-custom.el and .emacs and suggests to merge into .emacs-custom.el.

That way I could well experiment in my .emacs, then stabilize stuff in
.emacs-custom.el (which I only use for things I really want for long
with the same value.)

-- 
 Bastien

Re: temacs

[Ken Goldman]

On 6/28/2012 4:49 AM, Bastien wrote:
> "John Wiegley"<johnw@newartisans.com>  writes:
>
>> Thus, Emacs is already as simple as you need it to be.  Just don't load
>> anything in your .emacs.
>
> Which points at the trap many newbies fall in: adding to many stuff to
> their .emacs.  Some of them are just experimental, then get forgotten,
> then you wake up one day wondering why launching Emacs takes too long.

I think you've defined the wrong trap - starting emacs every time you 
want to edit a file and then complaining that launching takes too long.

If anything, perhaps it should be easier to install and use 
client-server emacs.  Windows programs (Firefox, Office, ...) do that by 
default.

I have many years of accumulated code in my .emacs.  I load all kinds of 
packages, some that I rarely use.  It doesn't matter.  I start emacs 
once every few months, so 10 seconds doesn't matter at all.

Re: temacs

[rusi]

On Jun 30, 12:37 am, Ken Goldman <kgold...@us.ibm.com> wrote:
> On 6/28/2012 4:49 AM, Bastien wrote:
>
> > "John Wiegley"<jo...@newartisans.com>  writes:
>
> >> Thus, Emacs is already as simple as you need it to be.  Just don't load
> >> anything in your .emacs.
>
> > Which points at the trap many newbies fall in: adding to many stuff to
> > their .emacs.  Some of them are just experimental, then get forgotten,
> > then you wake up one day wondering why launching Emacs takes too long.
>
> I think you've defined the wrong trap - starting emacs every time you
> want to edit a file and then complaining that launching takes too long.
>
> If anything, perhaps it should be easier to install and use
> client-server emacs.  Windows programs (Firefox, Office, ...) do that by
> default.
>
> I have many years of accumulated code in my .emacs.  I load all kinds of
> packages, some that I rarely use.  It doesn't matter.  I start emacs
> once every few months, so 10 seconds doesn't matter at all.

Parkinson law's says: http://en.wikipedia.org/wiki/Parkinson%27s_law

     Work expands so as to fill the time available for its completion.

Likewise one could say:
    Mess expands so as to fill the diskspace available for it

Re: temacs

[suvayu ali]

Hi Jambunathan,

On Wed, Jun 27, 2012 at 11:23 AM, Jambunathan K <kjambunathan@gmail.com> wrote:
> For git commits, rebases etc I use jemacs as EDITOR.  Can I use temacs
> for such simple editing jobs?

I just tried it, compared with emacs -Q it is quite a bit slow.

$ time /path/to/temacs -Q -f kill-emacs

real    0m4.106s
user    0m3.825s
sys     0m0.090s

$ time emacs -f kill-emacs

real    0m5.056s
user    0m2.894s
sys     0m0.182s

$ time emacs -q -f kill-emacs

real    0m1.508s
user    0m0.453s
sys     0m0.078s

$ time emacs -Q -f kill-emacs

real    0m0.990s
user    0m0.242s
sys     0m0.045s

This is what I use for git commits:

$ git config --get core.editor
emacs -nw -Q -l ~/.emacs.d/minimal-commit.el

$ time emacs -nw -Q -l ~/.emacs.d/minimal-commit.el -f kill-emacs

real    0m0.665s
user    0m0.270s
sys     0m0.021s

You can find minimal-commit.el here:

<https://github.com/suvayu/.emacs.d/blob/master/minimal-commit.el>

HTH

-- 
Suvayu

Open source is the future. It sets us free.

Re: temacs

[Alp Aker]

>> For git commits, rebases etc I use jemacs as EDITOR.  Can I use temacs
>> for such simple editing jobs?

If the concern is with startup time, then a cleaner solution is just
not to create a new emacs instance every time, and instead keep a
single emacs process running that you connect to every time git needs
to invoke an editor.  In other words, start emacs just once, as a
daemon (or put an existing emacs process into server mode), and have
git invoke the editor as "emacsclient" rather than "emacs".  See the
info node "(emacs) Emacs Server" for an overview of the various ways
one can use such a set up.

Re: temacs

[Ken Goldman]

On 6/27/2012 12:24 PM, Alp Aker wrote:
>>> For git commits, rebases etc I use jemacs as EDITOR.  Can I use temacs
>>> for such simple editing jobs?
>
> If the concern is with startup time, then a cleaner solution is just
> not to create a new emacs instance every time, and instead keep a
> single emacs process running that you connect to every time git needs
> to invoke an editor.  In other words, start emacs just once, as a
> daemon (or put an existing emacs process into server mode), and have
> git invoke the editor as "emacsclient" rather than "emacs".  See the
> info node "(emacs) Emacs Server" for an overview of the various ways
> one can use such a set up.
>

Absolutely!

I start emacs perhaps twice a year.  Why would I care how log it takes 
to start up?

Re: temacs

[John Wiegley]

>>>>> Jambunathan K <kjambunathan@gmail.com> writes:

> For git commits, rebases etc I use jemacs as EDITOR.  Can I use temacs for
> such simple editing jobs?

> What would the faults be?

temacs basically has only the C-implemented Lisp functions available.  Yet
even some of the most basic editing commands are found in simple.el and
subr.el.  I think you'd find temacs to be a pretty meager experience.  But how
about just giving it a try?

John

Re: temacs

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Wed, 04 Jul 2012 23:14:28 -0500
> 
> temacs basically has only the C-implemented Lisp functions
> available.

This is false.  When you run temacs, it begins by loading all of
loadup.el, which basically is everything the dumped Emacs has.

Re: temacs

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> temacs basically has only the C-implemented Lisp functions available.

> This is false.  When you run temacs, it begins by loading all of loadup.el,
> which basically is everything the dumped Emacs has.

Really?  I thought that only happened during dumping because the Makefile
explicit does "./temacs -batch -l loadup dump".  If it always loads loadup,
then why the -l loadup?

John

Re: temacs

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Sat, 07 Jul 2012 11:51:24 -0500
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> temacs basically has only the C-implemented Lisp functions available.
> 
> > This is false.  When you run temacs, it begins by loading all of loadup.el,
> > which basically is everything the dumped Emacs has.
> 
> Really?  I thought that only happened during dumping because the Makefile
> explicit does "./temacs -batch -l loadup dump".  If it always loads loadup,
> then why the -l loadup?

I think because temacs only does that automatically when invoked
interactively, not in -batch mode.  But you should be able to see that
clearly from the code.

Re: Issues with emacs

[Stefan Monnier]

>> But it's also a possible that a skilled developer could make a
>> permanent living from developing Emacs features.
> Does emacs REALLY need MORE features!?  It's already so complex, now,
> as to seem almost unfathomable to many.

I agree it has some very complex parts (e.g. the display engine), but
I strongly suspect that it's not what you perceive as complex.

E.g. making Gnus less complex for the end user will require more work,
more features elsewhere.


        Stefan

Re: Issues with emacs

[rusi]

On Jun 25, 12:45 pm, Helmut Eller <eller.hel...@gmail.com> wrote:
> * rusi [2012-06-25 05:51] writes:

> > If the issue is technical, then encouraging development is out-of-
> > bounds
> > If the issue is social -- how to get today's kids interested in emacs
> > -- and I start with the slogan LEARN ELISP -- I need to go to
> > marketing kindergarten
>
> I have my doubts that "kids" will make a better Emacs.  IMO good
> programs are usually built by experienced and skilled developers.  I
> don't think that it's accident that RMS wrote Emacs and GCC.  To make a
> better Emacs, we would need highly skilled (and probably well paid)
> people.

There are two extreme points:
- anyone and everyone adds code to the difficult/critical parts
resulting in a mess and breakdown
- no one codes; after a while emacs dies

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

Tom wrote:
> Some of today's kids will be experienced and skilled developers
> someday, but they will only use their skill to improve emacs if
> they get to like it first as "kids".

Very well put

Re: Issues with emacs

[Thien-Thi Nguyen]

() rusi <rustompmody@gmail.com>
() Mon, 25 Jun 2012 20:08:06 -0700 (PDT)

   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/adhoc.el>.]

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

Re: Issues with emacs

[MBR]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

On 6/25/2012 1:51 AM, rusi wrote:
> I believe that one of the biggest obstacles to widespread emacs
> adoption is (e)lisp.
> Unfortunately at this point the discussion invariably degenerates into
> a bad miscombination of  technical and sociological framing.
>
> If the issue is technical, then encouraging development is out-of-
> bounds
> If the issue is social -- how to get today's kids interested in emacs
> -- and I start with the slogan LEARN ELISP -- I need to go to
> marketing kindergarten
At FSF's annual LibrePlanet Conference just a few months ago, Ruby 
creator Yukihiro 'matz' Matsumoto gave a talk entitled, "How Emacs 
changed my life".  In that talk, he spoke of the great amount of time he 
spent in the early 1990s studying the Emacs source code.  He said he 
learned a lot from that about good programming practices and he applied 
those lessons when he designed Ruby.

You wrote: "If the issue is social -- how to get today's kids interested 
in emacs -- and I start with the slogan LEARN ELISP -- I need to go to 
marketing kindergarten."

On the other hand, if someone with street cred like Matz says it, some 
of today's "kids" might take up the challenge. What about a logo like 
this linked to a video of Matz' "How Emacs changed my life" talk posted 
on youtube.com?



                                Mark Rosenthal
                                mbr@arlsoft.com <mailto:mbr@arlsoft.com>


[-- Attachment #2.1: Type: text/html, Size: 3019 bytes --]

[-- Attachment #2.2: iijfgcbb.jpg --]
[-- Type: image/jpeg, Size: 89009 bytes --]

Re: Issues with emacs

[Bug Dout]

ken <gebser@mousecar.com> writes:

> 5. Make the elisp documentation and tutorials so easy and fun to learn
> that tons of people actually want to write code.

I think I'm tired of this shit. Everything in America has to be fun, and
easy, or we spoiled Americans can't be bothered.

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

RE: Issues with emacs (was Emacs users a dying breed?)

[Ugly Sean]

Sorry the only patches I have to offer you sew on jackets and jeans.  Some
of us dabbled in BASIC in the 1980s and never progressed.


-----Original Message-----
From: help-gnu-emacs-bounces+ugly=frightenstein.com@gnu.org
[mailto:help-gnu-emacs-bounces+ugly=frightenstein.com@gnu.org] On Behalf Of
Bastien
Sent: Friday, June 22, 2012 14:01
To: Drew Adams
Cc: 'rusi'; help-gnu-emacs@gnu.org
Subject: Re: Issues with emacs (was Emacs users a dying breed?)

The good news is that, whether Emacs users are a dying breed or not, the
only remedy to this hypothetical issue is to have more Emacs developers.

Patches welcome!

--
 Bastien