Emacs users a dying breed?

[S Boucher]

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

Regards,

[Henri-Paul Indiogine]

I do not know many people (not on-line), and as far as I can tell, I
am the only one using Emacs.

Still, I could not function without it. I just wish that the setup
of GNU for email were easier.

Best,
Henri-Paul


--
Henri-Paul Indiogine

Curriculum & Instruction
Texas A&M University
TutorFind Learning Centre
http://www.tutorfind.ca

Email: hindi...@gmail.com
Skype: hindiogine

[Pascal J. Bourguignon]

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

[Jeremiah Dodds]

S Boucher <st...@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? :-)
>

> Regards,


I have never worked anywhere where anyone else used Emacs. I've also
never worked anywhere where people were not pretty impressed with the
level of efficiency I had while editing, particularly for things like JS
frameworks that don't have widespread editor support.

There are definitely things that could use improvement in Emacs, but so
far, for the type of stuff I do, it's *by far* the most versatile tool
in my toolbox.

[Dan Espen]

Jeremiah Dodds <jeremia...@gmail.com> writes:

> S Boucher <st...@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? :-)
>>
>> Regards,
>
>
> I have never worked anywhere where anyone else used Emacs. I've also
> never worked anywhere where people were not pretty impressed with the
> level of efficiency I had while editing, particularly for things like JS
> frameworks that don't have widespread editor support.

Emacs often spreads quietly.

Lots of people I've worked with have seen the light.

--
Dan Espen

[Henri-Paul Indiogine]

I myself changed from vi and other editors to emacs a couple of years ago.

2012/6/17 Dan Espen <des...@verizon.net>:

> Emacs often spreads quietly.
>
> Lots of people I've worked with have seen the light.



--

[Jai Dayal]

In the research community, Emacs and VIM are going strong.  I think most users use Vim, but it's not by a devastating margin.

On Sun, Jun 17, 2012 at 8:35 PM, Henri-Paul Indiogine <hindi...@gmail.com> wrote:

I do not know many people (not on-line), and as far as I can tell, I
am the only one using Emacs.

Still, I could not function without it.   I just wish that the setup
of GNU for email were easier.

Best,
Henri-Paul

[Laurent Hoeltgen]

On 06/18/2012 04:32 AM, S Boucher 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. 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,
>

Hi,

at my job there are about 4 Emacs (and roughly 6 vi) users (out of 12).
Also, while being at the university, I was recommended Emacs in several
courses. Considering the sheer amount of text editors that actually
exist, I'd say, that the frequency at which you encounter emacs, is a
good sign for its popularity and large user-base.

Regards,
Laurent

[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

[Pascal J. Bourguignon]

We'll just keep maintaining it ourselves.

[Susan Cragin]

Oh, I think the base is increasing slowly, numerically. I'm a non-technical user, non-programmer, and I started using it because of org-mode. I use it for research, for my daily planner, that sort of thing.
Once I started using it, I couldn't stop. It doesn't take very many keystrokes to make one realize how special it is.

-----Original Message-----
>From: djc <ne...@resiak.org>
>Sent: Jun 18, 2012 5:32 AM
>To: help-gn...@gnu.org
>Subject: Re: Emacs users a dying breed?
>
>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

[Thien-Thi Nguyen]

() S Boucher <st...@yahoo.com>
() Sun, 17 Jun 2012 19:32:26 -0700 (PDT)

impression that Emacs users is a dying breed.

everybody dies, even those who dance in fingered trees.
so much pollen unhoarded, unhonied, awaiting next breeze!

[notbob]

On 2012-06-18, Dan Espen <des...@verizon.net> wrote:

> Emacs often spreads quietly.
>
> Lots of people I've worked with have seen the light.

Then there are users like myself. Real lazy ppl who find it
unacceptably annoying to have to add an extra keystroke each time they
move from one mode to the other, like all things vi. I probably
learned vi first, but kept wondering WTF! is it with this constantly
changing modes nightmare. This is insane! So, because of slrn, I
discovered jed. Later I discovered bash and many other linux
utilities use emacs keystrokes. Finally, I took the plunge and got
THE BOOK. The rest is history, as they say. I don't particularly
like a lot of things about emacs, I suck as a progrmmer so don't do
LISP, I don't use gnus, and am not a developer, and jed has better txt
highlighting already enabled. Even as I struggle to learn C, I still
don't understand how to compile a simple C program from inside emacs.
Regardless, it's the coolest bestest file mgr and txt editor I know
and I will always use it on the command line and would rather use M$
Windows notepad than vi.

</rant>


nb


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

[Andreas Röhler]

if Emacs is the front-door, who might be interested in it's backyard, who cares?
if Emacs is the back-door, who might sit inside, awaiting it's servants?

[suvayu ali]

On Mon, Jun 18, 2012 at 12:53 PM, Susan Cragin
<susan...@earthlink.net> wrote:
> Oh, I think the base is increasing slowly, numerically. I'm a non-technical user, non-programmer, and I started using it because of org-mode. I use it for research, for my daily planner, that sort of thing.

I hear this quite often. As a fervent org-mode user myself, it makes me
happy. :)

I am a physics researcher and I use it for almost everything (except for
web browsing, emails and shell).

--
Suvayu

Open source is the future. It sets us free.

[Sivaram Neelakantan]

On Mon, Jun 18 2012,S Boucher 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.  Most places I work,

> I'm in the minority - and that's an understatement - as an Emacs user.

and it still is, after a decade of using it in my office space.


[snipped 5 lines]

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

With the features it already has, I wouldn't even mind if development
stopped, it still beats other editors hands down. If anything, I've
pretty much stopped checking out every new editor that comes out every
few years; they seem to implement something that is obvious or trivial
to summon up in Emacs(not that the actual development of said feature
was trivial in Emacs).

[snipped 4 lines]


sivaram
--

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

[jid...@jidanni.org]

Too late in the game to have me learn a different editor.

[Pascal J. Bourguignon]

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

> On 2012-06-18, Dan Espen <des...@verizon.net> wrote:
>
>> Emacs often spreads quietly.
>>
>> Lots of people I've worked with have seen the light.
>
> Then there are users like myself. Real lazy ppl who find it
> unacceptably annoying to have to add an extra keystroke each time they
> move from one mode to the other, like all things vi. I probably
> learned vi first, but kept wondering WTF! is it with this constantly
> changing modes nightmare. This is insane! So, because of slrn, I
> discovered jed. Later I discovered bash and many other linux
> utilities use emacs keystrokes. Finally, I took the plunge and got
> THE BOOK. The rest is history, as they say. I don't particularly
> like a lot of things about emacs, I suck as a progrmmer so don't do
> LISP, I don't use gnus, and am not a developer, and jed has better txt
> highlighting already enabled. Even as I struggle to learn C, I still
> don't understand how to compile a simple C program from inside emacs.

Assuming you have the current buffer pgm.c,
you just type M-x compile RET pgm RET

M-x compile RET will present you a minibuffer with "make -k " in it.
Typing pgm RET will make it run: make -k pgm
Since you probably don't have a Makefile in the same directory as pgm.c,
the default rules will be used, so pgm will be built from pgm.c using
the C compiler.

If your program doesn't take any stdin input, you can even run it at the
same time: M-x compile RET pgm && ./pgm RET

> Regardless, it's the coolest bestest file mgr and txt editor I know
> and I will always use it on the command line and would rather use M$
> Windows notepad than vi.
>
> </rant>
>
>
> nb

--

[Pascal J. Bourguignon]

suvayu ali <fatkasuv...@gmail.com> writes:

> On Mon, Jun 18, 2012 at 12:53 PM, Susan Cragin
> <susan...@earthlink.net> wrote:
>> Oh, I think the base is increasing slowly, numerically. I'm a non-technical user, non-programmer, and I started using it because of org-mode. I use it for research, for my daily planner, that sort of thing.
>
> I hear this quite often. As a fervent org-mode user myself, it makes me
> happy. :)
>
> I am a physics researcher and I use it for almost everything (except for
> web browsing, emails and shell).

Give it a try!

M-x w3m-browse-url RET http://google.com RET
M-x mail RET to send one
M-x rmail RET to read your mail (some configuration needed)
M-x shell RET or M-x term RET

[notbob]

On 2012-06-18, Pascal J. Bourguignon <p...@informatimago.com> wrote:

> Since you probably don't have a Makefile in the same directory as pgm.c,
> the default rules will be used, so pgm will be built from pgm.c using
> the C compiler.

Thanks, Pascal. Since I use Slackware, which has jes about everything
needed for compiling from source, I'll give it a try. Both make and gcc are in
the same /usr/bin/ dir.

[Ugly Sean]

-----Original Message-----
From: jid...@jidanni.org
Sent: Monday, June 18, 2012 14:14
To: help-gn...@gnu.org
Subject: Re: Emacs users a dying breed?

If you are capable of learning then it's not too late.
However, if Emacs is the editor you know, why bother changing?

[Philipp Haselwarter]

You can't really know until you've tried, right? I sometimes wonder what
it's like on the other side… for two reasons:

1) Text editing actually seems quite efficient in the land of 666;
vimgolf [1] might or might not be representative, but the challenges and
results [2] are quite interesting. As Mickey Petersen puts it [3]:

> It’s obvious to most of us that to attempt a “fewest possible
> keystrokes” exercise in Emacs will invariably end in tears, as we
> can’t compete against vim in that regard; but with that said, we do
> have a lot of tricks up our sleeve.


And, more importantly,

2) Unix philosophy, in Doug McIlroy's words [4]:

> This is the Unix philosophy: Write programs that do one thing and do
> it well. Write programs to work together. Write programs to handle
> text streams, because that is a universal interface.

Eric Steven Raymond's "The Art of Unix Programming" discusses
editors [5] and the "Emacs question" in particular [6]:

> Emacs could be considered a virtual machine or framework around a
> collection of small, sharp tools (the modes) that happen to be written
> in Lisp.

Emacs does not contradict the philosophy /per se/, but sometimes I wish
Emacs was more of a low level utility. As it stands, Emacs does many
small tasks very well. One aspect that makes the workflow particularly
pleasant is that all these tools work together so well. Take the
kill-ring for example: It is by far the most powerful clipboard facility
I've used. But I'd like to be able to use it in all my applications, not
only those written in elisp. Emacs' entirely customizable key system is
another example of a tool that I'd like to have everywhere on my
desktop.

As it currently stands, all of the (elisp) programs that want to
leverage the power of Emacs' "global facilities" have to run in the same
main process. But there is a price to pay for mixing the core features
with the high-level programs:

- concurrency/locking
the classic example being programs that do networking and block the
whole session

- shared state ("everything is global")
- usability: huge buffer lists result in requiring window-manager
like capabilities
- configuration: a common look of the GUI
- stability: one misbehaving program can blow up the whole session
- task parallelism: most programs are intended to have only one
running instance per session (ex.: a gnus for work, one for private
mail; debugging with several instances of gud simultaneously)
- security: I want my email client to know my IMAP password, but not
my IRC client

- auxiliary tasks
tasks that are already solved on the desktop are duplicated, such as
window and workspace management

One could say that Emacs doesn't do enough and solve these problems
"inside Emacs" by implementing concurrency, integrating firefox and
essentially becoming the desktop environment.

Or one could say that Emacs already does too much. The core features
could be factored out into a "text editing daemon". Elisp programs could
then connect to this daemon and share as much of their state with the
daemon as makes sense to them. Basically take the current
emacs-server/emacsclient situation a step further and transform the
client from a very thin client into a runtime.

I'm curious to see what emacs.devel is planning for Emacs25, now that 24
is finally released I think we can expect to see some action on
implementing new features. The two approaches are rather complementary
than exclusive; let's hope that both get some love.


[1] http://www.vimgolf.com/
[2] http://vimeo.com/timvisher/videos/page:1/sort:newest
[3] http://www.masteringemacs.org/articles/2011/10/29/fun-with-vimgolf-1-alphabetize-directory/
[4] http://www.faqs.org/docs/artu/ch01s06.html
[5] http://www.catb.org/~esr/writings/taoup/html/ch13s02.html
[6] http://www.catb.org/~esr/writings/taoup/html/ch13s03.html#id2967765

--
Philipp Haselwarter

[Pascal J. Bourguignon]

Common Lisp offers more (potential) solutions to these problems.
See for example Climacs and McClim.
But more work is needed.

That said, nothing prevents you to run several instances of emacs. I
usually run three: programming, erc, gnus.

When you use StumpWM, you can define your own window manager key
bindings and have a CL REPL into your window manager available.

I could only encourage you to embed ECL into all the applications you
use.

[notbob]

On 2012-06-19, Pascal J. Bourguignon <p...@informatimago.com> wrote:

> usually run three: programming, erc, gnus.

I probably would, but irssi is better than erc and slrn is better than
gnus. I will use them up on my ubuntu netbook, it having no real
developement base, but on my Slack box emacs is my primary editor,
even for slrn.

I try to learn something new about emacs every day, if only a
key-stroke. When I have the time, I read emacs lisp tutorial. It's
excellent and very well written. While I'm a rank amateur at emacs, I
can't live without it. It's the first thing I install on any *nix box.

[Joe Corneli]

Riffing on Conrad Barski's LISP logos:

"Our little town is a hole. It always has been and still is. But now
it is a hole into the future. We’re going to
dump so much through this hole into your lousy world that everything will change
in it. Life will be different. It’ll be fair. Everyone will have
everything that he
needs. Some hole, huh? Knowledge comes through this hole. And when we have
the knowledge, we’ll make everyone rich, and we’ll fly to the stars,
and go anywhere
we want. That’s the kind of hole we have here."

-- Roadside Picnic, by Arkady and Boris Strugatsky

[Dvorak Hemialgia]

"Pascal J. Bourguignon" <p...@informatimago.com> writes:

> Assuming you have the current buffer pgm.c,
> you just type M-x compile RET pgm RET
>
> M-x compile RET will present you a minibuffer with "make -k " in it.
> Typing pgm RET will make it run: make -k pgm
> Since you probably don't have a Makefile in the same directory as pgm.c,
> the default rules will be used, so pgm will be built from pgm.c using
> the C compiler.
>
> If your program doesn't take any stdin input, you can even run it at the
> same time: M-x compile RET pgm && ./pgm RET

Wow, Pascal, this is becoming very useful to me as I learn C. Thank you
for sharing. I'll have to read up on how to do this with Java code,
which would have saved me a lot of time over the last couple semesters.

dkh.

[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

[Ken Goldman]

On 6/18/2012 3:25 PM, notbob wrote:
> On 2012-06-18, Pascal J. Bourguignon<p...@informatimago.com> wrote:
>
>> Since you probably don't have a Makefile in the same directory as pgm.c,
>> the default rules will be used, so pgm will be built from pgm.c using
>> the C compiler.
>
> Thanks, Pascal. Since I use Slackware, which has jes about everything
> needed for compiling from source, I'll give it a try. Both make and gcc are in
> the same /usr/bin/ dir.

I think Pascal was saying that you Makefile (not /usr/bin/make) might
not be in the same directory as your code.

If you don't have a makefile there, you can also do 'make -f
pathtomakefile' and emacs will remember it for the next time.

If you don't have a makefile at all, it's time to create one.

Bonus: Check out M-x next-error. I have both compile and next-error
bound to Fn keys since I use them constantly.

[rusi]

On Jun 22, 12:34 am, Ken Goldman <kgold...@us.ibm.com> wrote:
> On 6/18/2012 3:25 PM, notbob wrote:
>
> > On 2012-06-18, Pascal J. Bourguignon<p...@informatimago.com>  wrote:
>
> >> Since you probably don't have a Makefile in the same directory as pgm.c,
> >> the default rules will be used, so pgm will be built from pgm.c using
> >> the C compiler.
>
> > Thanks, Pascal.  Since I use Slackware, which has jes about everything
> > needed for compiling from source, I'll give it a try.  Both make and gcc are in
> > the same /usr/bin/ dir.
>
> I think Pascal was saying that you Makefile (not /usr/bin/make) might
> not be in the same directory as your code.
>
> If you don't have a makefile there, you can also do 'make -f
> pathtomakefile' and emacs will remember it for the next time.

Or simply backspace over the make -k and type gcc for one-off
compilations where a makefile is overkill. If you keep doing that you
can set the emacs variable compile-command but then writing a makefile
is probably a better idea.

[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

[Jeremiah Dodds]

Tom <adatg...@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.

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

[Bastien]

Tom <adatg...@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

[Andreas Röhler]

so what does vim better then Emacs?

[Jeremiah Dodds]

Tom <adatg...@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.

[Andreas Röhler]

Am 22.06.2012 13:17, schrieb Jeremiah Dodds:
> Tom <adatg...@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

[Richard Riley]

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

[Thien-Thi Nguyen]

() Andreas Röhler <andreas...@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...

[Jonathan Groll]

On Fri, 22 Jun 2012 14:21:27 +0200, Richard Riley <ril...@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

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

[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

[Susan Cragin]

I'm a writer with no programming interests, and I love emacs for gathering info, outlining, drafts. But I would like the following:

(1) Printing. Easier to print in the standard author draft form, which is letter-sized paper, 1" margins, double-spaced, TNRoman 12, new page started at each * (highest level outline).

(2) PDF. Files could be "read" and text-searched from within emacs.

(3) at-spi2 integration
I have been involved in a project to port Dragon NaturallySpeaking to Linux using wine. This has been a great help to me in entering text.
Unfortunately, the port that enables dictation straight into Linux apps requires good at-spi2 integration and dbus support, which emacs does not have.
Right now the NatSpeak project is in beta testing, and I can dictate (with bugs) into a number of applications, including Libra Office, G Edit, and Firefox. My e-mail client is web-based and I am dictating right now. As I said, buggy but fun.

This is a sticky subject, I know, since NatSpeak is both closed-source and a Windows program, but shouldn't at-spi2 compatibility be on emacs's radar somewhere?

Thanks, by the way, to Michael Albinus and Mario Lang for the work they did. I would have gotten back to both of them sooner, except that the prototype I was working with suddenly lost major functionality, and I couldn't figure out if Michael's coding worked or not. I am finally able to say that it doesn't work to enter text, but suddenly I can spell into emacs -- one letter at a time.

Susan Cragin

[Andreas Röhler]

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

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

[Jay Belanger]

Tom <adatg...@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?

[Tom]

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

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.

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

[Pascal J. Bourguignon]

rusi <rusto...@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.

[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

[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

[John Bokma]

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

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

[Pascal J. Bourguignon]

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.

[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

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

[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

[suvayu ali]

Hi Teemu,

On Sat, Jun 23, 2012 at 2:05 PM, Teemu Likonen <tlik...@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.

[Eli Zaretskii]

> From: Philipp Haselwarter <phi...@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.

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

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

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

[notbob]

On 2012-06-21, Ken Goldman <kgol...@us.ibm.com> wrote:

> I think Pascal was saying that you Makefile (not /usr/bin/make) might
> not be in the same directory as your code.
>
> If you don't have a makefile there, you can also do 'make -f
> pathtomakefile' and emacs will remember it for the next time.
>
> If you don't have a makefile at all, it's time to create one.
>
> Bonus: Check out M-x next-error. I have both compile and next-error
> bound to Fn keys since I use them constantly.

OK. I'll risk looking stupid one more time. ;)

What, exactly, is this "Makefile"?

nb

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

[Dan Espen]

4. Have a whole bunch of missing functionality.

--
Dan Espen

[Dan Espen]

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

> On 2012-06-21, Ken Goldman <kgol...@us.ibm.com> wrote:
>
>> I think Pascal was saying that you Makefile (not /usr/bin/make) might
>> not be in the same directory as your code.
>>
>> If you don't have a makefile there, you can also do 'make -f
>> pathtomakefile' and emacs will remember it for the next time.
>>
>> If you don't have a makefile at all, it's time to create one.
>>
>> Bonus: Check out M-x next-error. I have both compile and next-error
>> bound to Fn keys since I use them constantly.
>
> OK. I'll risk looking stupid one more time. ;)
>
> What, exactly, is this "Makefile"?

A Makefile is a file using that name (Makefile) that you normally keep
in the same directory as your source code. In that file you keep the
rules it takes to build your source code.

Start here for documentation:

http://www.gnu.org/software/make/manual/

The basic idea is to list your files, show how they inter-relate and are
used to build your project.


A simple example of a Makefile:

SRC:=hello.c
TARG:=$(subst .c,,$(SRC))

all: $(TARG)

%: %.c
cc $< $@

test: $(TARG)
./$(TARG)


Anything starting in column 1 and ending in a ":" is a target.
(Something you want to make.)

Things listed after the colon (":") are things you need to make
the target.

Things following a TAB in column 1 are rules. The rules you need
to make the target.

Makefiles can get a lot more elaborate and can do a lot of things
for you. If you need to compile 3 subroutines for a main before
you link the main, the makefile can ensure that you do that.

Anyway, it's definitely worth the time to learn and a great
productivity booster. It's also not only for building programs.
I use them to upload web pages to a server.

For example:

UP_SITE:=ftpmysite.somewhere.net
uploads:=$(wildcard *.jpg *.html *.gif *.css )
targets:=$(addprefix .upload/,$(uploads))

all: $(targets)

define install_html
(\
echo -e "binary\n"\
"cd deck\n"\
"put $(subst .upload/,,$@)\n"\
"close\n"\
"quit\n"\
) | ftp $(UP_SITE)
endef

.upload/%: %
$(install_html)
echo "`date`" > $@
clean:
rm .upload/*


--
Dan Espen

[Pascal J. Bourguignon]

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.

[ken]

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

[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

[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.
• 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 <rusto...@gmail.com>

[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

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

[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

[notbob]

On 2012-06-24, Corentin Henry <corent...@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]

[notbob]

On 2012-06-24, Andreas Röhler <andreas...@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! ;)

[Deniz Dogan]

On 2012-06-24 14:17,, notbob wrote:
> On 2012-06-24, Andreas Röhler <andreas...@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

[Richard Riley]

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

> On 2012-06-24, Andreas Röhler <andreas...@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.

[Pascal J. Bourguignon]

Indeed.

[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

[notbob]

On 2012-06-24, Deniz Dogan <de...@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.

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

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

[Yuri Khan]

On Sun, Jun 24, 2012 at 8:24 PM, Deniz Dogan <de...@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.

[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

[Rainer M Krug]

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

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

[Eli Zaretskii]

> Date: Sun, 24 Jun 2012 09:55:29 +0200
> From: Andreas Röhler <andreas...@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.

[Eli Zaretskii]

> Date: Sun, 24 Jun 2012 15:01:25 +0800
> From: Corentin Henry <corent...@gmail.com>
> Cc: help-gn...@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).

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

[Eli Zaretskii]

> Date: Sun, 24 Jun 2012 15:24:14 +0200
> From: Deniz Dogan <de...@dogan.se>
> Cc: help-gn...@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?

[Rainer M Krug]

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

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

[Andreas Röhler]

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

[Eli Zaretskii]

> Date: Sun, 24 Jun 2012 19:38:28 +0200

> From: Andreas Röhler <andreas...@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...@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.

[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

[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=frighten...@gnu.org
[mailto:help-gnu-emacs-bounces+ugly=frighten...@gnu.org] On Behalf Of
Bastien
Sent: Friday, June 22, 2012 14:01
To: Drew Adams
Cc: 'rusi'; help-gn...@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

[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

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

[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

[Gregor Zattler]

Hi James,
* James Freer <jesse...@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

[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

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

[James Freer]

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