is there summary of template systems for emacs?

is there summary of template systems for emacs?

[Xah Lee]

there seems to be a lot elisp packages for defining templates. Has
anyone studied them and can give a comparison? Basically, i just need
a brief explanation of their syntax and feature.

the emacswiki page
http://www.emacswiki.org/emacs/CategoryTemplates
is very helpful in listing them but a clear summary and comparison is
lacking.

here's what i found so far.

• skeleton.el is probably the oldest. It is officially part of gnu
emacs with full info doc. But its info doc is rather verbose and hard
to read.

• tempo.el is also officially part of gnu emacs. But other than being
included, there seems to be no mentioning of it, and lacks any doc
other than the few paragraphs in source code and chaotic info on
emacswiki.

the above's template syntax are lisp code, so it requires lisp
knowledge to use. There are several more elisp syntax templates:
Tempo, tempoSnippets.

consider how the advancement of technology today (looking at other
IDEs, etc), i think template systems based on lisp syntax is rather
obsolete. There are several plain text based template systems, which i
think are more proper today for emacs going forward:

MsfAbbrev, Snippet, TemplatesMode, ElseMode, YaSnippetMode.

I don't yet know their pro and cons... one wonders why there are so
many. I certainly hope emacs would choose ONE to be bundled as THE
template system for emacs.

With some cursory reading (spent like 3 hours now), it seems YaSnippet
is the most modern and feature rich...

it seems that Snippet is written in 2005 spurred by the Mac OS's
TextMate editor. Then, the author of YaSnippet tried to improve on
that and created SmartSnippet, but further improvement results in
YaSnippet. Looking at YaSnippet site, it seems to have extensive
documentation and examples. (a whole website dedicated to it)

e.g.
http://pluskid.lifegoo.com/upload/project/yasnippet/doc/define_snippet.html

though i'm haven't yet found out how other text based template system
compares.

Is there anyone, or authors of one the above, who actually studied the
whole and can give a summary?

Anyone got more info to add?

I'm interested because recently i'm writing a lsl mode. The lang lsl
has over 600 hundreds functions for scripting in the virtual world
environment Second Life  ... Being a game engine scripting lang, it is
unlike typical programing lang. Its hundreds of functions each has
unusual parameters. So a template set for lsl lang would be very
helpful for my mode.

• Linden Scripting Language with Emacs
  http://xahlee.org/sl/ls-emacs.html

  Xah
∑ http://xahlee.org/

☄

Re: is there summary of template systems for emacs?

[Xah Lee]

2008-12-01

in this page:
http://pluskid.lifegoo.com/?p=6

is a article where the pluskid wrote about why he wrote “smart-
snippet.el” (which is the precursor of yasnippet.el). However, it is
in Chinese. The following is a quick English translation.

------------------------------------------

mart-snippet and smart-skeleton
May 21, 2007 – 8:58 pm

with Ruby on Rail becoming hot, TextMate suddenly also caught the
flame. However, without a Mac, one can't know how TextMate is like.
However, i've seen some video of TextMate the web, and one of the
feature seems very good. That's “snipet”.  Define some template, then
it'll expand at the right time, to reduce repeative typing. This is a
feature any non-trivial editor have. Same template expanding in
multiple places is also a frequently seen feature. But usually the
editor would pop up dialog prompting user to enter proper field. The
surprising aspect of TextMate is that it doesn't do dialog popup, but
let you enter text in the same field, and automatically update all
places of that field.

Updaing fields in multiple places in one shot, this is super cool! All
of a sudden, all major editors are trying to add this feature. Emacs
is no exception, and soon someone wrote “snippet.el”, so that the
TextMate's super cool feature is now in emacs.

“snippet.el” uses emacs's abbrev feature to implement this. Emacs's
abbrev feature is a bit different from other editors, it doesn't need
some keyboard shortcut to invoke (in other words, needing many
shortcuts to expand diff abbrevs). When you turn on abbrev-mode,
abbreviations will auto expand when you type space, punctuation or
return. Abbrev can be major mode specific, so that each major mode can
have different sets of abbrev. However, abbrev has some flaws.

1. because it is based on words, so that it can't define text that's
not just word. For example, you can't use it to define a template to
expand to “()”.

2. Even though each major mode can have its own abbrev, but sometimes
it is not flexible enough. For example, in c++-mode i define a abbrev
to expand “class” to its template. This is very convenient, but i
don't what a bunch of text suddenly appear whenever i type the word
“class”. There are usually 2 ways to solve this: manually, by using “C-
q SPACE” instead of just space. The other way is to change the abbrev,
such as “classx”, so that you type “classx” when you need it to
expand. “msf-abbrev.el” is modeled like this.

however, in reality, both methods are not that great, because emacs's
abreev is not context sensitive.

thus i wrote “smart-snippet.el” based on “snippet.el”. It makes the
feature more flexible, like the name, it's smarter. It will expand or
not expand abbrev depending on the surrounding text. Very convenient.

I use “snippet.el”'s engine for expansion, and i modified it ab it.
“snippet.el”'s template syntax is very simple:


• “$${field}”  defines a field. Same named field in source code will
all get updated. Use Tab and Shift Tab to move between fields.

• “$” is for final the cursor location placement.

• “$>” means indendation. Emacs typicall has very nice indentation
setup for each major mode.

And these symbols can be changed. If they conflict with some
language's syntax and making emacs swoon, you can change other symbol
so that it is less confusing. You can set a different symbol for
different major mode. For example, i have have the following def for
“if”:

if ($${cond})
{$>
$>$.
}$>

but in other case, for example inside a string or comment. And there
are some other lang such as perl, ruby, etc, the same keyword can have
different construct. For example, in ruby, “if” can be used like
these:

# one way
if cond
  do_something
end

# another way
do_something if cond

the “smartness” in “smart-snippet.el” can be demonstrated right here!

i put a video tutorial of this in the main page, showing the features
of “smart-snippetl.el”.

...

------------------------------

Sorry i got tired translating at this point. The rest half is a bit
detail about other feature, such as how a “(” can expand to “()” with
the cursor inside, and how to get the cursor outside.

The last sentence in the article goes: “after all, editor design is
deep! Letting programer code comfortably is no doubt a very important
topic.”. Wee!

 It is a very good read. Anyhowe, smart snippet is now superceded by
yasnippet, and yasnippet has huge documentation in english and forum.
So, enjoy.

  Xah
∑ http://xahlee.org/

☄

RE: is there summary of template systems for emacs?

[Drew Adams]

> there seems to be a lot elisp packages for defining templates. Has
> anyone studied them and can give a comparison? Basically, i just need
> a brief explanation of their syntax and feature.
> 
> the emacswiki page
> http://www.emacswiki.org/emacs/CategoryTemplates
> is very helpful in listing them but a clear summary and comparison is
> lacking. here's what i found so far....

Good idea. Please update the wiki with a summary of the info you found and
whatever else comes out of this thread that might be helpful. The next person
who looks where you did will then find that missing help. ;-)

Re: is there summary of template systems for emacs?

[Peter Milliken]

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

Hi Xah,

I'd be interested in your opinion of ELSE. I haven't tried some of the
others that you mention - ELSE suits me fine. I have tried tempo and
skeleton etc but were turned off by the "intrusive" and horribly awkward
interfaces that they presented to the user. I had been exposed to DEC's LSE
in the past (circa 1985), and found that it didn't "get in my face" or cause
awkward usage problems, so I decided to "port" their language sensitive
editor functionality to Emacs (hence E(macs)LSE :-)).

But facilities such as ELSE, tempo, skeleton etc are obviously not very
popular (which I have never been able to understand!) i.e. I have shown many
fellow programmers ELSE over the years and not a single one of them has ever
taken up it's use. In fact, through all the time ELSE has been available on
the Internet, I have only ever received less than 10 queries/expressions of
interest in it - which may argue that it just doesn't hit the mark! :-) But
given the alternatives that were available (especially in the "early days")
I don't think that was the case. Of course, these days, it is even less
likely because Emacs just isn't that popular as an editor i.e. there are
probably 30 - 40 programmers at my current place of employ and there is only
one other programmer here that uses Emacs - so the opportunities for
creating "converts" are not good at all!

ELSE does not use (e)lisp like syntax. It has it's own template file for
generating new templates. It has (what I believe is) extensive documentation
- something that has always annoyed me about many Emacs packages (such as
tempo and skeleton) - when they were first available it was very much "read
the code and examples" - I believe that has changed for skeleton but I had
long since lost interest by the time somebody rectified that!

So I would echo Drew's call - by all means do a comparison and share the
results if you can with us all.

Peter

On Wed, Dec 3, 2008 at 11:34 AM, Drew Adams <drew.adams@oracle.com> wrote:

> > there seems to be a lot elisp packages for defining templates. Has
> > anyone studied them and can give a comparison? Basically, i just need
> > a brief explanation of their syntax and feature.
> >
> > the emacswiki page
> > http://www.emacswiki.org/emacs/CategoryTemplates
> > is very helpful in listing them but a clear summary and comparison is
> > lacking. here's what i found so far....
>
> Good idea. Please update the wiki with a summary of the info you found and
> whatever else comes out of this thread that might be helpful. The next
> person
> who looks where you did will then find that missing help. ;-)
>
>
>
>
>

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

Re: is there summary of template systems for emacs?

[Xah Lee]

2008-12-14

On Dec 7, 11:14 am, "Peter Milliken" <peter.milli...@gmail.com> wrote:
> Hi Xah,
>
> I'd be interested in your opinion of ELSE. I haven't tried some of the
> others that you mention - ELSE suits me fine. I have tried tempo and
> skeleton etc but were turned off by the "intrusive" and horribly awkward
> interfaces that they presented to the user. I had been exposed to DEC's LSE
> in the past (circa 1985), and found that it didn't "get in my face" or cause
> awkward usage problems, so I decided to "port" their language sensitive
> editor functionality to Emacs (hence E(macs)LSE :-)).
>
> But facilities such as ELSE, tempo, skeleton etc are obviously not very
> popular (which I have never been able to understand!) i.e. I have shown many
> fellow programmers ELSE over the years and not a single one of them has ever
> taken up it's use. In fact, through all the time ELSE has been available on
> the Internet, I have only ever received less than 10 queries/expressions of
> interest in it - which may argue that it just doesn't hit the mark! :-) But
> given the alternatives that were available (especially in the "early days")
> I don't think that was the case. Of course, these days, it is even less
> likely because Emacs just isn't that popular as an editor i.e. there are
> probably 30 - 40 programmers at my current place of employ and there is only
> one other programmer here that uses Emacs - so the opportunities for
> creating "converts" are not good at all!
>
> ELSE does not use (e)lisp like syntax. It has it's own template file for
> generating new templates. It has (what I believe is) extensive documentation
> - something that has always annoyed me about many Emacs packages (such as
> tempo and skeleton) - when they were first available it was very much "read
> the code and examples" - I believe that has changed for skeleton but I had
> long since lost interest by the time somebody rectified that!
>
> So I would echo Drew's call - by all means do a comparison and share the
> results if you can with us all.
>
> Peter
>
> On Wed, Dec 3, 2008 at 11:34 AM, Drew Adams <drew.ad...@oracle.com> wrote:
> > > there seems to be a lot elisp packages for defining templates. Has
> > > anyone studied them and can give a comparison? Basically, i just need
> > > a brief explanation of their syntax and feature.
>
> > > the emacswiki page
> > >http://www.emacswiki.org/emacs/CategoryTemplates
> > > is very helpful in listing them but a clear summary and comparison is
> > > lacking. here's what i found so far....
>
> > Good idea. Please update the wiki with a summary of the info you found and
> > whatever else comes out of this thread that might be helpful. The next
> > person
> > who looks where you did will then find that missing help. ;-)

Hi Peter,

Sorry i missed your post. (i use google groups and sometimes i miss
posts. (regular newsgroup client won't help much in this regard))

Anyway, i've followed Drew's advice and cleaned up the emacswiki a bit
based on what i've studied.

http://www.emacswiki.org/emacs/CategoryTemplates

though, i haven't looked into ELSE. Right now i pretty much settled on
yasnippet.

I really feel sorry emacs's user base is dying. The most important
thing i think is to get emacs to use modern terminologies and be
compatible with the minimum of standard modern UI. On the Mac, emacs
modernization is a huge success with Aquamacs Emacs, which is emacs
with pretty much complete Mac OS X UI. On Windows, there's EmacsW32 by
Lennart Borgman, but i think it primarily just changes emacs the Alt
key to conform to Window's Alt=Menu behavior and the core philosophy
of EmacsW32 is a emacs add-on improvement, as opposed to a whole,
complete, “download and use it” software. If Lennart would change his
philosophy and marketing a bit, i think it'd complete revolutionize
emacs overnight, together with Aquamacs, solves the emacs
modernization problem like XEmacs did 18 years ago.

In this year since June, i've filed 40 bug reports to bug-gnu-emacs.
( http://groups.google.com/group/gnu.emacs.bug/search?q=xah&start=0&scoring=d&
)
About maybe 20 has been fixed. About maybe only 5 of my all reports
are suggestions. (these are really conservative ones, most of these
suggestions are suggested by other developers's encouragement for
sending it to bug-gnu-emacs, as opposed to my owe ideas of critical
modernization issues) Roughly, anything that's not bugs are either
receives no reply, or marked as not bug with a explanation (e.g. emacs
does it THIS way), or piled to “wish list”.

  Xah
∑ http://xahlee.org/

☄

Distributed Maintenance for Emacs (was: is there summary of template systems for emacs?)

[Leo]

On 2008-12-14 21:37 +0000, Xah Lee wrote:
> I really feel sorry emacs's user base is dying. The most important
> thing i think is to get emacs to use modern terminologies and be
> compatible with the minimum of standard modern UI.

Users are not scared off by Emacs's UI. It is more important its
functionality.

And in order to boost its functionality a few orders more and better, it
needs a good development model, a model that supports *DISTRIBUTED*
maintenance.

A huge system like Emacs can not simply and effectively maintained by a
handful of maintainers.

Currently there are many successful models to follow, here are a few
examples:
R with CRAN,
Perl with CPAN,
TeX with CTAN,
Python with PYPI (http://pypi.python.org/pypi)
......

particularly R, it has a high-profile core team that maintains and
develops the core of the system while it has thousands of maintainers
for its 1628+ packages. I recommend you to have a peek at them at
http://www.stats.bris.ac.uk/R/web/packages/.

This way R has a high-quality core that is suitable for INDUSTRIAL and
serious work and it has thousands of high-quality packages maintained by
their authors, ready for bug reports and feature requests. This is key
to user satisfaction.

RMS's thinking is, the number one reason that users come to free
software is because it is free. However, free software is free only if
your time is worthless, someone once said. I just spent 10 minutes on
this post for the better or worse of Emacs.

To sum up, I think you have not caught the key problem in Emacs.

Bye,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

Re: Distributed Maintenance for Emacs

[Paul R]

Both the *default settings* for emacs UI and the lack of ready-to-use
packages are problems for wider emacs adoption.

The first one could be easily adressed by convincing the core team of
the need.

The second one mainly needs an officially supported package management
system built into emacs, and packages in it would have to be as
orthogonal as possible in terms of functionnality, so that it is clear
to the user that he needs package X to achieve task Y.

EmacsWiki already is a kind of informal emacs CPAN, without the
packaging.

-- 
  Paul

Re: is there summary of template systems for emacs?

[Peter Milliken]

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

Hi Xah,

Well, I use gmail to manage all of the mailing lists I am on - makes it much
easier to keep track of things as it keeps track of the threads and
everything for me :-)

I might have a look YaSnippet and possibly make comments on the Emacs Wiki
page as to how it compares - something which is sometimes not easy because
many packages have strengths and weakness, so drawing comparisons is not
always straight forward! :-)

I have done some experimentation with generating "autocompletion" with ELSE
templates in the past (autocompletion in the sense of the user trying to
complete a function call) - this was done with Python. From memory it went
quite well, but I never polished it off and took it to completion - probably
because of the general lack of desire in people to have autocompletion or
template systems in general i.e. why put in work when nobody will use it?
:-)

Anyway, all the best with your efforts, I see a lot of emails from you on
the mailing list, so you are obviously putting a lot of effort into using
Emacs and trying to make it better! So thanks for that :-)

Pete

On Mon, Dec 15, 2008 at 8:37 AM, Xah Lee <xahlee@gmail.com> wrote:

> 2008-12-14
>
> On Dec 7, 11:14 am, "Peter Milliken" <peter.milli...@gmail.com> wrote:
> > Hi Xah,
> >
> > I'd be interested in your opinion of ELSE. I haven't tried some of the
> > others that you mention - ELSE suits me fine. I have tried tempo and
> > skeleton etc but were turned off by the "intrusive" and horribly awkward
> > interfaces that they presented to the user. I had been exposed to DEC's
> LSE
> > in the past (circa 1985), and found that it didn't "get in my face" or
> cause
> > awkward usage problems, so I decided to "port" their language sensitive
> > editor functionality to Emacs (hence E(macs)LSE :-)).
> >
> > But facilities such as ELSE, tempo, skeleton etc are obviously not very
> > popular (which I have never been able to understand!) i.e. I have shown
> many
> > fellow programmers ELSE over the years and not a single one of them has
> ever
> > taken up it's use. In fact, through all the time ELSE has been available
> on
> > the Internet, I have only ever received less than 10 queries/expressions
> of
> > interest in it - which may argue that it just doesn't hit the mark! :-)
> But
> > given the alternatives that were available (especially in the "early
> days")
> > I don't think that was the case. Of course, these days, it is even less
> > likely because Emacs just isn't that popular as an editor i.e. there are
> > probably 30 - 40 programmers at my current place of employ and there is
> only
> > one other programmer here that uses Emacs - so the opportunities for
> > creating "converts" are not good at all!
> >
> > ELSE does not use (e)lisp like syntax. It has it's own template file for
> > generating new templates. It has (what I believe is) extensive
> documentation
> > - something that has always annoyed me about many Emacs packages (such as
> > tempo and skeleton) - when they were first available it was very much
> "read
> > the code and examples" - I believe that has changed for skeleton but I
> had
> > long since lost interest by the time somebody rectified that!
> >
> > So I would echo Drew's call - by all means do a comparison and share the
> > results if you can with us all.
> >
> > Peter
> >
> > On Wed, Dec 3, 2008 at 11:34 AM, Drew Adams <drew.ad...@oracle.com>
> wrote:
> > > > there seems to be a lot elisp packages for defining templates. Has
> > > > anyone studied them and can give a comparison? Basically, i just need
> > > > a brief explanation of their syntax and feature.
> >
> > > > the emacswiki page
> > > >http://www.emacswiki.org/emacs/CategoryTemplates
> > > > is very helpful in listing them but a clear summary and comparison is
> > > > lacking. here's what i found so far....
> >
> > > Good idea. Please update the wiki with a summary of the info you found
> and
> > > whatever else comes out of this thread that might be helpful. The next
> > > person
> > > who looks where you did will then find that missing help. ;-)
>
> Hi Peter,
>
> Sorry i missed your post. (i use google groups and sometimes i miss
> posts. (regular newsgroup client won't help much in this regard))
>
> Anyway, i've followed Drew's advice and cleaned up the emacswiki a bit
> based on what i've studied.
>
> http://www.emacswiki.org/emacs/CategoryTemplates
>
> though, i haven't looked into ELSE. Right now i pretty much settled on
> yasnippet.
>
> I really feel sorry emacs's user base is dying. The most important
> thing i think is to get emacs to use modern terminologies and be
> compatible with the minimum of standard modern UI. On the Mac, emacs
> modernization is a huge success with Aquamacs Emacs, which is emacs
> with pretty much complete Mac OS X UI. On Windows, there's EmacsW32 by
> Lennart Borgman, but i think it primarily just changes emacs the Alt
> key to conform to Window's Alt=Menu behavior and the core philosophy
> of EmacsW32 is a emacs add-on improvement, as opposed to a whole,
> complete, "download and use it" software. If Lennart would change his
> philosophy and marketing a bit, i think it'd complete revolutionize
> emacs overnight, together with Aquamacs, solves the emacs
> modernization problem like XEmacs did 18 years ago.
>
> In this year since June, i've filed 40 bug reports to bug-gnu-emacs.
> (
> http://groups.google.com/group/gnu.emacs.bug/search?q=xah&start=0&scoring=d&
> )
> About maybe 20 has been fixed. About maybe only 5 of my all reports
> are suggestions. (these are really conservative ones, most of these
> suggestions are suggested by other developers's encouragement for
> sending it to bug-gnu-emacs, as opposed to my owe ideas of critical
> modernization issues) Roughly, anything that's not bugs are either
> receives no reply, or marked as not bug with a explanation (e.g. emacs
> does it THIS way), or piled to "wish list".
>
>  Xah
> ∑ http://xahlee.org/
>
> ☄
>
>

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

Re: is there summary of template systems for emacs?

[Peter Milliken]

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

Well, I wasn't going to do this (project deadlines you know? Hope my project
manager doesn't monitor this list !:-)) but I couldn't resist...

Just had a quick look at the YaSnippet video on YouTube and the
documentation - without a detailed analysis I didn't see YaSnippet do
anything that ELSE doesn't do. It certainly prompted me to think - "what is
the history of YaSnippet? Did they look at ELSE before they put in this
work?" :-)

The documentation doesn't look that extensive (again, I just browsed it, so
I may well be doing it an injustice - or perhaps ELSE's documentation is too
"verbose"? I do tend to write so a 14 year old could understand - and some
people don't appreciate that! :-)). For example, "transformations" was an
interesting section (personally not sure I would bother with it though :-)),
but I was left wondering - "what are the list of available transformations?"
i.e. capitalize was mentioned in the example - are there more? If so, where
are they documented?

I didn't see any facility in YaSnippet for "cascading" templates at all i.e.
ELSE allows "expansion" of templates that lead to lower (and more detailed)
template structures. A crude example would be when you first invoke
else-mode in a new (and empty) file, it will automatically insert the
initial placeholder e.g.

{compilation_unit}

which, when expanded (C language template used as an example) to:

[module_level_comments]
[{include_files}...]

[{data_types_or_declarations}...]

[{function_definition}...]

[main_function]

Each item enclosed in {}'s or []'s are "placeholders" that can be easily
navigated to and expanded or deleted as required. Most of the placeholders
above lead to more detailed templates when expanded.

YaSnippet implements what are defined as "tokens" in ELSE - there is no
equivalent to the ELSE "placeholder", so there is no auto-repeating feature
in YaSnippet e.g. the ELSE (C language) template for the switch statement
looks like this (this is my "customised" version - not from the release
files):

switch ({expression})
{
    case {constant_expression}:
    [case {constant_expression}:]...
        [statement]...
        break;
    [case_part]...
    default :
        [statement]...
        break;
}

Note that the first "case" portion has an optional case placeholder below it
- the ellipses (...) after the closing ']' indicate that if the user chooses
to expand this then it will be "repeated" automatically by ELSE on either
the next line or the same line (ELSE allows either or tries to determine
from context) i.e. after an expansion of the second case placeholder, you
have:

switch (type_of_fruit)
{
    case ORANGE:
    case APPLE:
    [case {constant_expression}:]...
        [statement]...
        break;
    [case_part]...
    default :
        [statement]...
        break;
}

When the user decides that a placeholder (text enclosed by either {}'s or
[]'s) is nolonger required/desired then the placeholder can be deleted with
a single command/keystroke.

I presume that new "snippets" are easily defined - ELSE allows the user to
modify a definition "on the fly" by allowing the extraction of the
definition in the current buffer and then re-compilation for that session.
If the change looks like being "permanent", then the changed definition can
be saved in the users language customisation template file - which brings to
mind something that YaSnippet doesn't do - cater for multiple users with
common project coding standards. ELSE allows for loading two template files
per major mode - firstly a <lang>.lse file (which would come from a common
project directory) and then a <lang>-cust.lse file which could come from the
users local directory - the user places their own pet template definitions
in the later file (which don't violate the project coding standards! :-)).
The later template file can "override"/replace any definitions from the
primary template file.

Don't get me wrong though - I do like the look of YaSnippet. It has a very
concise definition syntax by the look of it and it is more straightforward
in allowing the definition of "mirrors" than ELSE (ELSE allows/implements
"mirrors" but the mirror definition is usually removed one level from where
it is used). It has a nice "look and feel" to it - it is not intrusive like
skeleton et el.

So I believe that ELSE does "more" - whether your typical user would
consider the "more" to be worth while or not, is entirely problematical! :-)

Pete


On Tue, Dec 16, 2008 at 5:48 AM, Peter Milliken <peter.milliken@gmail.com>wrote:

> Hi Xah,
>
> Well, I use gmail to manage all of the mailing lists I am on - makes it
> much easier to keep track of things as it keeps track of the threads and
> everything for me :-)
>
> I might have a look YaSnippet and possibly make comments on the Emacs Wiki
> page as to how it compares - something which is sometimes not easy because
> many packages have strengths and weakness, so drawing comparisons is not
> always straight forward! :-)
>
> I have done some experimentation with generating "autocompletion" with ELSE
> templates in the past (autocompletion in the sense of the user trying to
> complete a function call) - this was done with Python. From memory it went
> quite well, but I never polished it off and took it to completion - probably
> because of the general lack of desire in people to have autocompletion or
> template systems in general i.e. why put in work when nobody will use it?
> :-)
>
> Anyway, all the best with your efforts, I see a lot of emails from you on
> the mailing list, so you are obviously putting a lot of effort into using
> Emacs and trying to make it better! So thanks for that :-)
>
> Pete
>
>
> On Mon, Dec 15, 2008 at 8:37 AM, Xah Lee <xahlee@gmail.com> wrote:
>
>> 2008-12-14
>>
>> On Dec 7, 11:14 am, "Peter Milliken" <peter.milli...@gmail.com> wrote:
>> > Hi Xah,
>> >
>> > I'd be interested in your opinion of ELSE. I haven't tried some of the
>> > others that you mention - ELSE suits me fine. I have tried tempo and
>> > skeleton etc but were turned off by the "intrusive" and horribly awkward
>> > interfaces that they presented to the user. I had been exposed to DEC's
>> LSE
>> > in the past (circa 1985), and found that it didn't "get in my face" or
>> cause
>> > awkward usage problems, so I decided to "port" their language sensitive
>> > editor functionality to Emacs (hence E(macs)LSE :-)).
>> >
>> > But facilities such as ELSE, tempo, skeleton etc are obviously not very
>> > popular (which I have never been able to understand!) i.e. I have shown
>> many
>> > fellow programmers ELSE over the years and not a single one of them has
>> ever
>> > taken up it's use. In fact, through all the time ELSE has been available
>> on
>> > the Internet, I have only ever received less than 10 queries/expressions
>> of
>> > interest in it - which may argue that it just doesn't hit the mark! :-)
>> But
>> > given the alternatives that were available (especially in the "early
>> days")
>> > I don't think that was the case. Of course, these days, it is even less
>> > likely because Emacs just isn't that popular as an editor i.e. there are
>> > probably 30 - 40 programmers at my current place of employ and there is
>> only
>> > one other programmer here that uses Emacs - so the opportunities for
>> > creating "converts" are not good at all!
>> >
>> > ELSE does not use (e)lisp like syntax. It has it's own template file for
>> > generating new templates. It has (what I believe is) extensive
>> documentation
>> > - something that has always annoyed me about many Emacs packages (such
>> as
>> > tempo and skeleton) - when they were first available it was very much
>> "read
>> > the code and examples" - I believe that has changed for skeleton but I
>> had
>> > long since lost interest by the time somebody rectified that!
>> >
>> > So I would echo Drew's call - by all means do a comparison and share the
>> > results if you can with us all.
>> >
>> > Peter
>> >
>> > On Wed, Dec 3, 2008 at 11:34 AM, Drew Adams <drew.ad...@oracle.com>
>> wrote:
>> > > > there seems to be a lot elisp packages for defining templates. Has
>> > > > anyone studied them and can give a comparison? Basically, i just
>> need
>> > > > a brief explanation of their syntax and feature.
>> >
>> > > > the emacswiki page
>> > > >http://www.emacswiki.org/emacs/CategoryTemplates
>> > > > is very helpful in listing them but a clear summary and comparison
>> is
>> > > > lacking. here's what i found so far....
>> >
>> > > Good idea. Please update the wiki with a summary of the info you found
>> and
>> > > whatever else comes out of this thread that might be helpful. The next
>> > > person
>> > > who looks where you did will then find that missing help. ;-)
>>
>> Hi Peter,
>>
>> Sorry i missed your post. (i use google groups and sometimes i miss
>> posts. (regular newsgroup client won't help much in this regard))
>>
>> Anyway, i've followed Drew's advice and cleaned up the emacswiki a bit
>> based on what i've studied.
>>
>> http://www.emacswiki.org/emacs/CategoryTemplates
>>
>> though, i haven't looked into ELSE. Right now i pretty much settled on
>> yasnippet.
>>
>> I really feel sorry emacs's user base is dying. The most important
>> thing i think is to get emacs to use modern terminologies and be
>> compatible with the minimum of standard modern UI. On the Mac, emacs
>> modernization is a huge success with Aquamacs Emacs, which is emacs
>> with pretty much complete Mac OS X UI. On Windows, there's EmacsW32 by
>> Lennart Borgman, but i think it primarily just changes emacs the Alt
>> key to conform to Window's Alt=Menu behavior and the core philosophy
>> of EmacsW32 is a emacs add-on improvement, as opposed to a whole,
>> complete, "download and use it" software. If Lennart would change his
>> philosophy and marketing a bit, i think it'd complete revolutionize
>> emacs overnight, together with Aquamacs, solves the emacs
>> modernization problem like XEmacs did 18 years ago.
>>
>> In this year since June, i've filed 40 bug reports to bug-gnu-emacs.
>> (
>> http://groups.google.com/group/gnu.emacs.bug/search?q=xah&start=0&scoring=d&
>> )
>> About maybe 20 has been fixed. About maybe only 5 of my all reports
>> are suggestions. (these are really conservative ones, most of these
>> suggestions are suggested by other developers's encouragement for
>> sending it to bug-gnu-emacs, as opposed to my owe ideas of critical
>> modernization issues) Roughly, anything that's not bugs are either
>> receives no reply, or marked as not bug with a explanation (e.g. emacs
>> does it THIS way), or piled to "wish list".
>>
>>  Xah
>> ∑ http://xahlee.org/
>>
>> ☄
>>
>>
>

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

Emacs's popularity (was: Distributed Maintenance for Emacs)

[Teemu Likonen]

Leo (2008-12-15 18:24 +0000) wrote:

> On 2008-12-14 21:37 +0000, Xah Lee wrote:
>> I really feel sorry emacs's user base is dying. The most important
>> thing i think is to get emacs to use modern terminologies and be
>> compatible with the minimum of standard modern UI.
>
> Users are not scared off by Emacs's UI. It is more important its
> functionality.

Are people being scared off in the first place? I mean more than
normally. :-)

I don't know but at least among Debian GNU/Linux users Emacs's
popularity doesn't seem to have decreased. Here's a Debian popularity
contest[1] graph that shows the popularity of packages emacs21,
emacs21-nox, emacs22, emacs22-nox and emacs22-gtk:

    http://preview.tinyurl.com/55stry [2]

The graph shows that Emacs22 started gaining popularity around mid-2007
(the release) and Emacs21 started losing it. Those summed together Emacs
is no less popular than before. The latest official Debian release (4.0
"Etch") includes Emacs21.

This popularity measurement category is called "vote". It means that
user has accessed (atime) the files in the package within 30 days. It
roughly means that the software is actually being used, not only
installed.


---------------
[1] http://popcon.debian.org/

[2] http://qa.debian.org/popcon-graph.php?packages=emacs21%2Cemacs21-nox%2Cemacs22%2Cemacs22-gtk%2Cemacs22-nox&show_vote=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Peter Milliken]

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

It is difficult to tell if the emacs user base is "dying" - all I can do is
comment from experience. I have been a programmer for 25+ years now. In the
"early" days, Emacs and Vi were two of the main contenders - because Unix
was one of the most popular OS's (I used VAX's for a while - but neither was
available there). When IBM/Microsoft put PC's on everybodies desks, the
proliferation of "other" editors started to explode.

In my working experience, once PC's hit the desktop, Emacs or Vi were NEVER
the popular editor. So for at least the last 20+ years, I have been
virtually the only user in the organisation that I was currently working for
at the time using Emacs (or an Emacs look-alike - in the early days of PC's,
before DJ Delorie came along, you used things like "micro Emacs" if you were
an Emacs junkie). My current organisation has about 30 - 40 programmers
across a number of small projects - there are only two of us using Emacs :-)


So whether you can define Emacs as dying out - or just holding it's own is a
matter of perspective :-) Certainly you are likely to find a much higher
user base with OS's such as Debian's distribution of Linux - but I haven't
ever worked for an organisation that put machines running Linux on our desks
- managers like to play safe by spending lots of money with Microsoft and
getting the lowest common denominator on everybodies desk...

Pete

On Tue, Dec 16, 2008 at 6:31 AM, Teemu Likonen <tlikonen@iki.fi> wrote:

> Leo (2008-12-15 18:24 +0000) wrote:
>
> > On 2008-12-14 21:37 +0000, Xah Lee wrote:
> >> I really feel sorry emacs's user base is dying. The most important
> >> thing i think is to get emacs to use modern terminologies and be
> >> compatible with the minimum of standard modern UI.
> >
> > Users are not scared off by Emacs's UI. It is more important its
> > functionality.
>
> Are people being scared off in the first place? I mean more than
> normally. :-)
>
> I don't know but at least among Debian GNU/Linux users Emacs's
> popularity doesn't seem to have decreased. Here's a Debian popularity
> contest[1] graph that shows the popularity of packages emacs21,
> emacs21-nox, emacs22, emacs22-nox and emacs22-gtk:
>
>    http://preview.tinyurl.com/55stry [2]
>
> The graph shows that Emacs22 started gaining popularity around mid-2007
> (the release) and Emacs21 started losing it. Those summed together Emacs
> is no less popular than before. The latest official Debian release (4.0
> "Etch") includes Emacs21.
>
> This popularity measurement category is called "vote". It means that
> user has accessed (atime) the files in the package within 30 days. It
> roughly means that the software is actually being used, not only
> installed.
>
>
> ---------------
> [1] http://popcon.debian.org/
>
> [2]
> http://qa.debian.org/popcon-graph.php?packages=emacs21%2Cemacs21-nox%2Cemacs22%2Cemacs22-gtk%2Cemacs22-nox&show_vote=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>

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

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Jonathan Groll]

On Mon, Dec 15, 2008 at 07:31:21PM +0000, Teemu Likonen wrote:
>I don't know but at least among Debian GNU/Linux users Emacs's
>popularity doesn't seem to have decreased. Here's a Debian popularity
>contest[1] graph that shows the popularity of packages emacs21,
>emacs21-nox, emacs22, emacs22-nox and emacs22-gtk:
>
>    http://preview.tinyurl.com/55stry [2]
>

Sadly, vim outvotes all flavours of GNU emacs on the above graph when
added to it (although to be fair, on Debian emacs is not installed by
default but some flavour of vi is).

Cheers,
Jonathan

Re: Emacs's popularity

[Teemu Likonen]

Jonathan Groll (2008-12-15 23:09 +0200) wrote:

> Sadly, vim outvotes all flavours of GNU emacs on the above graph when
> added to it (although to be fair, on Debian emacs is not installed by
> default but some flavour of vi is).

Yes, nowadays Vim is in every Debian installation (priority "important"
for vim-tiny). The popularity graph by installs (percent) shows that
vim-common is basically in everyone's system:

    http://preview.tinyurl.com/6g934p

But Vim is not only installed; it's really used a lot. In Debian Vim has
always been a bit more popular than Emacs but in the first half of 2007
Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
"used actively" graph compares vim-common, emacs21-bin-common and
emacs22-bin-common packages:

    http://preview.tinyurl.com/5thmmx

Re: Emacs's popularity

[Lennart Borgman]

On Mon, Dec 15, 2008 at 10:37 PM, Teemu Likonen <tlikonen@iki.fi> wrote:
> But Vim is not only installed; it's really used a lot. In Debian Vim has
> always been a bit more popular than Emacs but in the first half of 2007
> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
> "used actively" graph compares vim-common, emacs21-bin-common and
> emacs22-bin-common packages:
>
>    http://preview.tinyurl.com/5thmmx

That is a bit strange since the vi emulator Viper in Emacs is now so good.

Re: Emacs's popularity

[Richard Riley]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

> On Mon, Dec 15, 2008 at 10:37 PM, Teemu Likonen <tlikonen@iki.fi> wrote:
>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>> always been a bit more popular than Emacs but in the first half of 2007
>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>> "used actively" graph compares vim-common, emacs21-bin-common and
>> emacs22-bin-common packages:
>>
>>    http://preview.tinyurl.com/5thmmx
>
> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>

Not strange at all Lennart, Why would someone run the Emacs OS to run
emulated vim  when they can run the real thing in 100th of the
footprint?

The big problem is simply that Emacs is far less approachable than
Vim. No matter what people say, I know from personal experience that
people balk at the Tutorial which still emphasises center keys as
opposed to arrows keys. It might appear minor to the seasoned emacs user
but its not to the average new adopter who is used to standard Windows
type CUA editors. I consider myself a pretty decent Emacs user now and I
use the arrow keys ... 

In addition, and importantly, the type which stick with Emacs and know
how it works are far less likely to by flag waving fan boys - something
Vi/m has always had an abundance of....


-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: Emacs's popularity

[Lennart Borgman]

On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:

>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>> always been a bit more popular than Emacs but in the first half of 2007
>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>> emacs22-bin-common packages:
>>>
>>>    http://preview.tinyurl.com/5thmmx
>>
>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>
>
> Not strange at all Lennart, Why would someone run the Emacs OS to run
> emulated vim  when they can run the real thing in 100th of the
> footprint?

Exactly why do you think the footprint matter?

> The big problem is simply that Emacs is far less approachable than
> Vim. No matter what people say, I know from personal experience that
> people balk at the Tutorial which still emphasises center keys as
> opposed to arrows keys. It might appear minor to the seasoned emacs user
> but its not to the average new adopter who is used to standard Windows
> type CUA editors. I consider myself a pretty decent Emacs user now and I
> use the arrow keys ...
>
> In addition, and importantly, the type which stick with Emacs and know
> how it works are far less likely to by flag waving fan boys - something
> Vi/m has always had an abundance of....
>
>
> --
>  important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970
>

Re: Emacs's popularity

[Richard Riley]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

> On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>
>>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>>> always been a bit more popular than Emacs but in the first half of 2007
>>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>>> emacs22-bin-common packages:
>>>>
>>>>    http://preview.tinyurl.com/5thmmx
>>>
>>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>>
>>
>> Not strange at all Lennart, Why would someone run the Emacs OS to run
>> emulated vim  when they can run the real thing in 100th of the
>> footprint?
>
> Exactly why do you think the footprint matter?

Are you serious?

Memory usage, start speed, response, and all thinks linked.

And with the boom in netbooks and OSen on USB sticks, emacs finds itself
more and more pushed into that "heavy dinosaur" category. I'm not saying
I *agree* with it, just those are my observations.

Personally I detest Vi and clones.

Re: Emacs's popularity

[Lennart Borgman]

On Tue, Dec 16, 2008 at 12:40 AM, Richard Riley <rileyrgdev@gmail.com> wrote:
> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>
>> On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>>
>>>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>>>> always been a bit more popular than Emacs but in the first half of 2007
>>>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>>>> emacs22-bin-common packages:
>>>>>
>>>>>    http://preview.tinyurl.com/5thmmx
>>>>
>>>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>>>
>>>
>>> Not strange at all Lennart, Why would someone run the Emacs OS to run
>>> emulated vim  when they can run the real thing in 100th of the
>>> footprint?
>>
>> Exactly why do you think the footprint matter?
>
> Are you serious?

Well, yes. I did not even mention that you greatly exaggerated the
footprint differences.

> Memory usage, start speed, response, and all thinks linked.

I actually do not think those are the problem. A barebone Emacs starts
up very fast.

But start up time may still be a trouble when doing small editing. Of
course if you know about Emacs client/server that is not a problem in
most cases (though someone gave an example with su that would not work
in this case).

> And with the boom in netbooks and OSen on USB sticks, emacs finds itself
> more and more pushed into that "heavy dinosaur" category. I'm not saying
> I *agree* with it, just those are my observations.

I checked my Emacs+EmacsW32 directory tree. It is about 160 MB. I am
planning to buy a netbook with about 160 GB disk. And hopefully 2 GB
memory.

> Personally I detest Vi and clones.
>

Re: Emacs's popularity

[Richard Riley]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

> On Tue, Dec 16, 2008 at 12:40 AM, Richard Riley <rileyrgdev@gmail.com> wrote:
>> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>>
>>> On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>>>
>>>>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>>>>> always been a bit more popular than Emacs but in the first half of 2007
>>>>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>>>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>>>>> emacs22-bin-common packages:
>>>>>>
>>>>>>    http://preview.tinyurl.com/5thmmx
>>>>>
>>>>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>>>>
>>>>
>>>> Not strange at all Lennart, Why would someone run the Emacs OS to run
>>>> emulated vim  when they can run the real thing in 100th of the
>>>> footprint?
>>>
>>> Exactly why do you think the footprint matter?
>>
>> Are you serious?
>
> Well, yes. I did not even mention that you greatly exaggerated the
> footprint differences.

Perception and reality are two different things. People assume Emacs is heavy.

>
>> Memory usage, start speed, response, and all thinks linked.
>
> I actually do not think those are the problem. A barebone Emacs starts
> up very fast.

It does. And if you use emacs -daemon and emacsclient -c almost
immediately :-;

>
> But start up time may still be a trouble when doing small editing. Of

Not really, small editing can be done with emacs -Q ...

> course if you know about Emacs client/server that is not a problem in
> most cases (though someone gave an example with su that would not work
> in this case).

A strange set up IMO. I'm still not sure why emacs can not be configured
to check for a daemon/server. Having to use emacsclient to connect seems
rather long winded but I'm sure there is a good reason for it.

>
>> And with the boom in netbooks and OSen on USB sticks, emacs finds itself
>> more and more pushed into that "heavy dinosaur" category. I'm not saying
>> I *agree* with it, just those are my observations.
>
> I checked my Emacs+EmacsW32 directory tree. It is about 160 MB. I am
> planning to buy a netbook with about 160 GB disk. And hopefully 2 GB
> memory.

Sounds nice. Which model? I'm looking for one too. But it'll be a Linux
one for sure.

Re: Emacs's popularity

[Lennart Borgman]

On Tue, Dec 16, 2008 at 2:01 AM, Richard Riley <rileyrgdev@gmail.com> wrote:
>> course if you know about Emacs client/server that is not a problem in
>> most cases (though someone gave an example with su that would not work
>> in this case).
>
> A strange set up IMO. I'm still not sure why emacs can not be configured
> to check for a daemon/server. Having to use emacsclient to connect seems
> rather long winded but I'm sure there is a good reason for it.

Emacs client starts very quickly.

> Sounds nice. Which model? I'm looking for one too. But it'll be a Linux
> one for sure.

We are not supposed to mention specific brands here. (Ask me privately
if you want to.)I am however going to buy one of those with a large
keyboard. Currently the largest keyboards on netbooks are about 90% of
the full keyboard.

Re: Emacs's popularity

[Richard Riley]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

> On Tue, Dec 16, 2008 at 2:01 AM, Richard Riley <rileyrgdev@gmail.com> wrote:
>>> course if you know about Emacs client/server that is not a problem in
>>> most cases (though someone gave an example with su that would not work
>>> in this case).
>>
>> A strange set up IMO. I'm still not sure why emacs can not be configured
>> to check for a daemon/server. Having to use emacsclient to connect seems
>> rather long winded but I'm sure there is a good reason for it.
>
> Emacs client starts very quickly.

I think you misunderstand what I meant : I agree with you, as I
specifically stated in the previous post

,----
| It does. And if you use emacs -daemon and emacsclient -c almost
| immediately :-;
`----

What I meant by "check for a daemon/server" is that when you press your
normal emacs icon, or type "emacs" it has to be doctored to connect to
the daemon and to start one if one is not already running. It would seem
(to me at any rate) that the the base could be configured to have
"emacs" start as a client if a server is running. If not, start emacs
and start a server.

Possibly you can help me with one small issue I have with the server setup: 

I find the EDITOR/ALTERNATE_EDITOR method ok generally where my emacs alias is
"emacsclient -c". This opens a new frame. But how to open a *new* buffer
in an emacs without using a new frame or even just bring emacs to the
foreground by jumping to the current buffer window? One can not just run
"emacsclient" from the command line or an icon. It says file name or
argument required. And I dont want a new frame all the time especially
since I started using XMonad which is a tiled Window
Manager. "emacsclient filename" works fine of course. Ideally I would
like the "emacsclient -c" functionality but without it creating a new
frame - rather a scratct buffer in the existing frame.

>
>> Sounds nice. Which model? I'm looking for one too. But it'll be a Linux
>> one for sure.
>
> We are not supposed to mention specific brands here. (Ask me privately
> if you want to.)I am however going to buy one of those with a large

I need to drop you some lines soon about nxhtml issues so will so :-;

> keyboard. Currently the largest keyboards on netbooks are about 90% of
> the full keyboard.

Re: Emacs's popularity

[Charles philip Chan]

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

Richard Riley <rileyrgdev@gmail.com> writes:

> And with the boom in netbooks and OSen on USB sticks, emacs finds
> itself more and more pushed into that "heavy dinosaur" category. I'm
> not saying I *agree* with it, just those are my observations.

Interesting enough I bought an Acer Apire One because I want something
more powerful than a PDA, but smaller than a laptop to run Emacs
(especially org-mode) on.

Charles

[-- Attachment #2: Type: application/pgp-signature, Size: 193 bytes --]

Re: Emacs's popularity

[Tim X]

Richard Riley <rileyrgdev@gmail.com> writes:

> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>
>> On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>>
>>>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>>>> always been a bit more popular than Emacs but in the first half of 2007
>>>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>>>> emacs22-bin-common packages:
>>>>>
>>>>>    http://preview.tinyurl.com/5thmmx
>>>>
>>>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>>>
>>>
>>> Not strange at all Lennart, Why would someone run the Emacs OS to run
>>> emulated vim  when they can run the real thing in 100th of the
>>> footprint?
>>
>> Exactly why do you think the footprint matter?
>
> Are you serious?
>
> Memory usage, start speed, response, and all thinks linked.
>
> And with the boom in netbooks and OSen on USB sticks, emacs finds itself
> more and more pushed into that "heavy dinosaur" category. I'm not saying
> I *agree* with it, just those are my observations.
>
> Personally I detest Vi and clones.

I think its an apples and oranges comparison. People who like vi*
editors are less likely to like emacs and vice versa. They serve
different audiences and different ways of working. I was a vi user for
nearly 15 years before I switched to emacs and I've now been using emacs
for 10 years. They way I work with each editor is completely different. 

When I started using emacs I had to change the way I worked because
emacs required it. Instead of opening my editor, doing some work,
closing it and moving on, with emacs, I open it, leave it open and only
close it when I'm logging out, rebooting etc. 

The biggest hurdle to emacs isn't due to 'odd' user interface defaults,
odd terminology or most of the claims that periodically come up in this
group. The hurdle is in the fact that emacs is significantly different
to other text editors. While it has much of the same functionality, the
way you use it is very different and requires something even more
difficult than learning new commands - it requires a paradigm shift and
a change in habits. I failed in my first few attempts simply because I
didn't really have the inclination or drive to make that shift and learn
new habits. Changing defaults, turning on CUA mode, changing terminology
etc is unlikely to have any real impact - this is just surface stuff. In
fact, it cold have a negative impact in that people are likely to make
comparisons based on the common low level functionality and decide there
is nothing about emacs that is any better than, lets say, vi, textmate,
etc. 

I also remain unconvinced by the claims that emacs is dying and needs to
become more popular. Even in the late 80s and 90s, the majority of
people I worked with in the Unix world used vi and its clones. Few used
emacs. Those that did were very dedicated and strong supporters, but
they certainly weren't in the majority - not anywhere I worked at
least. I don't think emacs is ever going to be what wold be called a
popular editor. 

With respect to it dying, I do't think the facts support the
claim. Emacs continues to see steady development. It remains stable and
powerful and still has a very dedicated following. In fact, I suspect
emacs is seeing more new development in recent years than it saw for
much of the 90s. The various forums, such as this newgroup seems to get
a respectable number of posts and I've not seen any great decline over
the last 10 years. The many new enhancements currently available ini
emacs 23, such as support for anti-aliased fonts, utf-8, improved
internationalisation, GTK based interface, built-in support for GPG,
dbus, json, svg graphics, new modes etc don't make me feel like its a
project thats about to die. While some may find criticism for its
development model, it should also be noted that although improvements
are always possible, its a model that has worked for a very long time -
a lot longer than the many other open source and free software projects
that have been cited in this thread. 

I would also be very wary regarding any effort to make emacs
'popular'. All too often, popularity is obtained by appealing to the
lowest common denominator. Emacs has traditionally been focused on the
needs of developers and I think that is still where the focus should
be. 

One of the advantages that emacs has is in the fact it can easily be
customized to suit new environments. I remember when I started doing
java when java was new. At the time, there wasn't a decent editor for
working in Java. One of the very first and possibly the best was JDE,
the emacs java development environment. Now there are numerous editors
that are ideal for working with java and to some extent, JDE may seem a
bit antiquated or limited in comparison. However, the point to note is
that it was one of the first really good environments available on
multiple platforms and provided a good solution while more powerful java
development environments were being implemented and refined. I have been
lucky enough not to have to do any java development for nearly 10 years
now, so I can't really say how JDE compares, but I suspect it looks
somewhat primitive to developers used to existing purpose built
environments. However, this is often a theme with emacs - in the end, it
may not have the best available development environment for your fav
language, but generally, it will be one of the first and I suspect
often, many of the more sophisticated environments used what emacs did
as inspiration. Other fine examples of this can be seen in modes like
SLIME, which is still the best environment I've used for lisp and is as
good as any of the commercial environments. Now, I'm using it with
clojure - as yet, there is no other environment for working with clojure
which comes even close.

I would therefor suggest that rather than spend time and effort trying
to make emacs more popular or attempting to find some miracle formular
consisting of terminology changes, manual updates, new defaults etc,
time would be better spent on improving packages that can help create
really high quality development environments. For example, the CEDET
project and semantic, parsers for different languages, etc are likely to
do a lot more to ensure emacs' continued development and existance. Such
packages and modes are non-trivial and take considerable effort, but
hold the promise of really great things. There are no simple things that
can be done that will achieve much and I would suggest even minor
contributions to significant projects like CEDET will provide far more
benefit than anything else.

peace,

Tim



-- 
tcross (at) rapttech dot com dot au

Re: Emacs's popularity

[Richard Riley]

Tim X <timx@nospam.dev.null> writes:

> Richard Riley <rileyrgdev@gmail.com> writes:
>
>> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>>
>>> On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>>>
>>>>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>>>>> always been a bit more popular than Emacs but in the first half of 2007
>>>>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>>>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>>>>> emacs22-bin-common packages:
>>>>>>
>>>>>>    http://preview.tinyurl.com/5thmmx
>>>>>
>>>>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>>>>
>>>>
>>>> Not strange at all Lennart, Why would someone run the Emacs OS to run
>>>> emulated vim  when they can run the real thing in 100th of the
>>>> footprint?
>>>
>>> Exactly why do you think the footprint matter?
>>
>> Are you serious?
>>
>> Memory usage, start speed, response, and all thinks linked.
>>
>> And with the boom in netbooks and OSen on USB sticks, emacs finds itself
>> more and more pushed into that "heavy dinosaur" category. I'm not saying
>> I *agree* with it, just those are my observations.
>>
>> Personally I detest Vi and clones.
>
> I think its an apples and oranges comparison. People who like vi*
> editors are less likely to like emacs and vice versa. They serve

That's a little obvious :-;

(ps Please note I love emacs  and dont take any arguments below as ill
meant or retaliatory - it's just an interesting banter and exchange)


> different audiences and different ways of working. I was a vi user for

I don't think they do serve different audiences if you define audiences
as people wanting to do a job of work. Both appeal to techy programmer
types. The emacs appeal is for people who make that one further step IMO
and say "hell, I spend most time in my editor, why the hell should I
leave it for peripheral tasks like IRC (erc), EMail (Gnus), or file
management (dired).". For me the advantage of keeping the Emacs UI and
the consistency across task buffers generally more than makes up for any
loss (if such exists) in functionality. We also have an advantage in
that most emacs users who do stick with it have a vested interest in
seeing things work properly. And being programmer types things that are
commonly a PITA get fixed. Its almost never I come across in Emacs which
annoys me which doesnt turn out to be for a very, very good reason and
which suddenly doesnt annoy me any more when I realise the bigger
picture. Emacs is, for me, the "bigger picture" editor ...

> nearly 15 years before I switched to emacs and I've now been using emacs
> for 10 years. They way I work with each editor is completely
> different. 
>
> When I started using emacs I had to change the way I worked because
> emacs required it. Instead of opening my editor, doing some work,
> closing it and moving on, with emacs, I open it, leave it open and only
> close it when I'm logging out, rebooting etc. 
>
> The biggest hurdle to emacs isn't due to 'odd' user interface defaults,
> odd terminology or most of the claims that periodically come up in this
> group. The hurdle is in the fact that emacs is significantly different
> to other text editors. While it has much of the same functionality, the
> way you use it is very different and requires something even more

Which is "odd" (your word not mine) interface defaults, terminology etc.

> difficult than learning new commands - it requires a paradigm shift and
> a change in habits. I failed in my first few attempts simply because I

I don't agree with that. Many editors have buffers and windows for
example. Paradigm shift is too big a word. Emacs is a customisable
editor - you can do a lot of things in it you might have used multiple
programs for before. I would not call this necessarily a paradigm shift.

> didn't really have the inclination or drive to make that shift and learn
> new habits. Changing defaults, turning on CUA mode, changing terminology
> etc is unlikely to have any real impact - this is just surface
> stuff. In

You really think so? My experience of watching new people adopt emacs is
that those are the things which do turn new users off. Even the idea of
pasting in a foreign and alien language like elisp drives a lot of
people off. Can it be helped? Probably not. You want the power then you
must get the license.

> fact, it cold have a negative impact in that people are likely to make
> comparisons based on the common low level functionality and decide there
> is nothing about emacs that is any better than, lets say, vi, textmate,
> etc. 

Exactly - the surface stuff, when not properly guided through, leaves
some people thinking emacs is lacking. My running emacs (and most users
here I dare say) bares little resemblance to the out of the box
experience :-;

>
> I also remain unconvinced by the claims that emacs is dying and needs to
> become more popular. Even in the late 80s and 90s, the majority of
> people I worked with in the Unix world used vi and its clones. Few used
> emacs. Those that did were very dedicated and strong supporters, but
> they certainly weren't in the majority - not anywhere I worked at
> least. I don't think emacs is ever going to be what wold be called a
> popular editor. 

I would agree there in general. But not with all. Popularity is needed
to maintain a degree of "uptodatedness" if I might coin a phrase. We are
lucky that a lot of the more commonly used things in emacs were
developed a long time ago and are merely maintained now. Yes there are
some great things coming through too. Lennart's nxhtml is a great
improvement for example. That in itself will be responsible for keeping a
LOT of people in emacs I daresay. Even then some of the features of
modern IDE editors does make one drool at times ....

>
> With respect to it dying, I do't think the facts support the
> claim. Emacs continues to see steady development. It remains stable and
> powerful and still has a very dedicated following. In fact, I suspect
> emacs is seeing more new development in recent years than it saw for
> much of the 90s. The various forums, such as this newgroup seems to get
> a respectable number of posts and I've not seen any great decline over
> the last 10 years. The many new enhancements currently available ini

Usenet as an indicator is not always the best. There is a core
difference between forums and usenet. And even a cursory glance at emacs
group here shows the same core names and few new ones. I agree with the
previous poster who, despite being a long term user, knows personally
almost no one else who uses it. Is this a good thing? A bad thing? I
dont know. But one thing is for sure - Emacs is a minority editor in
comparison with a lot of others. A lucky minority!

> emacs 23, such as support for anti-aliased fonts, utf-8, improved
> internationalisation, GTK based interface, built-in support for GPG,
> dbus, json, svg graphics, new modes etc don't make me feel like its a
> project thats about to die. While some may find criticism for its
> development model, it should also be noted that although improvements

I saw that post - while not overly familiar with it, there does seem to
be some issues with it for various people. my experience tells me that
is normal for any long term project where certain procedures are
entrenched for historical rather than efficiency reasons. There is
always a new breed chipping at the established foundations of any
project.

> are always possible, its a model that has worked for a very long time -
> a lot longer than the many other open source and free software projects
> that have been cited in this thread. 

Flag waving is great and I agree with you. This does not mean, however,
that emacs is not losing ground. I think it is. And hardly surprising
since the competition is so much greater. Its only to be expected. You
even mention yourself below how people can use Emacs until the other
editors catch up and exceed it in various areas like Java.

>
> I would also be very wary regarding any effort to make emacs
> 'popular'. All too often, popularity is obtained by appealing to the
> lowest common denominator. Emacs has traditionally been focused on the
> needs of developers and I think that is still where the focus should
> be. 

Totally agree. So long as one does not fall foul of the commonly found
"elitist" factor in SW - making sensible defaults, for example, does not
make it "lowest common denominator". Experts can easily replace these
"low brow" settings. It is not so easy for a new user to install them.

Possibly I am new enough back into the emacs fold to remember the pain
and sorrow involved in getting back up to speed in emacs. It's not
easy. It is, however, addictive ....

>
> One of the advantages that emacs has is in the fact it can easily be
> customized to suit new environments. I remember when I started doing
> java when java was new. At the time, there wasn't a decent editor for
> working in Java. One of the very first and possibly the best was JDE,
> the emacs java development environment. Now there are numerous editors
> that are ideal for working with java and to some extent, JDE may seem a
> bit antiquated or limited in comparison. However, the point to note is

Yes. Falling behind. Ditto for C++/C where things like refactoring, api
help, auto completion are all generally not as good as in things like
(yuck) eclipse. But you mention that later with CEDET.

> that it was one of the first really good environments available on
> multiple platforms and provided a good solution while more powerful
> java
> development environments were being implemented and refined. I have
> been

You make it sound like you only like emacs because it fills a gap until
other things "eclipse" it ... (excuse my pun). This is in itself an
indicator of a view that you might have without realising it - "good old
emacs - it'll do I suppose but for sure something will do it properly
soon enough". Personally I resist the urge to use other editors no
matter what they offer..

> lucky enough not to have to do any java development for nearly 10 years
> now, so I can't really say how JDE compares, but I suspect it looks
> somewhat primitive to developers used to existing purpose built
> environments. However, this is often a theme with emacs - in the end,
> it
> may not have the best available development environment for your fav
> language, but generally, it will be one of the first and I suspect
> often, many of the more sophisticated environments used what emacs did
> as inspiration. Other fine examples of this can be seen in modes like

Yes..

> SLIME, which is still the best environment I've used for lisp and is
> as

One would probably expect elisp and LISP support to be good in emacs.

> good as any of the commercial environments. Now, I'm using it with
> clojure - as yet, there is no other environment for working with clojure
> which comes even close.
>
> I would therefor suggest that rather than spend time and effort trying
> to make emacs more popular or attempting to find some miracle formular
> consisting of terminology changes, manual updates, new defaults etc,
> time would be better spent on improving packages that can help create
> really high quality development environments. For example, the CEDET
> project and semantic, parsers for different languages, etc are likely to
> do a lot more to ensure emacs' continued development and existance. Such
> packages and modes are non-trivial and take considerable effort, but
> hold the promise of really great things. There are no simple things that
> can be done that will achieve much and I would suggest even minor
> contributions to significant projects like CEDET will provide far more
> benefit than anything else.

This I totally agree with. My few encounters with CEDET have been
promising but I never really got autocompletion working properly!

Interesting post and I look forward to further discussion.

>
> peace,
>
> Tim

-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: Emacs's popularity

[Tim X]

"Charles philip Chan" <cpchan@sympatico.ca> writes:

> Richard Riley <rileyrgdev@gmail.com> writes:
>
>> And with the boom in netbooks and OSen on USB sticks, emacs finds
>> itself more and more pushed into that "heavy dinosaur" category. I'm
>> not saying I *agree* with it, just those are my observations.
>
> Interesting enough I bought an Acer Apire One because I want something
> more powerful than a PDA, but smaller than a laptop to run Emacs
> (especially org-mode) on.
>

I know of someone who like me is blind and is running emacs + emacspeak
on a Asus EEEPC running Debian. I've also got an Asus EEEPC and as soon
as I can get a sighted person with enough time to spend a day with me
setting it up, I will be doing the same thing.  Essentially, with its
built-in wireless capabilities, I can use it as a 'speaking terminal'
and access everything I need from the net using it. Most of my work will
reside on my home and work linux workstation, but I'll access it using
tramp, ssh, eshell, etc. I have even worked out a way to use sql-mode,
running sqlplus on the workstation, so for me, it will be extremely useful.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Emacs's popularity

[Phil Carmody]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:
> On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>
>>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>>> always been a bit more popular than Emacs but in the first half of 2007
>>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>>> emacs22-bin-common packages:
>>>>
>>>>    http://preview.tinyurl.com/5thmmx
>>>
>>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>>
>>
>> Not strange at all Lennart, Why would someone run the Emacs OS to run
>> emulated vim  when they can run the real thing in 100th of the
>> footprint?
>
> Exactly why do you think the footprint matter?

1 vote for 'emacs has a large footprint, and that matters to me'. My machine
has 128MB RAM. Emacs 21 is pretty OK, but 22 uses noticeably more memory,
which is my most limited resource.

Exactly why do you think that it doesn't matter?

But it's not just RAM footprint where emacs compares unfavourably to vim, 
in fact, RAM-wise it's not a huge difference, only about a couple of megs
difference. Far more importantly is the CPU footprint.  Emacs 21 takes 3 
times as long to start up as vim does on a large plain text file (so no 
syntax highlighting or anything being done). Emacs 22 takes even longer, 
in particular as the loading was interrupted with a "that's a big file, 
are you sure?" prompt.

Can you imagine vim-proponents not looking at these times (averaged over
3 runs, after everything was in the cache) with a sense of pride?

   vim  emacs21 emacs22
 0.004    0.10    0.20   = start with no file, quit
 0.18     0.58    0.62   = start with 12MB file, quit
 ????     0.59    0.66   = start with no file, open 12MB file, quit

(didn't know how to open a file from within vim, as it's utterly illucid.)

In which case, why shouldn't we emacs proponents look on them with a sense
of shame? More than 3 times slower - is that not shameful?

Phil
-- 
I tried the Vista speech recognition by running the tutorial. I was 
amazed, it was awesome, recognised every word I said. Then I said the 
wrong word ... and it typed the right one. It was actually just 
detecting a sound and printing the expected word! -- pbhj on /.

Re: Emacs's popularity

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 12:34, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> wrote:

> In which case, why shouldn't we emacs proponents look on them with a sense
> of shame? More than 3 times slower - is that not shameful?

No, because Emacs is not optimized for that kind of use pattern.

    Juanma

Re: Emacs's popularity

[Phil Carmody]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> On Tue, Dec 16, 2008 at 12:34, Phil Carmody
> <thefatphil_demunged@yahoo.co.uk> wrote:
>
>> In which case, why shouldn't we emacs proponents look on them with a sense
>> of shame? More than 3 times slower - is that not shameful?
>
> No, because Emacs is not optimized for that kind of use pattern.

Opening files?

Phil
-- 
I tried the Vista speech recognition by running the tutorial. I was 
amazed, it was awesome, recognised every word I said. Then I said the 
wrong word ... and it typed the right one. It was actually just 
detecting a sound and printing the expected word! -- pbhj on /.

Re: Emacs's popularity

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 13:36, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> wrote:

> Opening files?

Starting, opening a file, and exiting.

If vi loads a file much faster than Emacs in normal usage, that's a
cause for concern, specially if we're talking of a long time (more
than a few tenths of seconds, well into the seconds). But the examples
were "start, read file, quit". For that kind of thing the user would
use emacsclient/server. Emacs almost expects to start once a day
(week, etc.) at most.

Note that I'm not saying that is the "right" way to use Emacs; just
that it is more optimized for that kind of pattern. I start Emacs many
times a day (though, truth be told, startup time has never been
problematic, unless you happen to open etc/HELLO ;-)

    Juanma

Re: Emacs's popularity

[Phil Carmody]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> On Tue, Dec 16, 2008 at 13:36, Phil Carmody
> <thefatphil_demunged@yahoo.co.uk> wrote:
>
>> Opening files?
>
> Starting, opening a file, and exiting.
>
> If vi loads a file much faster than Emacs in normal usage, that's a
> cause for concern

Subtract the 'start, quit' time from the 'start, open file, quit' time.
That's the file open time. Is vim loading a file at twice the speed of 
emacs cause for concern?

> , specially if we're talking of a long time (more
> than a few tenths of seconds, well into the seconds). But the examples
> were "start, read file, quit". For that kind of thing the user would
> use emacsclient/server. Emacs almost expects to start once a day
> (week, etc.) at most.

That's why I specifically pointed out "opening files" above.
That's why I specifically gave a 'start, quit' time so that the
start and the quit could be subtracted from the 'start, open, quit'
time. You don't seriously think that I was considering 'start, quit'
to be an actual usage scenario whose time is important, do you?

> Note that I'm not saying that is the "right" way to use Emacs; just
> that it is more optimized for that kind of pattern. I start Emacs many
> times a day (though, truth be told, startup time has never been
> problematic, unless you happen to open etc/HELLO ;-)

My emacses, and alas I seem to have to have 2 open, stay open for
roughly 1 months (the GNUS one), and 1 week (the code editing one).

The reason I don't use the client/server setup is that I absolutely
do not want C/Perl code buffers appearing or being offered to me
while I'm doing stuff in GNUS, and I absolutely do not want newsgroup/
SCORE buffers appearing or being offered to me when I'm doing stuff
with coding. Is there any way to keep these two sessions independent 
and still use the client/server setup?

Phil
-- 
I tried the Vista speech recognition by running the tutorial. I was 
amazed, it was awesome, recognised every word I said. Then I said the 
wrong word ... and it typed the right one. It was actually just 
detecting a sound and printing the expected word! -- pbhj on /.

Re: Emacs's popularity

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 14:03, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> wrote:

> Subtract the 'start, quit' time from the 'start, open file, quit' time.
> That's the file open time. Is vim loading a file at twice the speed of
> emacs cause for concern?

Depends on the total time, and also on what are both editors doing
(syntax coloring, conversion, etc.). I don't doubt you're right that
Emacs is slower than vi; I can only offer my personal experience that,
for me, it is rare indeed the file where loading causes a significant,
annoying delay. I suppose it will be much more common in old hardware.

> You don't seriously think that I was considering 'start, quit'
> to be an actual usage scenario whose time is important, do you?

I found your way of presenting the data confusing. If you're
interested only in the file load time, why list the other times too?
If your interlocutor doesn't trust you to do a subtraction he won't
trust you to do the measures in the first place. [That said, it is
entirely possible your message was quite clear and I just didn't get
it; the flu's got the better of me right now.)

> The reason I don't use the client/server setup is that I absolutely
> do not want C/Perl code buffers appearing or being offered to me
> while I'm doing stuff in GNUS, and I absolutely do not want newsgroup/
> SCORE buffers appearing or being offered to me when I'm doing stuff
> with coding. Is there any way to keep these two sessions independent
> and still use the client/server setup?

I think the variable `server-window' could be useful. Or did you try
it already and didn't suit your needs?

    Juanma

Re: Emacs's popularity

[Phil Carmody]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> The reason I don't use the client/server setup is that I absolutely
>> do not want C/Perl code buffers appearing or being offered to me
>> while I'm doing stuff in GNUS, and I absolutely do not want newsgroup/
>> SCORE buffers appearing or being offered to me when I'm doing stuff
>> with coding. Is there any way to keep these two sessions independent
>> and still use the client/server setup?
>
> I think the variable `server-window' could be useful. Or did you try
> it already and didn't suit your needs?

I've never tried it, and, looking at the documentation, I can't
work out how to use it.
"""
Documentation:
Specification of the window to use for selecting Emacs server buffers.
If nil, use the selected window.
If it is a function, it should take one argument (a buffer) and
display and select it.  A common value is `pop-to-buffer'.
If it is a window, use that.
If it is a frame, use the frame's selected window.
"""

So I just created a new frame, and dragged it to my coding desktop,
how do I find out how to identify that frame? Going there and 
C-h v frame TAB gives:
"""
Possible completions are:
frame-background-mode              frame-creation-function
frame-initial-frame                frame-initial-frame-alist
frame-initial-geometry-arguments   frame-name-history
frame-notice-user-settings         frame-title-format
"""
Which looks useless.

Maybe there's a function which will tell me how to identify the
frame I'm in. C-h a frame doesn't really list much that seems useful.
Maybe there's something that's not listed. M-x frame TAB does list
a few more functions (why aren't they in the apropos?) - in particular
frame-list. Something which looked like it appears to be identifiers
for frames appears in the message bar, but annoyingly isn't selectable
by the mouse (why isn't the text there selectable?). So I go to 
the *Messages* buffer:
"""
(#<frame *scratch* 0x85e1500> #<frame *followup to Juanma Barranquero on gnu.emacs.help* 0x85d5fd0>)
"""

So, let's try to use the former as an identifier for M-x set-variable server-window
"""
if: Invalid read syntax: "#"
byte-code: Beginning of buffer
"""

So the function that "Return[s] a list of all frames." apparently doesn't
return anthing that can be directly used as an identifier for frames. 

So how should I set server-window to be on my new frame?
And how should it be done automatically?

And here's one extra thing that's a bit puzzling - why is it a 
server-*window*? Windows come and go, get split, resized and what-
have-you. When I started the new frame, it had the windows, 
according to M-x window-list, 
(#<window 454 on *scratch*> #<window 464 on *scratch*>).
But a few C-x 2, C-x o, and C-x 0 later, it's now 
(#<window 490 on *scratch*> #<window 491 on *scratch*>).
What good would it have done if I had succeded in setting the 
server-window to one of the two original windows? Wouldn't a 
server-frame be far more useful?


Assuming "Emacs server buffers" means the buffers that were opened
via the server, then that's only going to be a subset of the buffers
that I'll want to be sandboxed together. M-x ff-f, and I'll have my 
header files in there too; M-x compile or M-x ediff, and I could 
have arbitrary other files and non-file buffers. So "being opened 
via the server or not" is not a good way to separate the code buffers 
from the GNUS buffers.

And this is why I run 2 emacses, one for news, and one for coding.

Phil
-- 
I tried the Vista speech recognition by running the tutorial. I was 
amazed, it was awesome, recognised every word I said. Then I said the 
wrong word ... and it typed the right one. It was actually just 
detecting a sound and printing the expected word! -- pbhj on /.

Re: Emacs's popularity

[Richard Riley]

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>> The reason I don't use the client/server setup is that I absolutely
>>> do not want C/Perl code buffers appearing or being offered to me
>>> while I'm doing stuff in GNUS, and I absolutely do not want newsgroup/
>>> SCORE buffers appearing or being offered to me when I'm doing stuff
>>> with coding. Is there any way to keep these two sessions independent
>>> and still use the client/server setup?
>>
>> I think the variable `server-window' could be useful. Or did you try
>> it already and didn't suit your needs?
>
> I've never tried it, and, looking at the documentation, I can't
> work out how to use it.
> """
> Documentation:
> Specification of the window to use for selecting Emacs server buffers.
> If nil, use the selected window.
> If it is a function, it should take one argument (a buffer) and
> display and select it.  A common value is `pop-to-buffer'.
> If it is a window, use that.
> If it is a frame, use the frame's selected window.
> """
>
> So I just created a new frame, and dragged it to my coding desktop,
> how do I find out how to identify that frame? Going there and 
> C-h v frame TAB gives:
> """
> Possible completions are:
> frame-background-mode              frame-creation-function
> frame-initial-frame                frame-initial-frame-alist
> frame-initial-geometry-arguments   frame-name-history
> frame-notice-user-settings         frame-title-format
> """
> Which looks useless.
>
> Maybe there's a function which will tell me how to identify the
> frame I'm in. C-h a frame doesn't really list much that seems useful.
> Maybe there's something that's not listed. M-x frame TAB does list
> a few more functions (why aren't they in the apropos?) - in particular
> frame-list. Something which looked like it appears to be identifiers
> for frames appears in the message bar, but annoyingly isn't selectable
> by the mouse (why isn't the text there selectable?). So I go to 
> the *Messages* buffer:
> """
> (#<frame *scratch* 0x85e1500> #<frame *followup to Juanma Barranquero on gnu.emacs.help* 0x85d5fd0>)
> """
>
> So, let's try to use the former as an identifier for M-x set-variable server-window
> """
> if: Invalid read syntax: "#"
> byte-code: Beginning of buffer
> """
>
> So the function that "Return[s] a list of all frames." apparently doesn't
> return anthing that can be directly used as an identifier for frames. 
>
> So how should I set server-window to be on my new frame?
> And how should it be done automatically?
>
> And here's one extra thing that's a bit puzzling - why is it a 
> server-*window*? Windows come and go, get split, resized and what-
> have-you. When I started the new frame, it had the windows, 
> according to M-x window-list, 
> (#<window 454 on *scratch*> #<window 464 on *scratch*>).
> But a few C-x 2, C-x o, and C-x 0 later, it's now 
> (#<window 490 on *scratch*> #<window 491 on *scratch*>).
> What good would it have done if I had succeded in setting the 
> server-window to one of the two original windows? Wouldn't a 
> server-frame be far more useful?
>
>
> Assuming "Emacs server buffers" means the buffers that were opened
> via the server, then that's only going to be a subset of the buffers
> that I'll want to be sandboxed together. M-x ff-f, and I'll have my 
> header files in there too; M-x compile or M-x ediff, and I could 
> have arbitrary other files and non-file buffers. So "being opened 
> via the server or not" is not a good way to separate the code buffers 
> from the GNUS buffers.
>
> And this is why I run 2 emacses, one for news, and one for coding.
>
> Phil

I was looking at server-window myself recently (this morning) hoping it
might address some issues with calling emacslient to connect to a
running emac without needing to specify a file name or "-c" for new
frame. It confused me a tad too.

I see your reasoning for two emacs - running the server with emacs, erc
etc running and numerous code buffer leads to all sorts of hassles when
doing someting like reading mail in gnus especially when you have an
article buffer open in another frame on another workspace in XMonad or
something :-;


-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: Emacs's popularity

[Andrea Vettorello]

On Tue, Dec 16, 2008 at 4:50 PM, Richard Riley <rileyrgdev@gmail.com> wrote:

[...]

> I was looking at server-window myself recently (this morning) hoping it
> might address some issues with calling emacslient to connect to a
> running emac without needing to specify a file name or "-c" for new
> frame. It confused me a tad too.

Something I was looking myself (launching emacsclient without a
filename), I ended up modifying emacsclient...


-- 
Andrea

Re: Emacs's popularity

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 16:09, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> wrote:

> So I just created a new frame, and dragged it to my coding desktop,
> how do I find out how to identify that frame?

See the function `selected-frame'.

For example, you could create a new frame, and then, with the focus on
it, you can do

  M-: (setq server-window (selected-frame)) <RET>

Of course, if you plan to do it automatically from your .emacs you
could use something like this (not tested):

  (setq server-window (make-frame '((height . 40) (width . 80))))

> Maybe there's a function which will tell me how to identify the
> frame I'm in.

Yes.

> C-h a frame doesn't really list much that seems useful.

On the contrary, I'd say it lists a lot of useful things (too many, perhaps).

> And here's one extra thing that's a bit puzzling - why is it a
> server-*window*?

Why not? The name comes from the original (but still valid) use of the variable.

> What good would it have done if I had succeded in setting the
> server-window to one of the two original windows? Wouldn't a
> server-frame be far more useful?

Apparently, for you the answer is yes :-) Not for me, I dislike having
several frames.

> And this is why I run 2 emacses, one for news, and one for coding.

I think with a suitable setup of server.el you wouldn't really need
that, but if you like it more your can run two emacsen, each one of
them a server (with different names, for example "news" and "coding"),
and use

   emacsclient --server=news file1
   emacsclient --server=coding file2

    Juanma

Re: Emacs's popularity

[Paul R]

Phil> Maybe there's a function which will tell me how to identify the
Phil> frame I'm in. C-h a frame doesn't really list much that seems
Phil> useful.

You probably missed it 

    selected-frame
      Function: Return the frame that is now selected.

-- 
  Paul

Re: Emacs's popularity

[Richard Riley]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Tue, Dec 16, 2008 at 16:09, Phil Carmody
> <thefatphil_demunged@yahoo.co.uk> wrote:
>
>> So I just created a new frame, and dragged it to my coding desktop,
>> how do I find out how to identify that frame?
>
> See the function `selected-frame'.
>
> For example, you could create a new frame, and then, with the focus on
> it, you can do
>
>   M-: (setq server-window (selected-frame)) <RET>
>
> Of course, if you plan to do it automatically from your .emacs you
> could use something like this (not tested):
>
>   (setq server-window (make-frame '((height . 40) (width . 80))))
>
>> Maybe there's a function which will tell me how to identify the
>> frame I'm in.
>
> Yes.
>
>> C-h a frame doesn't really list much that seems useful.
>
> On the contrary, I'd say it lists a lot of useful things (too many,
> perhaps).


One assumes he meant concerning the subject at hand :-;

>
>> And here's one extra thing that's a bit puzzling - why is it a
>> server-*window*?
>
> Why not? The name comes from the original (but still valid) use of the
> variable.

Because one considers connecting to servers and process instances, not
"windows" which have a clear meaning. Or am I confused here? Actually
scrub that. I know I am.

>
>> What good would it have done if I had succeded in setting the
>> server-window to one of the two original windows? Wouldn't a
>> server-frame be far more useful?
>
> Apparently, for you the answer is yes :-) Not for me, I dislike having
> several frames.

>
>> And this is why I run 2 emacses, one for news, and one for coding.
>
> I think with a suitable setup of server.el you wouldn't really need

Do you mean a new server.el? Or a setup of the existing one?

> that, but if you like it more your can run two emacsen, each one of
> them a server (with different names, for example "news" and "coding"),
> and use
>
>    emacsclient --server=news file1
>    emacsclient --server=coding file2

my emacslient doesn't have this parameter. Could you explain in more
details please? How to start the named servers using (server-start)  and
how to connect.

>
>     Juanma
>
>

-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: Emacs's popularity

[Phil Carmody]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> On Tue, Dec 16, 2008 at 16:09, Phil Carmody
> <thefatphil_demunged@yahoo.co.uk> wrote:
>> So I just created a new frame, and dragged it to my coding desktop,
>> how do I find out how to identify that frame?
>
> See the function `selected-frame'.
>
> For example, you could create a new frame, and then, with the focus on
> it, you can do
>
>   M-: (setq server-window (selected-frame)) <RET>
>
> Of course, if you plan to do it automatically from your .emacs you
> could use something like this (not tested):
>
>   (setq server-window (make-frame '((height . 40) (width . 80))))
[SNIP - lots more]

Plenty to digest there, but too late to experiment with it tonight - 
many thanks!

Phil
-- 
I tried the Vista speech recognition by running the tutorial. I was 
amazed, it was awesome, recognised every word I said. Then I said the 
wrong word ... and it typed the right one. It was actually just 
detecting a sound and printing the expected word! -- pbhj on /.

Re: Emacs's popularity

[Andreas Politz]

Phil Carmody wrote:
> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>> On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>>
>>>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>>>> always been a bit more popular than Emacs but in the first half of 2007
>>>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>>>> emacs22-bin-common packages:
>>>>>
>>>>>    http://preview.tinyurl.com/5thmmx
>>>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>>>
>>> Not strange at all Lennart, Why would someone run the Emacs OS to run
>>> emulated vim  when they can run the real thing in 100th of the
>>> footprint?
>> Exactly why do you think the footprint matter?
> 
> 1 vote for 'emacs has a large footprint, and that matters to me'. My machine
> has 128MB RAM. Emacs 21 is pretty OK, but 22 uses noticeably more memory,
> which is my most limited resource.
> 
> Exactly why do you think that it doesn't matter?
> 
> But it's not just RAM footprint where emacs compares unfavourably to vim, 
> in fact, RAM-wise it's not a huge difference, only about a couple of megs
> difference. Far more importantly is the CPU footprint.  Emacs 21 takes 3 
> times as long to start up as vim does on a large plain text file (so no 
> syntax highlighting or anything being done). Emacs 22 takes even longer, 
> in particular as the loading was interrupted with a "that's a big file, 
> are you sure?" prompt.
> 
> Can you imagine vim-proponents not looking at these times (averaged over
> 3 runs, after everything was in the cache) with a sense of pride?
> 
>    vim  emacs21 emacs22
>  0.004    0.10    0.20   = start with no file, quit
>  0.18     0.58    0.62   = start with 12MB file, quit
>  ????     0.59    0.66   = start with no file, open 12MB file, quit

The command to open a <file> is ':edit <file>'.
> 
> (didn't know how to open a file from within vim, as it's utterly illucid.)
> 
> In which case, why shouldn't we emacs proponents look on them with a sense
> of shame? More than 3 times slower - is that not shameful?
> 
> Phil

Here are a couple more numbers :

$ time vim -c 'quit'

real    0m0.226s
user    0m0.112s
sys     0m0.048s

Processed lines of vimscript : 18867
(According to the vim command :scriptnames)*

$ time emacs -nw -Q '(kill-emacs)'

real    0m0.234s
user    0m0.168s
sys     0m0.036s

Processed lines of byte compiled elisp : 50717
(According to load-histoy)*

* and 'wc -l'

I took the best out of 3 trys.

Note I was a heavy vim user, so I got lots of vimscripts
around. If you start vim w/o anything loaded (e.g. in compatible
mode) or a bare minimum (e.g. just a simple ~/.vimrc) it'll be
ligthning fast. Maybe you can try and load emacs with a nil
load-history ?

However, vim is completely written in C with an optional
interpreter for it's own extension language (you can start
editing in vim w/o reading a single line of vimscript), it'll
always be faster, in some sense of 'faster'.

I don't know how far you'll get in emacs using only
the c level functions, probablly not far.

-ap

Re: Emacs's popularity

[Phil Carmody]

Andreas Politz <politza@fh-trier.de> writes:
> Phil Carmody wrote:
>>    vim  emacs21 emacs22
>>  0.004    0.10    0.20   = start with no file, quit
>> [0.16]   [0.43]   0.62   = start with 12MB file, quit
>> [0.16]   [0.44]   0.66   = start with no file, open 12MB file, quit
>
> The command to open a <file> is ':edit <file>'.

Ta! Times in [] adjusted to some new runs (I also equalised the
load on the otherwise identical machines too). (For reference, 
all were non-X versions of the editors.)

> Here are a couple more numbers :
>
> $ time vim -c 'quit'
>
> real    0m0.226s
> user    0m0.112s
> sys     0m0.048s
>
> Processed lines of vimscript : 18867
> (According to the vim command :scriptnames)*

Yikes!

real    0m0.012s
user    0m0.004s
sys     0m0.004s

125 lines (default Debian install)

> However, vim is completely written in C with an optional
> interpreter for it's own extension language (you can start
> editing in vim w/o reading a single line of vimscript), it'll
> always be faster, in some sense of 'faster'.

Indeed. One of the reasons I like emacs is because of the 
'kitchen sink' nature of it. I've tried a dozen newsreaders
in my time, and none of them quite do it for me like GNUS 
does. compile and (r)grep mode are undispensible. gdb likewise.
I love the unbounded scrollback history and incremental search
in shell windows, etc. ad nauseam, I simply can't survive 
without it.

I suspect that a poweruser could also do most of the above 
in vim too, but the learning curve is just too steep. Out of
the box, emacs does more, and gets me doing more, quicker 
than vim.

One thing that shocked me whilst looking at some simple core 
lisp modules in emacs, in order to get some hints how to do 
a quick 'copy one character from the line above' function,
the other week was the absurd inefficiency of some of the 
functions. The transpose-* family, for example. Imagine
what the number of bit-ops the transpose-chars equivalent
in vim would be compared with the emacs implementation. 
(go on - have a look - it's in simple.el)

Phil
-- 
I tried the Vista speech recognition by running the tutorial. I was 
amazed, it was awesome, recognised every word I said. Then I said the 
wrong word ... and it typed the right one. It was actually just 
detecting a sound and printing the expected word! -- pbhj on /.

Re: Emacs's popularity

[Tim X]

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>> On Mon, Dec 15, 2008 at 11:28 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>>
>>>>> But Vim is not only installed; it's really used a lot. In Debian Vim has
>>>>> always been a bit more popular than Emacs but in the first half of 2007
>>>>> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
>>>>> "used actively" graph compares vim-common, emacs21-bin-common and
>>>>> emacs22-bin-common packages:
>>>>>
>>>>>    http://preview.tinyurl.com/5thmmx
>>>>
>>>> That is a bit strange since the vi emulator Viper in Emacs is now so good.
>>>>
>>>
>>> Not strange at all Lennart, Why would someone run the Emacs OS to run
>>> emulated vim  when they can run the real thing in 100th of the
>>> footprint?
>>
>> Exactly why do you think the footprint matter?
>
> 1 vote for 'emacs has a large footprint, and that matters to me'. My machine
> has 128MB RAM. Emacs 21 is pretty OK, but 22 uses noticeably more memory,
> which is my most limited resource.
>
> Exactly why do you think that it doesn't matter?
>
> But it's not just RAM footprint where emacs compares unfavourably to vim, 
> in fact, RAM-wise it's not a huge difference, only about a couple of megs
> difference. Far more importantly is the CPU footprint.  Emacs 21 takes 3 
> times as long to start up as vim does on a large plain text file (so no 
> syntax highlighting or anything being done). Emacs 22 takes even longer, 
> in particular as the loading was interrupted with a "that's a big file, 
> are you sure?" prompt.
>
> Can you imagine vim-proponents not looking at these times (averaged over
> 3 runs, after everything was in the cache) with a sense of pride?
>
>    vim  emacs21 emacs22
>  0.004    0.10    0.20   = start with no file, quit
>  0.18     0.58    0.62   = start with 12MB file, quit
>  ????     0.59    0.66   = start with no file, open 12MB file, quit
>
> (didn't know how to open a file from within vim, as it's utterly illucid.)
>
> In which case, why shouldn't we emacs proponents look on them with a sense
> of shame? More than 3 times slower - is that not shameful?
>

No, not at all. The comparison really doesn't mean anything because
the speed at which an editor starts or quits is quite irrelevant to
using it. Its like saying my car is better than a jet because I can jump
in it and start traveling quicker than I can jump in a jet and start
traveling - its the quality of the trip that matters, not how fast it is
to start and stop. 

Your comparison is also too basic on too many dimensions to list. If you
can show me an editor that has the same advanced functionality,
features, extensibility etc etc that is a lot faster with a much smaller
memory and cpu footprint, then maybe you may have a point. Under your
metric, notepad would likely be faster and therefore look better, but we
know it isn't. 

Having said this, there are many things, most of them due to historical
decisions, that may become a real problem for emacs. For example,
reading large files, multi-threading, elisp speed etc. None of these
seem to be a huge issue yet, but in the future......

I suspect that at some point, another editor, inspired by emacs, will
possibly replace emacs. Maybe it will use guile, common lisp or some
other extensible scripting language with more power than elisp. maybe it
will be designed form the ground up with support for all those things
now considered important that were not even on the horizon when emacs
was first being designed. This isn't a problem and to some extent is
just natural evolution. However, I can't see this happening for a long
time - it would take a lot of work to create a new editor from scratch
that had the power of emacs, but its not something to be feared. Rather,
its something to be embraced!

Until then, I'll continue to use emacs as the only editor I use and I
use it at least 10 hours Mon-Fri and a good 6+ hours sat and sun. If a
better alternative comes along, I'll adopt it. Until then....

regards,

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Emacs's popularity

[B Smith-Mannschott]

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

> I suspect that at some point, another editor, inspired by emacs, will
> possibly replace emacs. Maybe it will use guile, common lisp or some
> other extensible scripting language with more power than elisp. maybe it
> will be designed form the ground up with support for all those things
> now considered important that were not even on the horizon when emacs
> was first being designed. This isn't a problem and to some extent is
> just natural evolution. However, I can't see this happening for a long
> time - it would take a lot of work to create a new editor from scratch
> that had the power of emacs, but its not something to be feared. Rather,
> its something to be embraced!
>

I sometimes think Eclipse is that editor. Of course it misses one of Emacs'
strengths in that extending it is a rather heavy-weight process. This
distinguishes it from systems like Emacs, SmallTalk, Oberon, which blur the
line between development tool and platform far more than Eclipse manages to.



> Until then, I'll continue to use emacs as the only editor I use and I
> use it at least 10 hours Mon-Fri and a good 6+ hours sat and sun. If a
> better alternative comes along, I'll adopt it. Until then....
>

Here too, along with Eclipse (with Emacs keybindings).


-- 
// Ben Smith-Mannschott

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

Re: Emacs's popularity

[Óscar Fuentes]

Teemu Likonen <tlikonen@iki.fi> writes:

[snip]

> But Vim is not only installed; it's really used a lot.[snip]

Inspecting the atime of emacs and vim executables on my machine, one
could conclude that I frequently use vim and almost never emacs. The
true is the opposite: I start emacs just after login and don't close it
until the next time that I'm in the mood of updating to the last CVS
version, or until the next reboot. This can mean several months of
intense use. OTOH, whenever I need to tweak some file on /etc, I do a
sudo vim /etc/whatever

-- 
Oscar

Re: Emacs's popularity

[Tim X]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Teemu Likonen <tlikonen@iki.fi> writes:
>
> [snip]
>
>> But Vim is not only installed; it's really used a lot.[snip]
>
> Inspecting the atime of emacs and vim executables on my machine, one
> could conclude that I frequently use vim and almost never emacs. The
> true is the opposite: I start emacs just after login and don't close it
> until the next time that I'm in the mood of updating to the last CVS
> version, or until the next reboot. This can mean several months of
> intense use. OTOH, whenever I need to tweak some file on /etc, I do a
> sudo vim /etc/whatever

I use to do it that way, but now I jus do  (for example)

C-x C-f /root@localhost:/etc/aliases 

tramp will prompt me for the root password and if I get it correct, will
open the file in an emacs buffer. No need to setup anything special, but
you can make it even easier if you setup sudo appropriately (which I've
not bothered doing cause I'm lazy!)

Tim
-- 
tcross (at) rapttech dot com dot au

Re: Emacs's popularity

[William Case]

Hi;

On Mon, 2008-12-15 at 23:37 +0200, Teemu Likonen wrote:
> Jonathan Groll (2008-12-15 23:09 +0200) wrote:
> 
> > Sadly, vim outvotes all flavours of GNU emacs on the above graph when
> > added to it (although to be fair, on Debian emacs is not installed by
> > default but some flavour of vi is).
> 
> Yes, nowadays Vim is in every Debian installation (priority "important"
> for vim-tiny). The popularity graph by installs (percent) shows that
> vim-common is basically in everyone's system:
> 
>     http://preview.tinyurl.com/6g934p
> 
> But Vim is not only installed; it's really used a lot. In Debian Vim has
> always been a bit more popular than Emacs but in the first half of 2007
> Vim really got popular (around Vim 7.1 and Debian 4.0 release). This
> "used actively" graph compares vim-common, emacs21-bin-common and
> emacs22-bin-common packages:
> 
>     http://preview.tinyurl.com/5thmmx

My experience is that a Linux user, particularly a new user, should take
a couple of hours to learn the rudiments of each.  Not only to make an
informed choice about whether emacs or vim suits them best as a text
editor, but also because most of the key strokes for command line
programs are based on one or the other, e.g. readline on emacs; less on
vi.  It took me a couple of years to fully understand that if I learnt
those two programs (vi and emacs), I didn't have to memorize hundreds of
key strokes for all my utility programs.
-- 
Regards Bill
Fedora 9, Gnome 2.22.3
Evo.2.22.3.1, Emacs 22.2.1

RE: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Drew Adams]

> Sadly, vim outvotes all flavours of GNU emacs on the above graph when
> added to it (although to be fair, on Debian emacs is not installed by
> default but some flavour of vi is).

Hm. Dunno why that should make one sad. I would never use vi or vim (unless I
had to), but I don't see why I should be sad or bothered if other people find it
useful. One person likes to live in the forest; another prefers the city; a
third the shore.

Why the need to make Emacs the most popular? It's good to make Emacs better, but
what's the popularity contest about? Perhaps Americans on average listen to
Britney Spears more than Mozart or Muddy Waters. So what?

On the other hand, info about the relative use of different Emacs versions is
(mildly) interesting and might be helpful in some ways.

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Lennart Borgman]

On Mon, Dec 15, 2008 at 11:03 PM, Drew Adams <drew.adams@oracle.com> wrote:
> Hm. Dunno why that should make one sad. I would never use vi or vim (unless I
> had to), but I don't see why I should be sad or bothered if other people find it
> useful. One person likes to live in the forest; another prefers the city; a
> third the shore.
>
> Why the need to make Emacs the most popular? It's good to make Emacs better, but
> what's the popularity contest about? Perhaps Americans on average listen to
> Britney Spears more than Mozart or Muddy Waters. So what?
>
> On the other hand, info about the relative use of different Emacs versions is
> (mildly) interesting and might be helpful in some ways.

It might also be worthwhile thinking about why vi clones are more
popular than Emacs.

RE: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Drew Adams]

> It might also be worthwhile thinking about why vi clones are more
> popular than Emacs.

Maybe, if specific vi features are found to be important to that popularity and
those features (or similar) might also make sense for Emacs.

IOW, (1) yes, one can always learn from others, and (2) the devil is in the
details.

General lamentation about the relative popularity of Emacs wrt vi, TextPad, or
anything else is what I don't understand.

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Lennart Borgman]

On Mon, Dec 15, 2008 at 11:19 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> It might also be worthwhile thinking about why vi clones are more
>> popular than Emacs.
>
> Maybe, if specific vi features are found to be important to that popularity and
> those features (or similar) might also make sense for Emacs.

I think there are other possibilities too. For example it might be
that people are used to that some vi program is always available, vi
starts up quickly.

Or perhaps it is that vi key bindings are perhaps more well-known
nowadays. Emacs key bindings tend to clash with cua bindings which
probably makes the emacs bindings less wellknown.

Re: Emacs's popularity

[Tim X]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

> On Mon, Dec 15, 2008 at 11:19 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>> It might also be worthwhile thinking about why vi clones are more
>>> popular than Emacs.
>>
>> Maybe, if specific vi features are found to be important to that popularity and
>> those features (or similar) might also make sense for Emacs.
>
> I think there are other possibilities too. For example it might be
> that people are used to that some vi program is always available, vi
> starts up quickly.
>
> Or perhaps it is that vi key bindings are perhaps more well-known
> nowadays. Emacs key bindings tend to clash with cua bindings which
> probably makes the emacs bindings less wellknown.
>

I doubt it - despite having used VI for 15 years, I would still say that
vi's key bindings and different 'modes' are far more alien to a new user
than emacs' (and I realise that modern vi clones are more forgiving in
the sense you can use the arrow keys to move around while in insert mode
etc). 

I just think they are different animals. A version of vi is supposed to
be guaranteed to be available on any nix system, but emacs is not. Vi is
faster to start 'out of the box' and suits a mode of operation that
possibly seems more familiar e.g. start the editor, edit, exit the
editor etc. 

the other issue is that we are running very close to theorising about
the basis of different editor choices, which has to be the oldest
'religious war' in the tech world. We are never going to resolve or
really understand the reason for the differences. Of course, that
doesn't stop me from lining up with the emacs team at the next emacs v
vi pie throwing contest at the next Linux conference I go to (the last
one, some years back was a hel of a lot of fun - until it came to
packing my grotty clothes to go home that is!

Maybe we should move on to argue why windows is more popular than OSX or
Linux or why python is better than perl or why common lisp is better
than scheme or why .......

We will never get an answer to these questions, which doesn't mean they
shouldn't be considered - only that we shouldn't expect to reach
consensus or a good answer.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Jonathan Groll]

On Mon, Dec 15, 2008 at 02:19:00PM -0800, Drew Adams wrote:
>General lamentation about the relative popularity of Emacs wrt vi,
>TextPad, or
>anything else is what I don't understand.
>

Emacs is one of my favourite items of technology, software or
otherwise. 

For me personally, the sadness comes from realising that there are
many potential Emacs users who will never get to try out Emacs or give
it a full investigation, either because it is not available on default
installs, or because of anti-Emacs sentiment.

Vi/m and Emacs occupy different niches - I enjoy Emacs because it is
amodal, and also because it is after all the extensible text editor -
even a beginner user cannot avoid harnessing some elisp in their
.emacs. I can also see how Vi/m is appealing - the near-universal
availability, small foot print and control without modifier keys are
all attractive features. For many of us though, it makes little sense
to learn multiple editors.

Not sure where I am picking this up from and maybe it is only
persecution mentality, but it seems to me that in some quarters Emacs
has been perceived to be an item of hilarity only to be seriously used
by bearded software freedom types (judging by some recent comments I
have seen on IRC and heard on assorted podcasts - Lugradio I'm looking
at you), am I feeling overly persecuted or is that a sentiment others
are also experiencing? Even among geeks we get picked on!!! 

On the other hand, in recent times there have also been many positive
reviews of the new releases of Emacs, excellent Emacs screencasts, and
bloggers (such as Steve Yegge) have also been helping to introduce
users to Emacs, so it has not been all negative publicity. 

I personally don't care if Emacs is never the most popular editor on
the planet, but I do care that it is given a fair chance to be
evaluated on it's merit.

Cheers,
Jonathan.

RE: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Drew Adams]

> Not sure where I am picking this up from and maybe it is only
> persecution mentality, but it seems to me that in some quarters Emacs
> has been perceived to be an item of hilarity only to be seriously used
> by bearded software freedom types (judging by some recent comments I
> have seen on IRC and heard on assorted podcasts - Lugradio I'm looking
> at you), am I feeling overly persecuted or is that a sentiment others
> are also experiencing? Even among geeks we get picked on!!! 

Picked on? Yes, perhaps you do have a persecution problem. ;-)
Ah yes, the jungle of peer pressure - dur, dur pour les ados.
Don't worry; it will pass.

Sounds like a compliment, to me.
But then, I'm an unshaven antique entombed in hilarity.

> helping to introduce users to Emacs,
> so it has not been all negative publicity.

We need more negative publicity. Give us more.
Keeps out the bopper tourists.
 
> I personally don't care if Emacs is never the most popular editor on
> the planet, but I do care that it is given a fair chance to be
> evaluated on it's merit.

Trial by fire. Emacs to the rack. Let it suffer!
It deserves NO popularity. Free Emacs from the Popularistas!

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Sean Sieger]

"Drew Adams" <drew.adams@oracle.com> writes:

    It deserves NO popularity. Free Emacs from the Popularistas!

Right?  Emacs' appeal to the person who turned me onto it is the only
one that has ever had any bearing on me.  I'm glad he liked it.

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[David L]

On Mon, Dec 15, 2008 at 2:03 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> Sadly, vim outvotes all flavours of GNU emacs on the above graph when
>> added to it (although to be fair, on Debian emacs is not installed by
>> default but some flavour of vi is).
>
> Hm. Dunno why that should make one sad. I would never use vi or vim (unless I
> had to), but I don't see why I should be sad or bothered if other people find it
> useful. One person likes to live in the forest; another prefers the city; a
> third the shore.
>
> Why the need to make Emacs the most popular? It's good to make Emacs better, but
> what's the popularity contest about? Perhaps Americans on average listen to
> Britney Spears more than Mozart or Muddy Waters. So what?

A tool with a shrinking user base also has a shrinking pool of potential
developers that will continue to make it better.  Fewer developers to
make it better will make it less competitive with other tools causing it to
lose more users.  And so on.  There are also fewer people to file
bug reports and help other users with problems.

Another reason that is would be nice if it was growing in popularity
is to give people like me some ammunition when many people
in my company are saying emacs is obsolete and I should start using eclipse.
There is something to be said for standardizing tools within a company...
I always get frustrated when I sit down with somebody to help them debug
something and don't know my way around eclipse and I know they feel
the same with emacs.  If a company forces developers to use a certain
tool or a few more popular tools (which many companies do), it's
like people are forced to listen to Britney Spears (to use your
analogy).

RE: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Drew Adams]

> >> Sadly, vim outvotes all flavours of GNU emacs on the above 
> >> graph when added to it (although to be fair, on Debian emacs
> >> is not installed by default but some flavour of vi is).
> >
> > Hm. Dunno why that should make one sad. I would never use 
> > vi or vim (unless I had to), but I don't see why I should be
> > sad or bothered if other people find it useful. One person
> > likes to live in the forest; another prefers the city; a
> > third the shore.
> >
> > Why the need to make Emacs the most popular? It's good to 
> > make Emacs better, but what's the popularity contest about?
> > Perhaps Americans on average listen to
> > Britney Spears more than Mozart or Muddy Waters. So what?
> 
> A tool with a shrinking user base also has a shrinking pool 
> of potential developers that will continue to make it better.
> Fewer developers to make it better will make it less competitive
> with other tools causing it to lose more users.  And so on.
> There are also fewer people to file
> bug reports and help other users with problems.

You miss the point. No one has argued that Emacs should be unpopular or that
unpopularity is better than popularity. No one has said that having fewer users
and developers is better than having more.

I said "Why the need to make Emacs _the most_ popular?". And I argued against
chasing popularity for its own sake, as opposed to trying to improve Emacs - a
difference in aim.

> Another reason that is would be nice if it was growing in popularity
> is to give people like me some ammunition when many people
> in my company are saying emacs is obsolete and I should start 
> using eclipse.

Let them use Eclipse. Learn from Eclipse. Improve Emacs using Eclipse as
inspiration, if that's appropriate.

If you want to help people learn how Emacs can help them, then show them (and
argue from) the specific merits of Emacs. Show and describe Emacs features.
Don't try to sell them on Emacs because it is the most popular.

Trying to persuade others to use Emacs because of its relative popularity is a
misguided approach. I don't know many good developers who would be persuaded to
use a tool just because of its popularity. Talk to them about features, not
popularity.

And when you try to argue from its merits (features), you will no doubt discover
lacunae - things the Emacs doesn't do so well out of the box. Learning that is
the first step to improving Emacs. Argument in favor of Emacs based only on
popularity will teach you nothing about how to improve it. The devil is in the
details.

> There is something to be said for standardizing tools within 
> a company. 

Is there? Depends what you mean. If you mean standards, yes. If you mean how
tools interface, yes.

But if you mean which tools an individual uses to accomplish tasks such as
editing, email, etc., then no, I'm not convinced.

The company I work for, which is quite large and has (and produces) tools and
products that interface with lots of different standards and lots of other tools
and products, does not, in general, impose specific tools for individual use by
its developers or other employees. Some platforms and tools are more readily
available than others, and employees generally do not have a choice wrt some of
the servers (e.g. mail) they interact with, but in general nothing prevents them
from using the individual (e.g. client) tools they want.

This can be a hassle for the IT department, which tries to help employees with
their multiple browsers, mail clients, editors, ftp clients, and so on. If you
choose to use something that is not "supported", then you don't get much support
from IT, of course. But there is no pressure to use only the tools that are
supported or are provided by default.

And I don't think that's a problem, in general. In fact, I think it is a benefit
overall. We learn from each other. We compare features (not popularity). We pick
and choose what we use based on our different professional needs, individual
preferences, and knowledge of what's available and how to install it. There is
no Central Tools Department that makes all of our tools choices for us.

Looking around me, I see developers using Emacs, vi, Eclipse, various editors
and IDEs made by the company itself, and many other tools. It's not unusual to
see the same developer use both vi and Emacs, and be proficient at both.
Likewise, for office workers - they use a mix of tools. People are different;
their tasks, goals, and styles are different; the tools they use are different.

> I always get frustrated when I sit down with somebody to help them debug 
> something and don't know my way around eclipse and I know they feel
> the same with emacs.

So learn to use Eclipse. Do you need Emacs to be _the most popular_ just so you
don't need to learn Eclipse? 

If you really want to help Emacs, then learn Eclipse and improve Emacs by adding
some of the features that only Eclipse has. That will help Emacs more than
trying to convince someone to give up Eclipse because Emacs is more popular.

> If a company forces developers to use a certain
> tool or a few more popular tools (which many companies do), it's
> like people are forced to listen to Britney Spears (to use your
> analogy).

Uh, and that's a good thing? Are you arguing for 100 flowers or for a monocrop?
Are you arguing to replace all-Eclipse by all-Emacs (to simplify the argument)?
Or are you arguing to let people use whatever they want?

I say let people choose (let 'em choose Britney, if they want). Let there be
competition among tools, yes, in the sense of learning helpful features from the
other. But forget about competition to win the popularity contest - that's a
dead end.

If you're an Emacs lover, then it's about improving Emacs. If you're an Eclipse
lover, then it's about improving Eclipse. (And I assume that one can be both.)
Improvement, not popularity.

The Emacs or the Eclipse that you use ten years from now will have been improved
by people who enabled it to do some of the things that only Eclipse or only
Emacs, respectively, does today. I'm willing to bet that neither will win the
popularity contest and eliminate the other. Likewise, vi or TextMate or any
other editor or programming environment.

Those tools that have a user base ten years from now will be those that people
find useful, not necessarily those that are most popular today. And Emacs will
be among them, I am sure. The greatest strength of Emacs is its extensibility,
even by ordinary end users. If any tool can be improved and adopt (and adapt)
good features from other tools, it is Emacs.

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[David L]

On Thu, Dec 18, 2008 at 9:50 AM, Drew Adams <drew.adams@oracle.com> wrote:
<snip>
>> > Why the need to make Emacs the most popular? It's good to
>> > make Emacs better, but what's the popularity contest about?
>> > Perhaps Americans on average listen to
>> > Britney Spears more than Mozart or Muddy Waters. So what?
>>
>> A tool with a shrinking user base also has a shrinking pool
>> of potential developers that will continue to make it better.
>> Fewer developers to make it better will make it less competitive
>> with other tools causing it to lose more users.  And so on.
>> There are also fewer people to file
>> bug reports and help other users with problems.
>
> You miss the point. No one has argued that Emacs should be unpopular or that
> unpopularity is better than popularity. No one has said that having fewer users
> and developers is better than having more.
>
> I said "Why the need to make Emacs _the most_ popular?". And I argued against
> chasing popularity for its own sake, as opposed to trying to improve Emacs - a
> difference in aim.

I agree, it doesn't need to be the "most popular" as a goal in itself.
But if the reason that it is not the most popular is usability, features,
and bugs (as opposed to a different target audience or different
goals), then that is a problem.  I'm not saying that is necessarily the
case, but it is the reason given by new developers at my company
for not adopting it despite tutorials on its use.

Obviously, emacs primary goal is not to be an IDE
but it does have a lot of great features as an editor and I like using
it as an IDE more than any other that I've tried including eclipse and
kdevelop.  But that's because the the editor is very good and the
other IDE features are marginally good enough or I don't care about
them.  Other people at my company care more about things like
ECB features (which isn't even part of the standard emacs) than
I do, and I have to admit that I would probably bail on emacs too
if I cared more about ECB, completion, etc.


>
>> Another reason that is would be nice if it was growing in popularity
>> is to give people like me some ammunition when many people
>> in my company are saying emacs is obsolete and I should start
>> using eclipse.
>
> Let them use Eclipse. Learn from Eclipse. Improve Emacs using Eclipse as
> inspiration, if that's appropriate.
>
> If you want to help people learn how Emacs can help them, then show them (and
> argue from) the specific merits of Emacs. Show and describe Emacs features.
> Don't try to sell them on Emacs because it is the most popular.
>
I tried... they found ECB inadequate and difficult to set up and use
and the gdb interface buggy (I should mention at this point that
I believe the emacs gdb guy is one of the most responsive
open source developers I've ever dealt with, so this should in
no way be taken to reflect negatively on him).

> Trying to persuade others to use Emacs because of its relative popularity is a
> misguided approach. I don't know many good developers who would be persuaded to
> use a tool just because of its popularity. Talk to them about features, not
> popularity.
I'm not trying to persuade them to use it based on its popularity.
I'm trying to justify my continued use of it despite poor competitiveness
as an IDE.  Basically they don't care about the things that I really like
about emacs and I am willing to live with its shortcomings as an
IDE whereas they are not.

But I do think it is fair for a company to require proficiency in one
or two of the more popular tools.  It means a higher chance that
new hires will already have experience with the tools and a
broader base of users to ask for help and developers to improve
it.


>
>> There is something to be said for standardizing tools within
>> a company.
>
> Is there? Depends what you mean. If you mean standards, yes. If you mean how
> tools interface, yes.
>
> But if you mean which tools an individual uses to accomplish tasks such as
> editing, email, etc., then no, I'm not convinced.
>
Look, I had this same argument with my management, and I was
on your side.  But they had some good points.  Training and support
for tools costs time and money.  If I have a problem with a tool,
it's nice if IT or somebody can help me.

>
>> I always get frustrated when I sit down with somebody to help them debug
>> something and don't know my way around eclipse and I know they feel
>> the same with emacs.
>
> So learn to use Eclipse. Do you need Emacs to be _the most popular_ just so you
> don't need to learn Eclipse?

I think eclipse sucks.  It does't make sense for me to learn it for the 5% of
my time that I spend working with other people.  And because I am very
productive at writing and debugging code, there is no serious pressure
for me to learn eclipse (yet).

>> If a company forces developers to use a certain
>> tool or a few more popular tools (which many companies do), it's
>> like people are forced to listen to Britney Spears (to use your
>> analogy).
>
> Uh, and that's a good thing?
No, that's a horrible thing.  But it happens.

> If you're an Emacs lover, then it's about improving Emacs. If you're an Eclipse
> lover, then it's about improving Eclipse. (And I assume that one can be both.)
> Improvement, not popularity.
Open source software is different than your music analogy.  Popularity
tends to help to improve open source software.  There is a positive
feedback loop between popularity and improvement... there are other
effects that can dampen this feedback, so it's not the only factor.
Popularity for the sake of popularity is bad, but prioritizing features and
bugs that are contributing to reduced popularity might improve
emacs faster.

Cheers...

         David

PS - Does emacs have a feature request and bug reporting system
like bugzilla yet?  I heard rumors that it might be getting one.  With
respect to this discussion, it would be nice if when emacs chokes
during a demonstration of its features, I could point to the bugzilla
page that shows the problem has been reported and is being
worked on and is a blocker for the release of version x.y which
is scheduled to be release on such and such a date.

RE: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Drew Adams]

<snip>

We agree that it would be good if Emacs were improved in some of the areas you
mentioned.

> PS - Does emacs have a feature request and bug reporting system
> like bugzilla yet?  I heard rumors that it might be getting one.  With
> respect to this discussion, it would be nice if when emacs chokes
> during a demonstration of its features, I could point to the bugzilla
> page that shows the problem has been reported and is being
> worked on

Yes, there is a bug and enhancement-request reporting system, of sorts.

You can file a bug using `M-x report-emacs-bug' or (menu) Help > Send Bug
Report.
The Emacs manual (`C-h r'), node `Bugs'.

You can examine existing bug reports and their status at the bug-report Web
site:
http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacs

This system is what it is. If you have suggestions for improving it, I believe
that the contact mail address for that is bug-gnu-emacs@gnu.org.

> and is a blocker for the release of version x.y which
> is scheduled to be release on such and such a date.

You can see the assessed severity of reported bugs. But Emacs releases under
development generally do not have a planned release date until late in the
development cycle.

I'm not an authority on this - someone please correct me if some of the above
info is not correct.

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Sean Sieger]

    A tool with a shrinking user base also has a shrinking pool of potential
    developers that will continue to make it better.  Fewer developers to
    make it better will make it less competitive with other tools causing it to
    lose more users.  And so on.  There are also fewer people to file
    bug reports and help other users with problems.

I'm a craftsman by trade and um---the tool thing jumped out at me
here---I gotta tell ya, people that use a tool that use developed, not a
tool that someone just picked up ... and changed.

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Tim X]

"Drew Adams" <drew.adams@oracle.com> writes:

>> Sadly, vim outvotes all flavours of GNU emacs on the above graph when
>> added to it (although to be fair, on Debian emacs is not installed by
>> default but some flavour of vi is).
>
> Hm. Dunno why that should make one sad. I would never use vi or vim (unless I
> had to), but I don't see why I should be sad or bothered if other people find it
> useful. One person likes to live in the forest; another prefers the city; a
> third the shore.
>
> Why the need to make Emacs the most popular? It's good to make Emacs better, but
> what's the popularity contest about? Perhaps Americans on average listen to
> Britney Spears more than Mozart or Muddy Waters. So what?
>
> On the other hand, info about the relative use of different Emacs versions is
> (mildly) interesting and might be helpful in some ways.
>

Well said Drew. Agree 100%

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Richard Riley]

Tim X <timx@nospam.dev.null> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>>> Sadly, vim outvotes all flavours of GNU emacs on the above graph when
>>> added to it (although to be fair, on Debian emacs is not installed by
>>> default but some flavour of vi is).
>>
>> Hm. Dunno why that should make one sad. I would never use vi or vim (unless I
>> had to), but I don't see why I should be sad or bothered if other people find it
>> useful. One person likes to live in the forest; another prefers the city; a
>> third the shore.
>>
>> Why the need to make Emacs the most popular? It's good to make Emacs better, but
>> what's the popularity contest about? Perhaps Americans on average listen to
>> Britney Spears more than Mozart or Muddy Waters. So what?
>>
>> On the other hand, info about the relative use of different Emacs versions is
>> (mildly) interesting and might be helpful in some ways.
>>
>
> Well said Drew. Agree 100%
>
> Tim

There seems to be a tendency in emacs circles to take any suggestion
which might make emacs more popular as some sort of push to make it for
thickies or dumb it down. The Britney v Mozart rebuttal is a worn old
war horse wheeled out frequently in such arguments :-;

Making something more widely used can only benefit the whole
community. People did not put man years into it for a small few. People
like their work to be used.

So personally, I *do* care if I think emacs is losing share. If it is
then something is wrong and people should consider ways of addressing
it. The "I dont care as it works for me" attitude is somewhat anti the
whole Open and Free movement IMO.


-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

RE: Emacs's popularity (was: Distributed Maintenance for Emacs)

[Drew Adams]

> >>> Sadly, vim outvotes all flavours of GNU emacs
> >>
> >> Hm. Dunno why that should make one sad. I would never use 
> >> vi or vim (unless I had to), but I don't see why I should
> >> be sad or bothered if other people find it useful. One
> >> person likes to live in the forest; another prefers the city;
> >> a third the shore.
> >>
> >> Why the need to make Emacs the most popular? It's good to 
> >> make Emacs better, but what's the popularity contest about?
> >> Perhaps Americans on average listen to Britney Spears more
> >> than Mozart or Muddy Waters. So what?
> >>
> >> On the other hand, info about the relative use of different
> >> Emacs versions is (mildly) interesting and might be helpful
> >> in some ways.
> >
> > Well said Drew. Agree 100%
> 
> There seems to be a tendency in emacs circles to take any suggestion
> which might make emacs more popular

No, not any suggestion that might make Emacs more popular. Suggestions TO make
Emacs popular. That's the difference. Improving Emacs might make it more popular
(or not!). No one has ridiculed suggestions for improvements.

It is the argument that Emacs _needs to win_ a popularity contest that I
contest. It is the goal TO make Emacs more popular than its "competitors" that I
think is misguided.

There is nothing wrong with some people using and prefering vi (or Eclipse or
whatever). Nothing. And nothing wrong if there are more of them than people
using Emacs. And nothing wrong if the ratio vi/emacs increases. The fact that
some people use vi is no reason to "modernize" Emacs by blindly copying vi (or
whatever else).

Each improvement to Emacs should be argued on its own merits, not simply by
pointing to what the others kids have. And as I said, it's always good to learn
from others. There is no contradiction here. Learning can mean copying, but it
does not necessarily mean copying. And seldom does just copying the popular kid
make you popular. The devil is in the details.

> as some sort of push to make it for thickies or dumb it down.

No one said that people who use other tools are thick or dumb. I don't think
that at all. I have a great deal of respect for those I know who can make fine
music with vi. The beauty and utility of an instrument (musical or other) is not
measured by its popularity. Violins and clarinets are not in competition.

> The Britney v Mozart rebuttal is a worn old
> war horse wheeled out frequently in such arguments :-;

Gosh, and I thought it was original. Funny how those old brains keep repeating
stuff.

How about Muddy Waters - is he wheeled out often? I'll have to modernize my
metaphors I guess. Which metaphors are the TextMate (vi? Eclipse?) proponents
using these days?

> Making something more widely used

Use how, why, by whom, for what? Making it so in what ways?

> can only benefit the whole community.

What community?

> People did not put man years into it for a small few. People
> like their work to be used.

Those who worked and played hard to make Emacs better did not do so to make it
popular, no matter how much they like their work to be used. They did so because
better is better, more helpful, more useful. I'm pretty sure of that
generalization, though I won't look to offer you proof.

When you add or remove a feature to improve Emacs for yourself and others, do
you think about making it more popular than vi (or Eclipse)? I doubt it. You
might be proud that your new Emacs feature is more useful in some way than vi,
but did you set out to make a vi-killer? I doubt it.

> So personally, I *do* care if I think emacs is losing share.

Why? Your argument above was for increasing popularity in absolute terms. But
your conclusion ("so") is in relative terms - it doesn't follow. Even if you
want more people to use Emacs, why do you care about _relative_ pie-slice size?
Grow the pie, if you are worried about growth in the Emacs user base.

Personally, I don't worry about either the absolute or the relative popularity
of Emacs. Couldn't care less. When I see a colleague try to use other tools to
do something s?he could do easier or better with Emacs, I steer the poor soul in
the Emacs direction. But _to help someone_, not to win market share for the
Emacs team.

Improving a product is about improving it, not about aiming to capture the whole
pie. It's true that in the business world market share can be important and even
become an end in itself, because of competition (survival) and the potential
perks of eliminating competition. That does not apply to Emacs, IMO. It does not
apply, in any case, to why I try to improve Emacs.

Emacs "losing share" is truly the least of our worries. Totally a dead end, IMO.

> If it is then something is wrong and people should consider ways of
> addressing it. The "I dont care as it works for me" attitude is somewhat
> anti the whole Open and Free movement IMO.

Why? You seem to be confusing several things. An Emacs "competitor" (e.g. vi)
could be free or not.

In any case, no one is arguing that Emacs should not be improved because it
already "works for me". Improve, improve; please improve.

But fuggedabowd popularity. Or not. I would even go so far as to say that if you
really want Emacs to win your popularity contest, then do _not_ aim for
popularity. Aim for improvement. And argue for particular improvements that you
endorse on their own merits - the-other-kids-all-have-one is not convincing.

Re: Emacs's popularity

[Teemu Likonen]

> [1] http://popcon.debian.org/

I should probably mention that Debian popularity contest is an automatic
system. Debian's installer asks whether user wants participate, and if
yes, it install package named popularity-contest. (Of course it can be
installed later too.) This package reports every week about installed
and used packages in the system.

Re: Emacs's popularity

[Giorgos Keramidas]

On Mon, 15 Dec 2008 19:31:21 GMT, Teemu Likonen <tlikonen@iki.fi> wrote:
> Are people being scared off in the first place? I mean more than
> normally. :-)
>
> I don't know but at least among Debian GNU/Linux users Emacs's
> popularity doesn't seem to have decreased. Here's a Debian popularity
> contest[1] graph that shows the popularity of packages emacs21,
> emacs21-nox, emacs22, emacs22-nox and emacs22-gtk:
>
>     http://preview.tinyurl.com/55stry [2]
>
> The graph shows that Emacs22 started gaining popularity around mid-2007
> (the release) and Emacs21 started losing it. Those summed together Emacs
> is no less popular than before. The latest official Debian release (4.0
> "Etch") includes Emacs21.
>
> This popularity measurement category is called "vote". It means that
> user has accessed (atime) the files in the package within 30 days. It
> roughly means that the software is actually being used, not only
> installed.

Or being regularly copied to a backup medium (unless Debian takes
explicit measures to avoid messing up with the atime when a backup
program iterates over the filesystem).

Nice graphs though :-)

Re: Distributed Maintenance for Emacs (was: is there summary of template systems for emacs?)

[Richard Riley]

Leo <sdl.web@gmail.com> writes:

> On 2008-12-14 21:37 +0000, Xah Lee wrote:
>> I really feel sorry emacs's user base is dying. The most important
>> thing i think is to get emacs to use modern terminologies and be
>> compatible with the minimum of standard modern UI.
>
> Users are not scared off by Emacs's UI. It is more important its
> functionality.

That is incredibly naive and not a little wrong in my humble opinion.

Many users are scared off by the UI.  The UI is not for the faint
hearted.  What must be accepted is that to gain the benefits then one
has to earn the skills to access those benefits.

>
> And in order to boost its functionality a few orders more and better, it
> needs a good development model, a model that supports *DISTRIBUTED*
> maintenance.

Its current functionality would appear to be at odds with your
views. Not that the current maintenance structure could not be
improved. What can not be improved after all?


-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

RE: is there summary of template systems for emacs?

[Drew Adams]

> Anyway, i've followed Drew's advice and cleaned up the emacswiki a bit
> based on what i've studied.
> http://www.emacswiki.org/emacs/CategoryTemplates

Thanks.

I encourage anyone who has Emacs help posted on sites other than Emacs Wiki to
also add pointers to that help from Emacs Wiki. That way, people looking for
help on the wiki will find your help. Best is to provide a short, specific
summary or description on the wiki, along with the link to the corresponding
help on your site. Conversely, if there is related help on the wiki, you might
want to point to it from your site.