Tom <adatgyu...@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:
> 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).
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)
rusi <rustompm...@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.
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 [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.
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.
On Sat, Jun 23, 2012 at 2:05 PM, Teemu Likonen <tliko...@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.
> From: Philipp Haselwarter <phil...@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.
>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.
> 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 :-)).
> 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.
Tom <adatgyu...@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.
notbob <not...@nothome.com> writes:
> On 2012-06-21, Ken Goldman <kgold...@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.
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.
Dan Espen <des...@verizon.net> writes:
> Tom <adatgyu...@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.
>>> 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.
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
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.
> 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
> 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.
> 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/
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
On 2012-06-24, Andreas Röhler <andreas.roeh...@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! ;)
> On 2012-06-24, Andreas Röhler <andreas.roeh...@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
