Efforts to attract more users?

Efforts to attract more users?

[Ken Hori]

I'm not sure if Emacs is attracting new users the way it used to be.
Certainly search volume has been going downhill for more than several years
(http://www.google.com/trends?q=emacs), and yet I don't hear this issue being
addressed here strongly enough.  I hate to ask pedestrian sort of a question
like this, but are there any efforts specifically to attract more users?

Thanks.

Re: Efforts to attract more users?

[joakim]

Ken Hori <fplemma@gmail.com> writes:

> I'm not sure if Emacs is attracting new users the way it used to be.
> Certainly search volume has been going downhill for more than several years
> (http://www.google.com/trends?q=emacs), and yet I don't hear this issue being
> addressed here strongly enough.  I hate to ask pedestrian sort of a question
> like this, but are there any efforts specifically to attract more users?
>
> Thanks.

I dont know of any organized effort.

I do try to attract people to Emacs and free software myself.

I mostly work with developers that use a windoze desktop, Eclipse, and
some secondary simpler editor. In recent years getting people interested
in Emacs has been difficult, I can only recall about one or two people I
helped getting started with Emacs the last 3 years.

I also try to help improve technical things developers used to an IDE
find lacking in Emacs. CEDET being included in Emacs was a step in the
right direction.

I think Emacs has a lot of potential to attract new users, especially if
we put more effort into polishing some user interface aspects.

For instance I have observed the following usage pattern with developers
using Eclipse:

"Hmm, I want to diff a file in my project. I don't want to read a boring
manual. Lets fiddle around in the menus until I find a suitable Wizard
that does it for me"

Emacs could quite possibly do the same thing better than Eclipse, but
the same developer trying the same approach in Emacs would probably get
stumped.

I would like to emphasize that I don't think Emacs should do things the
same way Eclipse does them, we need to find Emacsy ways. Perhaps by
improving the Emacs documentation so it is a more obvious entry point
rather than clicking about in menus. Perhaps the info documentation
could be enhanced so it works more like the web, with improved search
facilities, support for Wizards in the info documentation, etc.


-- 
Joakim Verona

Re: Efforts to attract more users?

[Adrian Robert]

 <joakim <at> verona.se> writes:


> I would like to emphasize that I don't think Emacs should do things the
> same way Eclipse does them, we need to find Emacsy ways. Perhaps by
> improving the Emacs documentation so it is a more obvious entry point
> rather than clicking about in menus. Perhaps the info documentation
> could be enhanced so it works more like the web, with improved search
> facilities, support for Wizards in the info documentation, etc.

It's hard to say.  I see lots of developers even using Eclipse in completely
non-optimal ways, because there seems to be some kind of bias towards using
mouse and on-the-screen display elements for tasks.  For example, laboriously
navigating a large class hierarchy using the tree display on the left to find a
class they know they name of, rather than just invoking "Find Resource" whether
by keystroke or menu.  Even developers that know about the command still persist
in this.  What is it?  Habit, bias away from the keyboard?

Whatever it is, just adding eye candy or wizards to emacs won't change its
nature as a keyboard-oriented editing system, and add-ons like JDEE and ECB,
great as they are, are never going to match what a widget-oriented system like
Eclipse provides.

For that matter, why is VIM popular?  I've never seen how the weird,
line-oriented, moded editing style has anything to compare in ease of use or
simplicitly to learn with emacs, yet developer after developer uses it as their
"second choice or remote" editor -- while considering emacs "too hard" or "too
complicated".  (?)

I do think the basic mouse and selection interaction there is in emacs needs to
continue to be brought more in line with other other apps.  The little things,
getting default line and word-wrapping modes right, enabling forward delete by
default for delete key, etc..  Maybe some kind of reasonable default right-click
menus (based on mode of course).


-Adrian

Re: Efforts to attract more users?

[Stephen J. Turnbull]

Adrian Robert writes:

 > For that matter, why is VIM popular?  I've never seen how the
 > weird, line-oriented, moded editing style has anything to compare
 > in ease of use or simplicitly to learn with emacs, yet developer
 > after developer uses it as their "second choice or remote" editor
 > -- while considering emacs "too hard" or "too complicated".  (?)

I've never heard "too hard" or "too complicated".  What I hear a lot
is that Emacsen take too long to start, or at least they did when
those guys started using vi(m).  OTOH, most of the folks I know who
use vi don't use vim, they use nvi or elvis or something like that.

The other thing a lot of people complain about is Emacs regexps (why,
I'm not sure, they're mostly the same as vim's!), and the fact that
there's no regexp search on a short key sequence.  Yes, I know about
C-u C-s; the point is that they don't find out until well after
they've chosen a different editor.

I think an incremental re-search with pcre would be a killer feature
for newbies, but what do I know? ;-)

Re: Efforts to attract more users?

[Stuart Hacking]

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

On 8 July 2010 15:26, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
> ,,,and the fact that there's no regexp search on a short key sequence.
>  Yes, I know about
> C-u C-s; the point is that they don't find out until well after
> they've chosen a different editor.
>

Is there any reason why we can't make C-s and C-r use the regexp
equivalents? I've been doing this for some time. Performance is fine and for
most strings behaviour is the same as string search. (unless you frequently
search for periods or pluses I guess.)

When I first tried the incremental regexp search, I thought it was pretty
neat that emacs highlighted the subsequent matches in addition to the
current. I'm not sure I could name another editor that does that.

-- Stuart

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

Re: Efforts to attract more users?

[Richard Stallman]

    Is there any reason why we can't make C-s and C-r use the regexp
    equivalents?

I would not like having to use regexp search by default.
I'd rather leave that on C-M-s.

Re: Efforts to attract more users?

[Christoph]

On 7/9/2010 3:46 PM, Richard Stallman wrote:
>      Is there any reason why we can't make C-s and C-r use the regexp
>      equivalents?
>
> I would not like having to use regexp search by default.
> I'd rather leave that on C-M-s.
>

Is there anything that search can do that regular expression search 
can't? Would anyone who is not familiar with regexp search even notice a 
difference?

Christoph

Re: Efforts to attract more users?

[Chong Yidong]

Christoph <cschol2112@googlemail.com> writes:

> Is there anything that search can do that regular expression search
> can't?

Search for punctuation without quoting.

Re: Efforts to attract more users?

[Richard Stallman]

Many characters are special in regexps.  I want no difficulties when
I search for characters such as [ or *.

Re: Efforts to attract more users?

[Christoph]

On 07/10/2010 08:51 AM, Richard Stallman wrote:
> Many characters are special in regexps.  I want no difficulties when
> I search for characters such as [ or *.

OK. That makes sense.

Re: Efforts to attract more users?

[Teemu Likonen]

* 2010-07-08 23:26 (+0900), Stephen J. Turnbull wrote:

> The other thing a lot of people complain about is Emacs regexps (why,
> I'm not sure, they're mostly the same as vim's!), [...]

Vim's regular expressions are more powerful than Emacs's.

    http://vimdoc.sourceforge.net/htmldoc/pattern.html#pattern-multi-items

Emacs's syntax (\s \S) and character (\c \C) classes are better than
anything but otherwise Vim has a lot more matcher atoms.

Re: Efforts to attract more users?

[Stuart Hacking]

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

On 8 July 2010 08:44, <joakim@verona.se> wrote:
>
> I dont know of any organized effort.
>
> I do try to attract people to Emacs and free software myself.
>

 I think Emacs becomes very alluring when someone gets stuck on a laborious
piece of text processing or searching. I've introduced a couple of people in
work to it simply by virtue of regexp incremental search and keyboard
macros. Now they're converts.

I mostly work with developers that use a windoze desktop, Eclipse, and
> some secondary simpler editor. In recent years getting people interested
> in Emacs has been difficult, I can only recall about one or two people I
> helped getting started with Emacs the last 3 years.
>

It's hard to come up with persuasive arguments for emacs in the face of
shiny new development environments. I suppose things like drag and drop
refactoring and graphical editors (property lists, forms, tree based xml)
are popular. Is this a by product of Eclipse being quite difficult and
cumbersome when you try to search for something?

At home I use Emacs and JDE with Tags. In work I use Eclipse because it's
the done thing. I often find myself copying large chunks of text into emacs
to work with, then copying them back.

As I mentioned, Emacs earns its stripes when people discover the joys of
automating away the drudgery and then explore the other things they can do.
Whenever I mention emacs to anyone though, I'm met with either a blank stare
or "Hah, Emacs. Nice operating system, shame about the editor.", "Emacs?
Eight megs and constantly swapping!"

Just try it, friend. It's eight megs well spent.

--Stuart

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

Re: Efforts to attract more users?

[Richard Stallman]

The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
them, but maybe we still lack some.

I saw it once, and it used tabs a lot for switching between different views.
We need to be able to do that too.

Also, one advantage of Eclipse's GUI interface is that it shows you a
lot of features when they might be useful.  So you don't have as much
to learn and remember.

Re: Efforts to attract more users?

[Bernardo Barros]

2010/7/9 Richard Stallman <rms@gnu.org>:
> I saw it once, and it used tabs a lot for switching between different views.
> We need to be able to do that too.

Hi, Richard. Aquamacs-Emacs implemented tabs too. Just like Firefox and Eclipse.

Re: Efforts to attract more users?

[Stephen Eilert]

On Fri, Jul 9, 2010 at 12:24 AM, Bernardo Barros
<bernardobarros2@gmail.com> wrote:
> 2010/7/9 Richard Stallman <rms@gnu.org>:
>> I saw it once, and it used tabs a lot for switching between different views.
>> We need to be able to do that too.
>
> Hi, Richard. Aquamacs-Emacs implemented tabs too. Just like Firefox and Eclipse.
>
>

Not exactly.

I think that Richard is actually refering to "perspectives". A
"perspective" in Eclipse is actually a collection of windows (using
Emacs terminology). For instance, one can have a Java perspective,
with a big editing window in the middle, a class tree on the left,
class symbols on the right and a console on the bottom of the screen.
And then a "Debug perspective", with the stack trace on top left,
variables top right, editing in the center, and whatever else the user
wants to display.

You can do that in Aquamacs, if you take the time to configure it,
splitting and switching to the desired buffers, for each tab. Just to
lose it when Emacs close (mitigated by desktop-save) or when something
switches one of the buffers you have painstakingly configured.

In Eclipse, you can hide the frames temporarily, resize them, add or
remove, or maximize the editing window. But usually you do not want to
mess with them, as they contain useful information and are sort of
"persistent".

There are also per-file tabs, but these should  be (and are, in
Eclipse) distinct from the perspectives. Using Aquamacs' approach the
two are mixed, so one would spend quite a lot of time fighting the
interface.

I seem to recall a discussion a while ago about "persistent windows".
That, along with tabs, would duplicate Eclipse's perspectives quite
nicely.

What prevents people I know from switching to Emacs is that Emacs has
no notion of "projects", and operations affecting files in a given
project. While I think Eclipse's approach to be overkill, the way
Textmate does it appears to be enough.


--Stephen

Sent from my Emacs

Re: Efforts to attract more users?

[Rolando Pereira]

Stephen Eilert <spedrosa@gmail.com> writes:

> On Fri, Jul 9, 2010 at 12:24 AM, Bernardo Barros
> <bernardobarros2@gmail.com> wrote:
>> 2010/7/9 Richard Stallman <rms@gnu.org>:
>>> I saw it once, and it used tabs a lot for switching between
>>> different views.  We need to be able to do that too.
>>
>> Hi, Richard. Aquamacs-Emacs implemented tabs too. Just like Firefox
>> and Eclipse.
>>
>
> Not exactly.
>
> I think that Richard is actually refering to "perspectives". A
> "perspective" in Eclipse is actually a collection of windows (using
> Emacs terminology). For instance, one can have a Java perspective,
> with a big editing window in the middle, a class tree on the left,
> class symbols on the right and a console on the bottom of the screen.
> And then a "Debug perspective", with the stack trace on top left,
> variables top right, editing in the center, and whatever else the user
> wants to display.
>
> You can do that in Aquamacs, if you take the time to configure it,
> splitting and switching to the desired buffers, for each tab. Just to
> lose it when Emacs close (mitigated by desktop-save) or when something
> switches one of the buffers you have painstakingly configured.
>

Couldn't Emacs simulate that using something like escreen[1] or
elscreen[2]?

Or maybe with the window-configuration-to-register and jump-to-register
functions.

I'm not sure how those options could be presented the user. Perhaps in a
dropdown menu labeled "Perspectives".

Although the use of registers would require, I think (since I'm not
familiar with the code base), all buffers used on the perspectives to be
created at startup, which would probably increase a lot the startup
time, especially if there is a great number of perspectives.


[1] http://www.emacswiki.org/emacs/EmacsScreen
[2] http://www.emacswiki.org/emacs/EmacsLispScreen

Re: Efforts to attract more users?

[Aneesh Kumar K. V]

On Thu, 08 Jul 2010 23:05:31 -0400, Richard Stallman <rms@gnu.org> wrote:
> The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
> them, but maybe we still lack some.
> 
> I saw it once, and it used tabs a lot for switching between different views.
> We need to be able to do that too.
> 
> Also, one advantage of Eclipse's GUI interface is that it shows you a
> lot of features when they might be useful.  So you don't have as much
> to learn and remember.

Rather than features one of important thing to "fix" would be to make
CEDET faster. Pushing some of CEDET related task to thread (when
threading becomes available) or converting some of the performance
sensitive code to C and call them from emacs would be a solution. Right
now with CEDET enabled, it gets in the way of normal editing. I have to
explicitly set semantic-idle-scheduler-idle-time to a higher value to
prevent idle scheduler from kicking in early. 

-aneesh

Re: Efforts to attract more users?

[Lennart Borgman]

On Fri, Jul 9, 2010 at 9:26 AM, Aneesh Kumar K. V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
>
> Rather than features one of important thing to "fix" would be to make
> CEDET faster. Pushing some of CEDET related task to thread (when
> threading becomes available) or converting some of the performance
> sensitive code to C and call them from emacs would be a solution. Right
> now with CEDET enabled, it gets in the way of normal editing. I have to
> explicitly set semantic-idle-scheduler-idle-time to a higher value to
> prevent idle scheduler from kicking in early.

Maybe threads are very important then?

Re: Efforts to attract more users?

[christian.lynbech]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

Richard> ... it used tabs a lot for switching between different views.

This is probably one (among several) key issue.

I use frames quite a lot to separate different contexts (one 'main'
frame, one for shell, one news/mail, one for web, etc.) but sometimes it
feels a little that I am fighting emacs over this. Without having any
firm evidence, I am prepared to believe that it is not immediate obvious
to newcomers how to do a multiframe setup (or otherwise separate contexts).

One thing I have noted with people using vi/vim is that they tend to
have multiple vim instances in different xterms. It is surprisingly (at
least to me) hard to teach them to open only one emacs instance and
fetch files into that rather than trying to do it the vim way where you
start a new emacs for each new file you want to work on. If that is one's
mode of operation I have no problem understanding why emacs feels
awkward.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Efforts to attract more users?

[Lennart Borgman]

On Fri, Jul 9, 2010 at 9:31 AM,  <christian.lynbech@tieto.com> wrote:
>
> One thing I have noted with people using vi/vim is that they tend to
> have multiple vim instances in different xterms. It is surprisingly (at
> least to me) hard to teach them to open only one emacs instance and
> fetch files into that rather than trying to do it the vim way where you
> start a new emacs for each new file you want to work on. If that is one's
> mode of operation I have no problem understanding why emacs feels
> awkward.

I am sure it is part of the problem. And the reason for it is IMO
partly that emacs client does not start Emacs by default. (It does in
the patched version of Emacs+EmacsW32 however.)

Re: Efforts to attract more users?

[Juanma Barranquero]

On Fri, Jul 9, 2010 at 13:04, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> And the reason for it is IMO
> partly that emacs client does not start Emacs by default. (It does in
> the patched version of Emacs+EmacsW32 however.)

You could send patches for the standard Emacs...

Hey! Didn't we have this conversation (a few times) before? :-)

    Juanma

Re: Efforts to attract more users?

[Lennart Borgman]

On Fri, Jul 9, 2010 at 1:24 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Jul 9, 2010 at 13:04, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>> And the reason for it is IMO
>> partly that emacs client does not start Emacs by default. (It does in
>> the patched version of Emacs+EmacsW32 however.)
>
> You could send patches for the standard Emacs...
>
> Hey! Didn't we have this conversation (a few times) before? :-)

Yes, I know. Some things here has taken much more time than I wanted
and I have had to skip it.

If you want to I can send you the latest working version of
emacsclient.c and so we can perhaps start where we left off. We
easiest way to merge is probably changing some things in the trunk
emacsclient.c to get it closer to my emacsclient.c first. Then we can
see what really differs.

Re: Efforts to attract more users?

[Juanma Barranquero]

On Fri, Jul 9, 2010 at 13:41, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> If you want to I can send you the latest working version of
> emacsclient.c and so we can perhaps start where we left off.

No, as long as it is totally "reordered" wrt the trunk's version.

> We
> easiest way to merge is probably changing some things in the trunk
> emacsclient.c to get it closer to my emacsclient.c first. Then we can
> see what really differs.

I think the idea is more like "you can change some things in your
emacsclient.c to get it closer to the trunk's. Then we can see what
really differs."

Now, this is the point at which things stalled in all past attempts...

    Juanma

Re: Efforts to attract more users?

[Lennart Borgman]

On Fri, Jul 9, 2010 at 2:58 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Jul 9, 2010 at 13:41, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>> If you want to I can send you the latest working version of
>> emacsclient.c and so we can perhaps start where we left off.
>
> No, as long as it is totally "reordered" wrt the trunk's version.

The reordering is done exactly to make emacsclient.c start Emacs when needed.

So I do not understand what you ask for.

>> We
>> easiest way to merge is probably changing some things in the trunk
>> emacsclient.c to get it closer to my emacsclient.c first. Then we can
>> see what really differs.
>
> I think the idea is more like "you can change some things in your
> emacsclient.c to get it closer to the trunk's. Then we can see what
> really differs."

I can make it totally equal the emacsclient.c in the trunk. But it
will not help ;-)

> Now, this is the point at which things stalled in all past attempts...
>
>     Juanma
>

Re: Efforts to attract more users?

[Dan Nicolaescu]

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

> On Fri, Jul 9, 2010 at 2:58 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> On Fri, Jul 9, 2010 at 13:41, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>
>>> If you want to I can send you the latest working version of
>>> emacsclient.c and so we can perhaps start where we left off.
>>
>> No, as long as it is totally "reordered" wrt the trunk's version.
>
> The reordering is done exactly to make emacsclient.c start Emacs when needed.
>
> So I do not understand what you ask for.

I don't have the context for what you are talking about, what code are you trying to merge?
But emacsclient.c is 1800 lines in trunk now, there's no complicated algorithms in there.
It shouldn't be that complicated to use narrow-to-defun and merge function by function...

Re: Efforts to attract more users?

[Lennart Borgman]

On Fri, Jul 9, 2010 at 6:09 PM, Dan Nicolaescu <dann@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Fri, Jul 9, 2010 at 2:58 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>>> On Fri, Jul 9, 2010 at 13:41, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>
>>>> If you want to I can send you the latest working version of
>>>> emacsclient.c and so we can perhaps start where we left off.
>>>
>>> No, as long as it is totally "reordered" wrt the trunk's version.
>>
>> The reordering is done exactly to make emacsclient.c start Emacs when needed.
>>
>> So I do not understand what you ask for.
>
> I don't have the context for what you are talking about, what code are you trying to merge?
> But emacsclient.c is 1800 lines in trunk now, there's no complicated algorithms in there.
> It shouldn't be that complicated to use narrow-to-defun and merge function by function...


I would be very glad if anyone has time to try to merge my version and
the trunk version.

My version is in two parts, the general part and the w32 part. I
divided it this way to make the merge easier. Please take the files
here, maybe make a temporary bzr repository for those two files and go
ahead:

  http://ourcomments.org/Emacs/DL/C/

Re: Efforts to attract more users?

[Dan Nicolaescu]

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

> On Fri, Jul 9, 2010 at 6:09 PM, Dan Nicolaescu <dann@gnu.org> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Fri, Jul 9, 2010 at 2:58 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>>>> On Fri, Jul 9, 2010 at 13:41, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>>
>>>>> If you want to I can send you the latest working version of
>>>>> emacsclient.c and so we can perhaps start where we left off.
>>>>
>>>> No, as long as it is totally "reordered" wrt the trunk's version.
>>>
>>> The reordering is done exactly to make emacsclient.c start Emacs when needed.
>>>
>>> So I do not understand what you ask for.
>>
>> I don't have the context for what you are talking about, what code are you trying to merge?
>> But emacsclient.c is 1800 lines in trunk now, there's no complicated algorithms in there.
>> It shouldn't be that complicated to use narrow-to-defun and merge function by function...
>
>
> I would be very glad if anyone has time to try to merge my version and
> the trunk version.
>
> My version is in two parts, the general part and the w32 part. I
> divided it this way to make the merge easier. Please take the files
> here, maybe make a temporary bzr repository for those two files and go
> ahead:

You might want to first explain why would we want to merge your version.

>   http://ourcomments.org/Emacs/DL/C/

There's some files there with some non-suggestive names (-my.c,
-my-ok.c) and there's nothing that explains what changes where made
and why...

It looks like you would be the best person to do the merge... Given
that there's not that much code, it can't take more than a couple of
hours.

Re: Efforts to attract more users?

[Lennart Borgman]

On Fri, Jul 9, 2010 at 7:05 PM, Dan Nicolaescu <dann@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Fri, Jul 9, 2010 at 6:09 PM, Dan Nicolaescu <dann@gnu.org> wrote:
>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>
>>>> On Fri, Jul 9, 2010 at 2:58 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>>>>> On Fri, Jul 9, 2010 at 13:41, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>>>
>>>>>> If you want to I can send you the latest working version of
>>>>>> emacsclient.c and so we can perhaps start where we left off.
>>>>>
>>>>> No, as long as it is totally "reordered" wrt the trunk's version.
>>>>
>>>> The reordering is done exactly to make emacsclient.c start Emacs when needed.
>>>>
>>>> So I do not understand what you ask for.
>>>
>>> I don't have the context for what you are talking about, what code are you trying to merge?
>>> But emacsclient.c is 1800 lines in trunk now, there's no complicated algorithms in there.
>>> It shouldn't be that complicated to use narrow-to-defun and merge function by function...
>>
>>
>> I would be very glad if anyone has time to try to merge my version and
>> the trunk version.
>>
>> My version is in two parts, the general part and the w32 part. I
>> divided it this way to make the merge easier. Please take the files
>> here, maybe make a temporary bzr repository for those two files and go
>> ahead:
>
> You might want to first explain why would we want to merge your version.
>
>>   http://ourcomments.org/Emacs/DL/C/
>
> There's some files there with some non-suggestive names (-my.c,
> -my-ok.c) and there's nothing that explains what changes where made
> and why...
>
> It looks like you would be the best person to do the merge... Given
> that there's not that much code, it can't take more than a couple of
> hours.

I am in a hurry right now. I think any .c versions are ok to start with.

No, I am not the right person. I have suggested this to this list
before and it was not accepted. Someone else should do it.

Re: Efforts to attract more users?

[Dan Nicolaescu]

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

> On Fri, Jul 9, 2010 at 7:05 PM, Dan Nicolaescu <dann@gnu.org> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Fri, Jul 9, 2010 at 6:09 PM, Dan Nicolaescu <dann@gnu.org> wrote:
>>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>>
>>>>> On Fri, Jul 9, 2010 at 2:58 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>>>>>> On Fri, Jul 9, 2010 at 13:41, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>>>>
>>>>>>> If you want to I can send you the latest working version of
>>>>>>> emacsclient.c and so we can perhaps start where we left off.
>>>>>>
>>>>>> No, as long as it is totally "reordered" wrt the trunk's version.
>>>>>
>>>>> The reordering is done exactly to make emacsclient.c start Emacs when needed.
>>>>>
>>>>> So I do not understand what you ask for.
>>>>
>>>> I don't have the context for what you are talking about, what code are you trying to merge?
>>>> But emacsclient.c is 1800 lines in trunk now, there's no complicated algorithms in there.
>>>> It shouldn't be that complicated to use narrow-to-defun and merge function by function...
>>>
>>>
>>> I would be very glad if anyone has time to try to merge my version and
>>> the trunk version.
>>>
>>> My version is in two parts, the general part and the w32 part. I
>>> divided it this way to make the merge easier. Please take the files
>>> here, maybe make a temporary bzr repository for those two files and go
>>> ahead:
>>
>> You might want to first explain why would we want to merge your version.
>>
>>>   http://ourcomments.org/Emacs/DL/C/
>>
>> There's some files there with some non-suggestive names (-my.c,
>> -my-ok.c) and there's nothing that explains what changes where made
>> and why...
>>
>> It looks like you would be the best person to do the merge... Given
>> that there's not that much code, it can't take more than a couple of
>> hours.
>
> I am in a hurry right now. I think any .c versions are ok to start with.
>
> No, I am not the right person. I have suggested this to this list
> before and it was not accepted. Someone else should do it.

You might want to try again, and first start by explaining what the
new code does and why the changes were needed.  Otherwise it's hard to
convince anyone to work on code without knowing why...
This still says that you are the most qualified to do the work...

You can start in small steps:
 - identify new functions that you added, add those to the end of the file
 - identify functions that you've changed, merge changes one by one,
   and write ChangeLog entries explaining the change

RE: Efforts to attract more users?

[Drew Adams]

So now it seems that this thread has been diverted to a discussion about merging
Lennart's emacsclient changes, who should do that, why...  Next you'll be
discussing each of those changes individually.  Then...

Why is it so difficult to _start a new thread_ when you change the subject?

Here, FWIW, was the place where you turned off the road:

>> And the reason for it is IMO
>> partly that emacs client does not start Emacs by default. (It does in
>> the patched version of Emacs+EmacsW32 however.)
>
> You could send patches for the standard Emacs...
> Hey! Didn't we have this conversation (a few times) before? :-)

Some discussion of emacsclient problems and improvements _might_ be appropriate
for this thread, provided it remains tied to a discussion about attracting more
users.

But when you take a detour to pursue emacsclient implementation and merge
details, you've left the road, probably forever.  At best, you're on a side
road.  At worst, you're off into the swamp.

Re: Efforts to attract more users?

[Juanma Barranquero]

On Fri, Jul 9, 2010 at 19:29, Drew Adams <drew.adams@oracle.com> wrote:
> So now it seems that this thread has been diverted to a discussion about merging
> Lennart's emacsclient changes, who should do that, why...  Next you'll be
> discussing each of those changes individually.  Then...
>
> Why is it so difficult to _start a new thread_ when you change the subject?
>
> Here, FWIW, was the place where you turned off the road:
>
>>> And the reason for it is IMO
>>> partly that emacs client does not start Emacs by default. (It does in
>>> the patched version of Emacs+EmacsW32 however.)
>>
>> You could send patches for the standard Emacs...
>> Hey! Didn't we have this conversation (a few times) before? :-)
>
> Some discussion of emacsclient problems and improvements _might_ be appropriate
> for this thread, provided it remains tied to a discussion about attracting more
> users.
>
> But when you take a detour to pursue emacsclient implementation and merge
> details, you've left the road, probably forever.  At best, you're on a side
> road.  At worst, you're off into the swamp.
>
>



-- 
    Juanma

Re: Efforts to attract more users?

[Chong Yidong]

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

> I would be very glad if anyone has time to try to merge my version and
> the trunk version.

This discussion brings to mind a quote by the physicist Wolfgang Pauli.
In 1958, writing about on a colleague's (specious) claims to have found
a unified field theory, he drew a big blank rectangle, and remarked:

  This is to show the world that I can paint like Titian.
  Only technical details are missing.

Re: Efforts to attract more users?

[Lennart Borgman]

On Sat, Jul 10, 2010 at 9:15 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> I would be very glad if anyone has time to try to merge my version and
>> the trunk version.
>
> This discussion brings to mind a quote by the physicist Wolfgang Pauli.
> In 1958, writing about on a colleague's (specious) claims to have found
> a unified field theory, he drew a big blank rectangle, and remarked:
>
>  This is to show the world that I can paint like Titian.
>  Only technical details are missing.

Hm. Quite creative association. Maybe it even can move things forward.

Re: Efforts to attract more users?

[Juanma Barranquero]

On Fri, Jul 9, 2010 at 15:09, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> The reordering is done exactly to make emacsclient.c start Emacs when needed.

It's hard to believe that moving functions around is *exactly* what's
needed to add functionality.

> So I do not understand what you ask for.

1.- Move original emacsclient functions back to where they were.
2.- Do a diff, which should result in a list of the *real differences*
between your emacsclient and the trunk's, instead of being a full file
diff like it is now because of your reordering.
3.- Send the patch *and* a good ChangeLog, or some kind of explanation
of the changes and what they do (and how they work, if it is not
evident).
4.- Wait for comments.
5.- *Act* on those comments.
6.- Repeat  3-5 until everybody is (more or less) satisfied with the result.
7. Commit your changes or ask for them to be committed.

Isn't that difficult, really. All you need is the intention of doing
the work, instead of dumping your emacsclient and asking others to do
it for you...

    Juanma

Re: Efforts to attract more users?

[Lennart Borgman]

On Sat, Jul 10, 2010 at 2:03 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Jul 9, 2010 at 15:09, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>> The reordering is done exactly to make emacsclient.c start Emacs when needed.
>
> It's hard to believe that moving functions around is *exactly* what's
> needed to add functionality.

Believe whatever you want. Or look into it. You might even be right, I
did this long ago.

>> So I do not understand what you ask for.
>
> 1.- Move original emacsclient functions back to where they were.
> 2.- Do a diff, which should result in a list of the *real differences*
> between your emacsclient and the trunk's, instead of being a full file
> diff like it is now because of your reordering.
> 3.- Send the patch *and* a good ChangeLog, or some kind of explanation
> of the changes and what they do (and how they work, if it is not
> evident).
> 4.- Wait for comments.
> 5.- *Act* on those comments.
> 6.- Repeat  3-5 until everybody is (more or less) satisfied with the result.
> 7. Commit your changes or ask for them to be committed.
>
> Isn't that difficult, really. All you need is the intention of doing
> the work, instead of dumping your emacsclient and asking others to do
> it for you...

I have done the work. I simplified it to what it is now. If that is
not accepted then just skip it.

Re: Efforts to attract more users?

[Juanma Barranquero]

On Sat, Jul 10, 2010 at 02:11, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> Believe whatever you want. Or look into it. You might even be right, I
> did this long ago.

You seem to forget that I *did* (look into it) long ago. That's what
I'm talking about.

> I have done the work. I simplified it to what it is now. If that is
> not accepted then just skip it.

I'll be ready to "skip it" the day you're ready to stop accussing
Emacs developers of ignoring your work every time you've got the
opportunity.

Perhaps you should be brave enough to accept that Emacs+EmacsW32 is a
fork, because you're *not* interested in doing work to get most of
these changes accepted back into mainstream Emacs.

    Juanma

Re: Efforts to attract more users?

[Lennart Borgman]

On Sat, Jul 10, 2010 at 2:16 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Sat, Jul 10, 2010 at 02:11, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> Believe whatever you want. Or look into it. You might even be right, I
>> did this long ago.
>
> You seem to forget that I *did* (look into it) long ago. That's what
> I'm talking about.

I told you at that time how to do the merge. You seemed to believe it
could be done another way. Maybe you are right, but to me the way you
wanted to do it looked like much more work. I ran out of time.

>> I have done the work. I simplified it to what it is now. If that is
>> not accepted then just skip it.
>
> I'll be ready to "skip it" the day you're ready to stop accussing
> Emacs developers of ignoring your work every time you've got the
> opportunity.
>
> Perhaps you should be brave enough to accept that Emacs+EmacsW32 is a
> fork, because you're *not* interested in doing work to get most of
> these changes accepted back into mainstream Emacs.

I have told some times now that I am not interested in keeping the
patches. I have thrown away some because I do not have time for all
the merging.

I do not accuse you of anything. I am just telling how I see the
situation. Getting the thoughts behind the changes I suggest often
takes too much time - even if I write the first part of the patch.
Take for example the recent discussion about the display engine. There
was too many misunderstandings so in the end I thought it was best to
just drop it. Is someone is really interested I have left the
explanations already.

Re: Efforts to attract more users?

[Juanma Barranquero]

On Sat, Jul 10, 2010 at 02:28, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I told you at that time how to do the merge. You seemed to believe it
> could be done another way.

Yes, you told me "here's my code, please adapt it to the trunk, as I
don't have time to do it myself" (not exact quote, but that's the
feeling).

> Maybe you are right, but to me the way you
> wanted to do it looked like much more work. I ran out of time.

No, what I wanted was not more work. It was the same amount of work,
but mostly done by you, instead of me.

> I have told some times now that I am not interested in keeping the
> patches. I have thrown away some because I do not have time for all
> the merging.

That does not mean that you haven't forked, only that you don't have
the time to maintain it.

> I do not accuse you of anything.

I didn't say "me".

> Take for example the recent discussion about the display engine. There
> was too many misunderstandings so in the end I thought it was best to
> just drop it.

I remember the discussion. I got the feeling the misunderstandings
were mainly on your part.

    Juanma

Re: Efforts to attract more users?

[Lennart Borgman]

On Sun, Jul 11, 2010 at 1:43 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Sat, Jul 10, 2010 at 02:28, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> I told you at that time how to do the merge. You seemed to believe it
>> could be done another way.
>
> Yes, you told me "here's my code, please adapt it to the trunk, as I
> don't have time to do it myself" (not exact quote, but that's the
> feeling).

OK, that is your impression, but not my intention. As I told you then
I was/am unused to cvs and did not want to break anything in the
repository or make things more difficult.

We both wanted to make the merge. I suggested to make it stepwise by
changing the function arguments the way I needed them for the new
structure. It would have made the burden of merging easier, but I was
not able to convince you of that.  To still make it a bit easier I
restructured the code so that a similar implementation could be used
on all platform. I got no feedback on that either. Somewhere there I
gave up. I realized I did not have time and I thought it be better to
spend the time I had on nXhtml.

And since such small changes I had proposed for emacsclient and for
the menu system, key board etc where so difficult to get accepted I
decided to try to work around the difficulties in Emacs for using
multi major modes rather than proposing here changes that would have
made it easier. I just did not had time to take the discussion since
these parts are much more difficult.

So all this had big consequences for me.

>> Maybe you are right, but to me the way you
>> wanted to do it looked like much more work. I ran out of time.
>
> No, what I wanted was not more work. It was the same amount of work,
> but mostly done by you, instead of me.

Maybe the big problem was that I did not commit this myself. It looks
to me the amount of work trying to make it this way is several times
bigger than trying to cooperate like this. By that I do not mean
anyone of us where doing something especially wrong or that we did not
try hard enought. Just that this type of cooperation means much more
work.

So I suggest we just give up on this here. I may or may not find time
to switch to savannah from launchpad to do the merge myself. I am not
sure, it depends a lot of what will happen in other areas of my life.
Or someone else may find the time to look into how I structured this
and do the merge. Or someone might redo it from scratch. All I hope is
that this can be done. I do not really care how. I just realize our
efforts so far have been unsuccessful.

>> Take for example the recent discussion about the display engine. There
>> was too many misunderstandings so in the end I thought it was best to
>> just drop it.
>
> I remember the discussion. I got the feeling the misunderstandings
> were mainly on your part.

Really? Did you read my explanation then? (It is not important to me,
but still I get irritated if the bug I was looking at gets ignored
because of misunderstandings.)

Re: Efforts to attract more users?

[Juanma Barranquero]

On Sun, Jul 11, 2010 at 04:40, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> We both wanted to make the merge. I suggested to make it stepwise by
> changing the function arguments the way I needed them for the new
> structure. It would have made the burden of merging easier, but I was
> not able to convince you of that.  To still make it a bit easier I
> restructured the code so that a similar implementation could be used
> on all platform. I got no feedback on that either.

Obviously we remember it quite differently. Let's drop the issue.

> Maybe the big problem was that I did not commit this myself.

Only if trying to reach consensus is seen as a big problem...

> Just that this type of cooperation means much more
> work.

Much more work than what? You're basically saying that you can't be
bothered to spend time discussing changes, so the answers you see are,
either other people spends the time, or you commit the changes even if
you suspect they wouldn't likely be accepted as is, or in some cases
you know they are actively opposed.

> I do not really care how. I just realize our
> efforts so far have been unsuccessful.

I'm glad to see you put it that way, because in most previous
ocassions (including the one that triggered my intervention here) you
said that you had patch X or Y but the developers weren't interested
on them...

> Really? Did you read my explanation then? (It is not important to me,
> but still I get irritated if the bug I was looking at gets ignored
> because of misunderstandings.)

Misunderstanding is the operating word here. After a while, I find
your posts in some given thread harder and harder to follow.

    Juanma

Re: Efforts to attract more users?

[Lennart Borgman]

On Sun, Jul 11, 2010 at 4:56 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
>
> Obviously we remember it quite differently. Let's drop the issue.

Fine with me.

>> Maybe the big problem was that I did not commit this myself.
>
> Only if trying to reach consensus is seen as a big problem...

I was not talking of that problem. So it is not about that.

>> Just that this type of cooperation means much more
>> work.
>
> Much more work than what?

Than when you do the commits yourself.

> You're basically saying that you can't be
> bothered to spend time discussing changes, so the answers you see are,
> either other people spends the time, or you commit the changes even if
> you suspect they wouldn't likely be accepted as is, or in some cases
> you know they are actively opposed.

Not at all. I am talking about the technical difficulties with cooperation.

> I'm glad to see you put it that way, because in most previous
> ocassions (including the one that triggered my intervention here) you
> said that you had patch X or Y but the developers weren't interested
> on them...

It has sometimes seemed so to me, but looking back I think it is more
about our limited resources.

>> Really? Did you read my explanation then? (It is not important to me,
>> but still I get irritated if the bug I was looking at gets ignored
>> because of misunderstandings.)
>
> Misunderstanding is the operating word here. After a while, I find
> your posts in some given thread harder and harder to follow.

I often try to explain on another level if the previous message was
not understood because it seems to me that this is necessary.

I am not sure what the problem is. With some people here I find it
very easy to communicate. With some it is quite hard.

Re: Efforts to attract more users?

[Stephen J. Turnbull]

Back to the "attract more users" thread.  Specifically, "attract more
user/developers."

Juanma Barranquero writes:
 > On Sat, Jul 10, 2010 at 02:28, Lennart Borgman
 > <lennart.borgman@gmail.com> wrote:
 > 
 > > I told you at that time how to do the merge. You seemed to believe it
 > > could be done another way.
 > 
 > Yes, you told me "here's my code, please adapt it to the trunk, as I
 > don't have time to do it myself" (not exact quote, but that's the
 > feeling).

That's not the feeling I get at all.  I don't have complete sympathy
for Lennart, there is clearly some aspect of contributing to Emacs
that he just doesn't get, leading to blocked communication with
disheartening frequency.  However, "take it or leave it" is NOT AT ALL
what I get from his posts.  There a separate issue, that when you
submit working code to Emacs, you will be told to change it in ways
that give you heartburn.  Lennart has had *multiple* experiences where
he has submitted working code, communications over the integration
break down, and his code was refused, without anybody ever doing more
than looking at it and saying "that can't work" (usually with a
theoretical rationale that for whatever reason Lennart doesn't get).
While (as I mention above), Lennart has to take some responsibility
for the communications breakdown, I cannot at all blame him for not
wanting to go through that again.

One of the nice things about working on <beep>Emacs and <boop>Emacs,
as well as projects like Python, Mailman, and Bazaar, is that
sometimes (not always, of course) other people will do the work that
you for whatever reason don't want to do.

It's a shame that GNU Emacs, of all the projects in the world, feels
so impoverished that its developers can't take time out to mentor
somebody like Lennart, show him the ropes, and *teach* him how to make
submissions that get accepted the first time around and require only
minor adjustments and checks before integration to the trunk.  I think
in this case the proposed change is such an obvious winner that it's
only Emacs-side stubbornness that prevents it from being implemented.

Re: Efforts to attract more users?

[Juanma Barranquero]

On Mon, Jul 12, 2010 at 02:23, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> That's not the feeling I get at all.

Well, there were a couple times when I was in contact with him (I
mean, I was really trying to help him get some code into Emacs), and
that's the feeling I got. If your experience, from the times you've
tried to help him (or mentor him, as you later describe) is different,
lucky you.

> Lennart has had *multiple* experiences where
> he has submitted working code, communications over the integration
> break down, and his code was refused, without anybody ever doing more
> than looking at it and saying "that can't work" (usually with a
> theoretical rationale that for whatever reason Lennart doesn't get).

I cannot argue that what you said has not happened, because I sure am
not going to go re-reading all these old threads. But certainly
there's been more than a few times when nobody said "can't work", more
like "please do the work", only to hear back "oh, that's a lot of time
I don't have right now, just do it yourself". Followed by complains
later on when nobody took on the invitation (which is what really irks
me; I can understand he not wanting to do it, but not his complaining
about others not doing it for him).

> It's a shame that GNU Emacs, of all the projects in the world, feels
> so impoverished that its developers can't take time out to mentor
> somebody like Lennart, show him the ropes, and *teach* him how to make
> submissions that get accepted the first time around and require only
> minor adjustments and checks before integration to the trunk.

What you describe as "can't work" interactions I'd describe as "take
time out to mentor". So far the answer has no been encouraging.

> I think
> in this case the proposed change is such an obvious winner that it's
> only Emacs-side stubbornness that prevents it from being implemented.

Really? Is just that? How nice that you can so fully understand
people's motives (and minds) to know that's the only thing that's
happened.

    Juanma

Re: Efforts to attract more users?

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Well, there were a couple times when I was in contact with him (I
 > mean, I was really trying to help him get some code into Emacs),

I don't know what it feels like to mentor Lennart, personally.  I do
know what it feels like to try to get code into Emacs, *and I won't
try it again*.  I'm an extreme case for several reasons, there are
*plenty* of people willing to jump through the hoops (and I'm not
talking about "papers").  But I bet there is also a fair amount of
good code sitting around out there that people are unwilling to
contribute because of the scutwork and bikeshedding entailed in
getting anything into Emacs, and which experienced developers could
whip into shape quite quickly if they just took the code and said "it
will be our pleasure".

 > I cannot argue that what you said has not happened, because I sure am
 > not going to go re-reading all these old threads. But certainly
 > there's been more than a few times when nobody said "can't work", more
 > like "please do the work", only to hear back "oh, that's a lot of time
 > I don't have right now, just do it yourself". Followed by complains
 > later on when nobody took on the invitation (which is what really irks
 > me; I can understand he not wanting to do it, but not his complaining
 > about others not doing it for him).

And if it turns out to be good code, it's cheap at ten times the price
-- it took me ten years to learn to swallow my pride, and the
investment was paid back in less than one in third-party contribs that
got into mainline faster :-).  If it turns out to be bad code upon
review and attempted fix, you tell him so.  If bad code happens twice,
you tell him he'll have to find another mentor/channel to the
mainline.  IME it's well worth it.

 > > I think in this case the proposed change is such an obvious
 > > winner that it's only Emacs-side stubbornness that prevents it
 > > from being implemented.
 > 
 > Really? Is just that? How nice that you can so fully understand
 > people's motives (and minds) to know that's the only thing that's
 > happened.

Read what I wrote.  Nothing about intentions.  Only that this change
(having a single program, named either "emacs" or "emacsclient", that
if needed automatically starts an emacs daemon, and then connects to
it) is a big win IMO, one that I've wanted for <buup>Emacs for a long
time.[1]  I can understand Richard or Miles or other non-Windows-user
brushing it off; I don't understand you or Eli being willing to let
this one go without at least trying to beat it into shape yourself,
given that Lennart is probably not going to get it into Emacs himself
(based on past experience, without assigning fault).

All I'm saying is that sometimes it's worth doing the work yourself.

Footnotes: 
[1]  We of course actually do have a kludgy half-baked functionality,
both on Windows and on *nix, but it doesn't make either traditional
users or Windows/CUA types happy.

Re: Efforts to attract more users?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Mon, 12 Jul 2010 16:43:38 +0900
> Cc: Lennart Borgman <lennart.borgman@gmail.com>,
> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> I don't know what it feels like to mentor Lennart, personally.  I do
> know what it feels like to try to get code into Emacs, *and I won't
> try it again*.

So you are talking about Lennart, but think about yourself.  It would
have been fair to tell that up front.  More importantly, there's a
world of difference between these two cases, even though the result
might be similar.

> But I bet there is also a fair amount of good code sitting around
> out there that people are unwilling to contribute because of the
> scutwork and bikeshedding entailed in getting anything into Emacs,
> and which experienced developers could whip into shape quite quickly
> if they just took the code and said "it will be our pleasure".

I don't think there's ``a fair amount of code'' in this status.
However, I hope you will understand that making the necessary changes
for a contributor who is unwilling to make them by herself is not a
good policy in the long run, because (1) it's hardly a good use of the
limited time resources I have, and (2) we will need to do this
forever, as the contributor doesn't want to adapt their practices to
some minimal requirements of QA and code cleanness.  He even refuses
to reformat his code as to facilitate the review!

> I can understand Richard or Miles or other non-Windows-user
> brushing it off; I don't understand you or Eli being willing to let
> this one go without at least trying to beat it into shape yourself,

What's not to understand?  I have no time for arguing with Lennart,
and I have better use (developing bidi) for the few hours a week I
have to work on Emacs.  I'm willing to invest some portion of that
time in teaching someone who genuinely wants to learn.  I'm
_un_willing to _waste_ it on endless arguments with someone who thinks
they know better.

Re: Efforts to attract more users?

[Richard Stallman]

    However, I hope you will understand that making the necessary changes
    for a contributor who is unwilling to make them by herself is not a
    good policy in the long run, because (1) it's hardly a good use of the
    limited time resources I have, and (2) we will need to do this
    forever, as the contributor doesn't want to adapt their practices to
    some minimal requirements of QA and code cleanness.  He even refuses
    to reformat his code as to facilitate the review!

Deciding to clean up someone else's feature is no different, in regard
to these issues, from deciding to write a feature.  You don't have
time to write all the features that someone suggests and that you
would like.  That doesn't mean you must make a policy decision between
implementing all suggestions and implementing none.  You see the
suggestions and sometimes you implement one.

You can look at other people's patches the same way.  There is nothing
wrong, in principle, with cleaning up someone else's patch.  It just
takes work, and it may or may not be the way you want to contribute.

In the end, if a person refuses to reformat or adapt his own patch,
that doesn't make it impossible for us to use the patch, but does make
it expensive.  Sometimes someone else will decide to do this work for
him, but usually not.  The refusal will surely result in few of his
patches' being installed, and when they are, it will be at the cost of
more work for the rest of us.  So it will mean he effectively
contributes much less -- that is why it is unfortunate.  But we have no
reason to treat it as all or nothing.

Re: Efforts to attract more users?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: stephen@xemacs.org, lekktu@gmail.com, lennart.borgman@gmail.com,
> 	emacs-devel@gnu.org
> Date: Mon, 12 Jul 2010 08:37:06 -0400
> 
> You can look at other people's patches the same way.  There is nothing
> wrong, in principle, with cleaning up someone else's patch.  It just
> takes work, and it may or may not be the way you want to contribute.
> 
> In the end, if a person refuses to reformat or adapt his own patch,
> that doesn't make it impossible for us to use the patch, but does make
> it expensive.  Sometimes someone else will decide to do this work for
> him, but usually not.  The refusal will surely result in few of his
> patches' being installed, and when they are, it will be at the cost of
> more work for the rest of us.  So it will mean he effectively
> contributes much less -- that is why it is unfortunate. 

I agree and support everything you say above.

> But we have no reason to treat it as all or nothing.

No such decision was made, definitely not by me.  I was just
explaining why things might end up this way even if no such decision
was made.

Re: Efforts to attract more users?

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Juanma Barranquero writes:
>
>  > Well, there were a couple times when I was in contact with him (I
>  > mean, I was really trying to help him get some code into Emacs),
>
> I don't know what it feels like to mentor Lennart, personally.  I do
> know what it feels like to try to get code into Emacs, *and I won't
> try it again*.

Well, I find it an awful pain to get non-trivial code into pretty much
any large project.  Problem is that the committer needs to feel
comfortable about it, or it becomes Somebody Else's Problem (tm).  And
the typical committer is quite more likely to feel comfortable about his
own code than about third-party code of similar code and documentation
quality.

Which does not serve to improve the mood of non-committing contributors.
Now excellent coding skills and excellent social skills are not
necessarily positively correlated.

For me, the consequences are that I try to get commit access as soon as
possible.  Not because I deem my contributions are of better quality
than that of others without commit access, but since the alternatives
are so much more wasteful regarding everybody's time and nerves.

AFAIK, however, Lennart _does_ have commit access and the skills to
understand and heed others' suggestions, but is lacking time and
motivation to follow through.

That's a pity, but it won't become less of a pity by fingerpointing.  I
don't see how social and technical structures could be amended to create
a better environment for getting the integration work done.

Things work as good as they can, given the current "human resources".
The results are not good enough, but it would not appear that anybody
has an idea how to change this without waving a magical wand that
changes what we have to work with.

-- 
David Kastrup

Re: Efforts to attract more users?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Mon, 12 Jul 2010 09:23:48 +0900
> Cc: Lennart Borgman <lennart.borgman@gmail.com>,
> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> It's a shame that GNU Emacs, of all the projects in the world, feels
> so impoverished that its developers can't take time out to mentor
> somebody like Lennart, show him the ropes, and *teach* him how to make
> submissions that get accepted the first time around and require only
> minor adjustments and checks before integration to the trunk.

Stephen, I'm sorry to break it to you, but you are talking out of
ignorance.  You've read one or two recent threads, formed your own
illusion of what they tell, and now attack the wrong people based on
that illusion.  This is imply unfair.

The facts are different.  Indeed, a very small part of Lennart's
patches were outright rejected, because they were based on wrong
assumptions and ideas.  However, most of his patches were not
rejected.  They got _reviewed_, and the review yielded _comments_ and
requests for changes.  The problem started when Lennart effectively
refused to modify his code according to the comments.  Instead, he
argued time and again that his code was correct, and the reviewers
were wrong.  This led to endless discussions going in circles and
leading nowhere, so people tend to cut their losses and stop
responding.  The result is that his patches are left hanging in the
air.

And after several such experiences, I cannot blame anyone for trying
to cut their losses even _before_ entering the same vicious circle for
the N+1st time.

IOW, if there is stubbornness, you will find plenty of it -- on
Lennart's side.  His lack of will to compromise and hear to *mentors*
and learn from them is profound, and doesn't seem to be prone to
change any time soon.  While Lennart is entitled to his views and ways
of socializing with others, it is very hard to teach and mentor
someone who in effect thinks, even if he doesn't say that explicitly,
that he is always right.

It's a shame that Emacs development seems to lose Lennart's resources
of time and energy, but I really don't see how things could go
differently, given his repeated attitude and lack of will to be taught
and become part of a team.

Re: Efforts to attract more users?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > requests for changes.  The problem started when Lennart effectively
 > refused to modify his code according to the comments.

I acknowledge that, and I've been following emacs-devel for about a
decade now; my opinion of this case is *not* based on one or two
recent interactions.  See also my reply to Juanma.

 > IOW, if there is stubbornness, you will find plenty of it -- on
 > Lennart's side.

Lennart is one individual.  A individual non-committer's stubbornness
is not a problem; if you don't feel like dealing with it, just put him
in your killfile.  Emacs's stubbornness (assuming it exists) *is* a
problem; putting emacs-devel in your killfile just won't do.

 > It's a shame that Emacs development seems to lose Lennart's resources
 > of time and energy, but I really don't see how things could go
 > differently,

It's very easy to see how it could go differently.  Do what he asks,
on a case by case business.  Of course you have to get papers.  And
you have to reserve the right to make arbitrary changes to his
contributed code.  (That actually should go without saying, but in
this case it might be a good idea to make it explicit.)  But I suspect
that as long as it works he won't even check what you did to fit it
into Emacs coding style etc.

And finally, the code has to be worth making an exception.  Maybe I'm
misjudging what this is worth to Emacs; on that, I concede that you
and Juanma are far better judges than I ever will be.

Re: Efforts to attract more users?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: lekktu@gmail.com,
>     lennart.borgman@gmail.com,
>     emacs-devel@gnu.org
> Date: Mon, 12 Jul 2010 17:05:05 +0900
> 
>  > It's a shame that Emacs development seems to lose Lennart's resources
>  > of time and energy, but I really don't see how things could go
>  > differently,
> 
> It's very easy to see how it could go differently.  Do what he asks,
> on a case by case business.  Of course you have to get papers.  And
> you have to reserve the right to make arbitrary changes to his
> contributed code.

I explained elsewhere why I think this is not a good use of my time.
I can easily understand why Juanma would think it's not a good use of
his time, either.

> But I suspect that as long as it works he won't even check what you
> did to fit it into Emacs coding style etc.

Wrong assumption.  And, of course, coding conventions is not the only
issue with these contributions.  More often than not, the
implementation is just plain wrong, based on purely phenomenological
evidence, and lacking any real understanding of how the relevant parts
of Emacs work.  Explaining how things really work does not help,
because the only outcome is another endless argument.

> And finally, the code has to be worth making an exception.  Maybe I'm
> misjudging what this is worth to Emacs; on that, I concede that you
> and Juanma are far better judges than I ever will be.

Both of us (and Jason Rumney, when he had more time to spend on this)
were always almost unanimous in our critical opinions.  If you think
it helped convince Lennart to budge, think again.

Re: Efforts to attract more users?

[Deniz Dogan]

Is this discussion going anywhere? Seriously.

Re: Efforts to attract more users?

[David Kastrup]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:

> Is this discussion going anywhere? Seriously.

Let's say that reference counting won't make it go away.

-- 
David Kastrup

Emacs learning curve (was Re: Efforts to attract more users?)

[christian.lynbech]

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

I failed to resist the urge to re-post the below picture on editor
learning curves :-)

I found it at http://unix.rulez.org/~calver/pictures/curves.jpg

                              -- Christian


[-- Attachment #2: curves.jpg --]
[-- Type: image/jpeg, Size: 26488 bytes --]

Re: Emacs learning curve

[Masatake YAMATO]

> I failed to resist the urge to re-post the below picture on editor
> learning curves :-)
> 
> I found it at http://unix.rulez.org/~calver/pictures/curves.jpg

Quite interesting.

I guess the emacs curve is also applicable to "Lisp" in "learning curve for 
some common programming languages."

Masatake YAMATO

Re: Efforts to attract more users?

[Lennart Borgman]

On Fri, Jul 9, 2010 at 5:05 AM, Richard Stallman <rms@gnu.org> wrote:
> The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
> them, but maybe we still lack some.
>
> I saw it once, and it used tabs a lot for switching between different views.
> We need to be able to do that too.
>
> Also, one advantage of Eclipse's GUI interface is that it shows you a
> lot of features when they might be useful.  So you don't have as much
> to learn and remember.

I guess it would be much more easy to do that if Emacs could use for
example wxWidgets.

Re: Efforts to attract more users?

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> I guess it would be much more easy to do that if Emacs could use for
> example wxWidgets.

Why?  Emacs already uses GTK.

-Miles

-- 
Defenceless, adj. Unable to attack.

Re: Efforts to attract more users?

[Lennart Borgman]

On Sun, Jul 11, 2010 at 6:37 AM, Miles Bader <miles@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>> I guess it would be much more easy to do that if Emacs could use for
>> example wxWidgets.
>
> Why?  Emacs already uses GTK.

What I think is important is to follow platform conventions (when possible).

Is that supported by GTK?

Re: Efforts to attract more users?

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> Why?  Emacs already uses GTK.
>
> What I think is important is to follow platform conventions (when possible).
>
> Is that supported by GTK?

No clue.

But wxwidgets is ancient, clunky, and bloated, and not something Emacs
should be depending on lightly.

-Miles

-- 
Bigot, n. One who is obstinately and zealously attached to an opinion that
you do not entertain.

Re: Efforts to attract more users?

[Lennart Borgman]

On Sun, Jul 11, 2010 at 3:24 PM, Miles Bader <miles@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>> Why?  Emacs already uses GTK.
>>
>> What I think is important is to follow platform conventions (when possible).
>>
>> Is that supported by GTK?
>
> No clue.
>
> But wxwidgets is ancient, clunky, and bloated, and not something Emacs
> should be depending on lightly.

I will not pretend to know anything about it but the latest release is
from 2010-04-23.

Re: Efforts to attract more users?

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> But wxwidgets is ancient, clunky, and bloated, and not something Emacs
>> should be depending on lightly.
>
> I will not pretend to know anything about it but the latest release is
> from 2010-04-23.

I don't mean it's not maintained.

-Miles

-- 
Helpmate, n. A wife, or bitter half.

Re: Efforts to attract more users?

[Lennart Borgman]

On Sun, Jul 11, 2010 at 3:59 PM, Miles Bader <miles@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>> But wxwidgets is ancient, clunky, and bloated, and not something Emacs
>>> should be depending on lightly.
>>
>> I will not pretend to know anything about it but the latest release is
>> from 2010-04-23.
>
> I don't mean it's not maintained.

No I am getting curious. You obviously know more than me about this.
Why do you say wxWidget is ancient? (This is a little bit funny to use
the word "ancient" here when Emacs is so old ;-)

I know people have had negative opinions about it here before. It
looked to me some of it was based on experience, but I am not sure.

Re: Efforts to attract more users?

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sun, 11 Jul 2010 16:13:38 +0200
> Cc: fplemma@gmail.com, rms@gnu.org, joakim@verona.se, emacs-devel@gnu.org
> 
> On Sun, Jul 11, 2010 at 3:59 PM, Miles Bader <miles@gnu.org> wrote:
> > Lennart Borgman <lennart.borgman@gmail.com> writes:
> >>> But wxwidgets is ancient, clunky, and bloated, and not something Emacs
> >>> should be depending on lightly.
> >>
> >> I will not pretend to know anything about it but the latest release is
> >> from 2010-04-23.
> >
> > I don't mean it's not maintained.
> 
> No I am getting curious. You obviously know more than me about this.
> Why do you say wxWidget is ancient? (This is a little bit funny to use
> the word "ancient" here when Emacs is so old ;-)
> 
> I know people have had negative opinions about it here before. It
> looked to me some of it was based on experience, but I am not sure.

According to their docs, wxWidgets is for C++, not for C, so Emacs
cannot use it.

Re: Efforts to attract more users?

[Alan Mackenzie]

On Sun, Jul 11, 2010 at 05:24:42PM +0300, Eli Zaretskii wrote:
> > From: Lennart Borgman <lennart.borgman@gmail.com>
> > Date: Sun, 11 Jul 2010 16:13:38 +0200
> > Cc: fplemma@gmail.com, rms@gnu.org, joakim@verona.se, emacs-devel@gnu.org

> > On Sun, Jul 11, 2010 at 3:59 PM, Miles Bader <miles@gnu.org> wrote:
> > > Lennart Borgman <lennart.borgman@gmail.com> writes:
> > >>> But wxwidgets is ancient, clunky, and bloated, and not something Emacs
> > >>> should be depending on lightly.

> > >> I will not pretend to know anything about it but the latest release is
> > >> from 2010-04-23.

> > > I don't mean it's not maintained.

> > No I am getting curious. You obviously know more than me about this.
> > Why do you say wxWidget is ancient? (This is a little bit funny to use
> > the word "ancient" here when Emacs is so old ;-)

> > I know people have had negative opinions about it here before. It
> > looked to me some of it was based on experience, but I am not sure.

> According to their docs, wxWidgets is for C++, not for C, so Emacs
> cannot use it.

In that case, couldn't we just convert our base code to C++, then we
could use wxWidgets.

(Hey, it's over 35 degrees (of the Celsius variety) here in Nuremberg;
this doesn't encourage high quality hacking.  I'm kind of wondering how
far over Europe this blanket of smothering heat extends.)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Efforts to attract more users?

[Bernardo Barros]

It's 21 celcius in Sao Paulo. Happy hacking day!

2010/7/11 Alan Mackenzie <acm@muc.de>:
> On Sun, Jul 11, 2010 at 05:24:42PM +0300, Eli Zaretskii wrote:
>> > From: Lennart Borgman <lennart.borgman@gmail.com>
>> > Date: Sun, 11 Jul 2010 16:13:38 +0200
>> > Cc: fplemma@gmail.com, rms@gnu.org, joakim@verona.se, emacs-devel@gnu.org
>
>> > On Sun, Jul 11, 2010 at 3:59 PM, Miles Bader <miles@gnu.org> wrote:
>> > > Lennart Borgman <lennart.borgman@gmail.com> writes:
>> > >>> But wxwidgets is ancient, clunky, and bloated, and not something Emacs
>> > >>> should be depending on lightly.
>
>> > >> I will not pretend to know anything about it but the latest release is
>> > >> from 2010-04-23.
>
>> > > I don't mean it's not maintained.
>
>> > No I am getting curious. You obviously know more than me about this.
>> > Why do you say wxWidget is ancient? (This is a little bit funny to use
>> > the word "ancient" here when Emacs is so old ;-)
>
>> > I know people have had negative opinions about it here before. It
>> > looked to me some of it was based on experience, but I am not sure.
>
>> According to their docs, wxWidgets is for C++, not for C, so Emacs
>> cannot use it.
>
> In that case, couldn't we just convert our base code to C++, then we
> could use wxWidgets.
>
> (Hey, it's over 35 degrees (of the Celsius variety) here in Nuremberg;
> this doesn't encourage high quality hacking.  I'm kind of wondering how
> far over Europe this blanket of smothering heat extends.)
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
>

Re: Efforts to attract more users?

[Eli Zaretskii]

> Date: Sun, 11 Jul 2010 15:01:42 +0000
> Cc: Lennart Borgman <lennart.borgman@gmail.com>, fplemma@gmail.com,
>   emacs-devel@gnu.org, rms@gnu.org, joakim@verona.se, miles@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > According to their docs, wxWidgets is for C++, not for C, so Emacs
> > cannot use it.
> 
> In that case, couldn't we just convert our base code to C++, then we
> could use wxWidgets.

Maybe Lennart will volunteer for that job.

Re: Efforts to attract more users?

[John Yates]

On Sun, Jul 11, 2010 at 1:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Alan Mackenzie <acm@muc.de>
>>
>> In that case, couldn't we just convert our base code to C++, then we
>> could use wxWidgets.
>
> Maybe Lennart will volunteer for that job.

Bjarne Stroustrup pretty much beat Lennart to it.  It is mostly a
project decision to invoke the C++ rather than the C compiler.  The
gcc project recently took the plunge:

http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html

/john

Re: Efforts to attract more users?

[Eli Zaretskii]

> Date: Sun, 11 Jul 2010 17:25:05 -0400
> From: John Yates <john@yates-sheets.org>
> Cc: Alan Mackenzie <acm@muc.de>, fplemma@gmail.com, rms@gnu.org, lennart.borgman@gmail.com, 
> 	joakim@verona.se, emacs-devel@gnu.org, miles@gnu.org
> 
> On Sun, Jul 11, 2010 at 1:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> From: Alan Mackenzie <acm@muc.de>
> >>
> >> In that case, couldn't we just convert our base code to C++, then we
> >> could use wxWidgets.
> >
> > Maybe Lennart will volunteer for that job.
> 
> Bjarne Stroustrup pretty much beat Lennart to it.  It is mostly a
> project decision to invoke the C++ rather than the C compiler.

Compiling ANSI C sources with a C++ compiler is a relatively trivial
job.  Most of the work is elsewhere: you need to actually use C++
features in order to compile and link against wxWidgets, see their
documentation for details.  And that would involve solving all kinds
of potential incompatibilities, like the complex games we play with
memory allocation, including, but not limited to, relocating buffers
and strings behind the app's back, allocating off the pure space, etc.
I don't think a C++ Emacs will fly without a private implementation of
`new' and friends, for example.

And then we will need to figure out the possible incompatibilities
with other toolkits, whose sources we don't own and don't control.

So please don't try to pretend this as an easy decision and easy job.
It's not.  It's not impossible, of course; it just takes motivated
individuals and enough time.  If you are stepping forward, by all
means, describe your plan and let's discuss it.

> The gcc project recently took the plunge:

I wish Emacs was as simple a project as GCC and had so many developers
per area of expertise.

Re: Efforts to attract more users?

[Richard Stallman]

C++ is a badly designed and ugly language.  It would be a shame
to use it in Emacs.

The reason the GCC developers wanted to use it is for destructors
and generics.  These aren't much use in Emacs, which has GC and in
which data types are handled at the Lisp level.

Re: Efforts to attract more users?

[Stephen Eilert]

On Mon, Jul 12, 2010 at 9:36 AM, Richard Stallman <rms@gnu.org> wrote:
> C++ is a badly designed and ugly language.  It would be a shame
> to use it in Emacs.
>
> The reason the GCC developers wanted to use it is for destructors
> and generics.  These aren't much use in Emacs, which has GC and in
> which data types are handled at the Lisp level.
>
>

Indeed, I am left wondering why it was even proposed in the first
place. Moving to C++ would be nonsense and a step backwards.

If we are willing to put so much effort on it, modernizing Elisp would
be a better starting point. That's mostly invisible to users and not
relevant to this discussion, however.


-- Stephen

Sent from my Emacs

Re: Efforts to attract more users?

[Stephen J. Turnbull]

Stephen Eilert writes:

 > Indeed, I am left wondering why [moving to C++] it was even
 > proposed in the first place.

It wasn't.  What was proposed is using a well-known cross-platform
widget set.  That widget set happens to provide C++ bindings but not C
bindings.

It's probably moot since several people who actually have used
wxWidgets in a real project say it's not advantageous over GTK+.

Re: Efforts to attract more users?

[Bernardo Barros]

many people in the gnu world are using qt4. are there reasons not to
consider it?

2010/7/12 Stephen J. Turnbull <stephen@xemacs.org>:
> Stephen Eilert writes:
>
>  > Indeed, I am left wondering why [moving to C++] it was even
>  > proposed in the first place.
>
> It wasn't.  What was proposed is using a well-known cross-platform
> widget set.  That widget set happens to provide C++ bindings but not C
> bindings.
>
> It's probably moot since several people who actually have used
> wxWidgets in a real project say it's not advantageous over GTK+.
>
>
>

Re: Efforts to attract more users?

[Eli Zaretskii]

> Date: Mon, 12 Jul 2010 14:25:00 -0300
> From: Bernardo Barros <bernardobarros2@gmail.com>
> Cc: Stephen Eilert <spedrosa@gmail.com>, fplemma@gmail.com, rms@gnu.org, 
> 	lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, acm@muc.de, 
> 	eliz@gnu.org, John Yates <john@yates-sheets.org>, miles@gnu.org
> 
> many people in the gnu world are using qt4. are there reasons not to
> consider it?

Qt is also C++.  Besides, what's it got that we would like to have?

Why not Qt4? (hi, Drew! was: Efforts to attract more users?)

[Stephen J. Turnbull]

Trimming the absurd CC list.

Bernardo Barros writes:

 > many people in the gnu world are using qt4. are there reasons not to
 > consider it?

A short summary:

- There are already Emacs implementations for all platforms supported
  by Qt4.

- Qt is not a GNU project, some of the already supported toolkits are.

- TrollTech's position on licensing is suspect.  Doesn't bother me in
  theory, actually, as I believe that Qt should be considered part
  of the OS[1] where available, but I suspect many core developers
  would be wary of any dependency on a company with a history of
  non-free licensing.

I think Qt is a non-starter, except as a bikeshed-painting exercise.

Footnotes: 
[1]  By analogy to Motif.  Note that AFAIK the official position of
GNU and the FSF is clear that toolkits like GTK+ and Qt are *not* part
of any free OS.  Therefore they must be distributed under GPL-compatible
licenses to be linked to Emacs.

Re: Efforts to attract more users?

[Miles Bader]

Bernardo Barros <bernardobarros2@gmail.com> writes:
> many people in the gnu world are using qt4. are there reasons not to
> consider it?

Mostly that there would be no point, as it doesn't offer any significant
advantages over GTK, and has some clear problems -- notably it's a C++
toolkit (I personally like C++, but Emacs is not a C++ app).

[I also have some personal gripes about qt4, e.g., it screws up font
rendering in some cases if you have a ~/.fonts.conf file, but things
like that are presumably bugs, and could theoretically be fixed.]

-Miles

-- 
Run away!  Run away!

Re: Efforts to attract more users?

[Richard Stallman]

    many people in the gnu world are using qt4. are there reasons not to
    consider it?

Two:

* GNU policy is to use other GNU packages by preference, and QT isn't
  GNU.

* GNU policy is to use C by preference to C++.

Re: Efforts to attract more users?

[Deniz Dogan]

2010/7/13 Richard Stallman <rms@gnu.org>:
>    many people in the gnu world are using qt4. are there reasons not to
>    consider it?
>
> Two:
>
> * GNU policy is to use other GNU packages by preference, and QT isn't
>  GNU.
>
> * GNU policy is to use C by preference to C++.
>
>

Are these policies listed somewhere?

-- 
Deniz Dogan

Re: Efforts to attract more users?

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 400 bytes --]

   >    many people in the gnu world are using qt4. are there reasons not to
   >    consider it?
   >
   > Two:
   >
   > * GNU policy is to use other GNU packages by preference, and QT isn't
   >  GNU.
   >
   > * GNU policy is to use C by preference to C++.

   Are these policies listed somewhere?

They are listed in the GNU Maintainer Guidelines, the GNU mainfesto,
and our project web page.

Re: Efforts to attract more users?

[Deniz Dogan]

2010/7/13 Alfred M. Szmidt <ams@gnu.org>:
>   >    many people in the gnu world are using qt4. are there reasons not to
>   >    consider it?
>   >
>   > Two:
>   >
>   > * GNU policy is to use other GNU packages by preference, and QT isn't
>   >  GNU.
>   >
>   > * GNU policy is to use C by preference to C++.
>
>   Are these policies listed somewhere?
>
> They are listed in the GNU Maintainer Guidelines, the GNU mainfesto,
> and our project web page.
>

Well, I don't find anything about C++ specifically in the maintainer
guidelines and the manifesto... Never mind, it's not important.

-- 
Deniz Dogan

Re: Efforts to attract more users?

[Eli Zaretskii]

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Tue, 13 Jul 2010 17:52:08 +0200
> Cc: rms@gnu.org, fplemma@gmail.com, lennart.borgman@gmail.com, 
> 	spedrosa@gmail.com, emacs-devel@gnu.org, bernardobarros2@gmail.com, 
> 	joakim@verona.se, acm@muc.de, stephen@xemacs.org, john@yates-sheets.org, 
> 	eliz@gnu.org, miles@gnu.org
> 
> 2010/7/13 Alfred M. Szmidt <ams@gnu.org>:
> >   >    many people in the gnu world are using qt4. are there reasons not to
> >   >    consider it?
> >   >
> >   > Two:
> >   >
> >   > * GNU policy is to use other GNU packages by preference, and QT isn't
> >   >  GNU.
> >   >
> >   > * GNU policy is to use C by preference to C++.
> >
> >   Are these policies listed somewhere?
> >
> > They are listed in the GNU Maintainer Guidelines, the GNU mainfesto,
> > and our project web page.
> >
> 
> Well, I don't find anything about C++ specifically in the maintainer
> guidelines and the manifesto... Never mind, it's not important.

Bad reference.  See the "Source Language" node in the standards.info
manual.

Re: Efforts to attract more users?

[Bernardo Barros]

That makes sense :-)

2010/7/13 Richard Stallman <rms@gnu.org>:
>    many people in the gnu world are using qt4. are there reasons not to
>    consider it?
>
> Two:
>
> * GNU policy is to use other GNU packages by preference, and QT isn't
>  GNU.
>
> * GNU policy is to use C by preference to C++.
>

Re: Efforts to attract more users?

[Lennart Borgman]

On Sun, Jul 11, 2010 at 7:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 11 Jul 2010 15:01:42 +0000
>> Cc: Lennart Borgman <lennart.borgman@gmail.com>, fplemma@gmail.com,
>>   emacs-devel@gnu.org, rms@gnu.org, joakim@verona.se, miles@gnu.org
>> From: Alan Mackenzie <acm@muc.de>
>>
>> > According to their docs, wxWidgets is for C++, not for C, so Emacs
>> > cannot use it.
>>
>> In that case, couldn't we just convert our base code to C++, then we
>> could use wxWidgets.
>
> Maybe Lennart will volunteer for that job.

Why should I do that if I should have to fight all your misunderstandings?

Re: Efforts to attract more users?

[Bernardo Barros]

2010/7/11 Lennart Borgman <lennart.borgman@gmail.com>
>
> No I am getting curious. You obviously know more than me about this.
> Why do you say wxWidget is ancient? (This is a little bit funny to use
> the word "ancient" here when Emacs is so old ;-)
>

just a though. "new" and "old" are not that relevant. but maybe a
felling that it is going somewhere and it is actvelly being developed.
Emacs is doing his job and going somewhere, striping down ancient
things like the terminology I hope :-)

Re: Efforts to attract more users?

[Chong Yidong]

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

>> Also, one advantage of Eclipse's GUI interface is that it shows you a
>> lot of features when they might be useful.  So you don't have as much
>> to learn and remember.
>
> I guess it would be much more easy to do that if Emacs could use for
> example wxWidgets.

You're just throwing stuff at a wall to see what sticks, without
stopping to consider whether what you're saying makes sense.  wxWidgets
(which is just another graphical toolkit) has nothing to do with what
you're replying to:

>> shows you a lot of features when they might be useful.  So you don't
>> have as much to learn and remember.

Re: Efforts to attract more users?

[Lennart Borgman]

On Sun, Jul 11, 2010 at 5:49 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>>> Also, one advantage of Eclipse's GUI interface is that it shows you a
>>> lot of features when they might be useful.  So you don't have as much
>>> to learn and remember.
>>
>> I guess it would be much more easy to do that if Emacs could use for
>> example wxWidgets.
>
> You're just throwing stuff at a wall to see what sticks, without
> stopping to consider whether what you're saying makes sense.  wxWidgets
> (which is just another graphical toolkit) has nothing to do with what
> you're replying to:

I think you could write something much more useful if you tried to
understand what I am saying.

>>> shows you a lot of features when they might be useful.  So you don't
>>> have as much to learn and remember.
>

Re: Efforts to attract more users?

[joakim]

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

> On Fri, Jul 9, 2010 at 5:05 AM, Richard Stallman <rms@gnu.org> wrote:
>> The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
>> them, but maybe we still lack some.
>>
>> I saw it once, and it used tabs a lot for switching between different views.
>> We need to be able to do that too.
>>
>> Also, one advantage of Eclipse's GUI interface is that it shows you a
>> lot of features when they might be useful.  So you don't have as much
>> to learn and remember.
>
> I guess it would be much more easy to do that if Emacs could use for
> example wxWidgets.

I used wxWidgets a lot a couple of years ago when contributing to a midi
sequencer. My opinion is that there would be no gain in converting any
GTK project to wxWidgets. GTK is already cross-platform. wxWidgets uses
GTK as its native peer set. Thus, wxWidgets is a subset of GTK,
widget-wise anyway. Starting a new project from scratch is a slightly
different story.

>
-- 
Joakim Verona

Re: Efforts to attract more users?

[Eric M. Ludlam]

On 07/08/2010 11:05 PM, Richard Stallman wrote:
> The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
> them, but maybe we still lack some.

In some ways CEDET is "better" that Eclipse (code completion in C/C++ is 
better), and in others it falls behind, such as project management. 
(This I gather from comments I've read).

Quite a while ago I realized I didn't have time to work on both the 
infrastructure that is CEDET, and user interfaces that use the 
infrastructure.  Instead I'd write small tools that use the 
infrastructure in different ways to make sure everything was working 
correctly.  A side effect is that CEDET feels like a big collection of 
very different little programs that have to be learned separately.

What I'd like to tackle this winter is to try and figure out a more 
cohesive interface to the suite of underlying tools.  The reason is that 
project management, code completion/parsing/navigation and template 
based code generation (for Makefiles) is tightly bound.  The use of UML 
for understanding and writing code is tighly bound to code parsing, 
template based code generation, and project management.  Having these 4 
items be completely separate with different makes these dependencies 
unclear, and makes learning the tools appear more complicated that it 
really is.

Eric

Re: Efforts to attract more users?

[Alex Ott]

Re

Eric M. Ludlam  at "Fri, 09 Jul 2010 08:05:32 -0400" wrote:
 EML> On 07/08/2010 11:05 PM, Richard Stallman wrote:
 >> The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
 >> them, but maybe we still lack some.

 EML> In some ways CEDET is "better" that Eclipse (code completion in C/C++ is better), and in
 EML> others it falls behind, such as project management. (This I gather from comments I've
 EML> read).

The biggest problem with CEDET is speed, and complexity of
installation/configuration for projects - this is most often called
problem, that I got as response for my articles and blog posts

P.S. you can read some of comments at
http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html (JS is required)

-- 
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/           http://alexott.net
http://alexott-ru.blogspot.com/

Re: Efforts to attract more users?

[Aneesh Kumar K. V]

On Fri, 09 Jul 2010 14:23:24 +0200, Alex Ott <alexott@gmail.com> wrote:
> Re
> 
> Eric M. Ludlam  at "Fri, 09 Jul 2010 08:05:32 -0400" wrote:
>  EML> On 07/08/2010 11:05 PM, Richard Stallman wrote:
>  >> The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
>  >> them, but maybe we still lack some.
> 
>  EML> In some ways CEDET is "better" that Eclipse (code completion in C/C++ is better), and in
>  EML> others it falls behind, such as project management. (This I gather from comments I've
>  EML> read).
> 
> The biggest problem with CEDET is speed, 

This is one of the main issue i also have. I would really like some of
the CEDET related operation pushed to background and make it don't
effect my editing task. But otherwise I am really happy with the
feature provided.

-aneesh

CEDET speed issues [was Re: Efforts to attract more users?]

[Eric M. Ludlam]

On 07/09/2010 10:33 AM, Aneesh Kumar K. V wrote:
> On Fri, 09 Jul 2010 14:23:24 +0200, Alex Ott<alexott@gmail.com>  wrote:
>> Re
>>
>> Eric M. Ludlam  at "Fri, 09 Jul 2010 08:05:32 -0400" wrote:
>>   EML>  On 07/08/2010 11:05 PM, Richard Stallman wrote:
>>   >>  The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
>>   >>  them, but maybe we still lack some.
>>
>>   EML>  In some ways CEDET is "better" that Eclipse (code completion in C/C++ is better), and in
>>   EML>  others it falls behind, such as project management. (This I gather from comments I've
>>   EML>  read).
>>
>> The biggest problem with CEDET is speed,
>
> This is one of the main issue i also have. I would really like some of
> the CEDET related operation pushed to background and make it don't
> effect my editing task. But otherwise I am really happy with the
> feature provided.

When CEDET is all-on, it certainly is busy anytime it first hits a 
project.  It has to parse all the files and discover the extent of your 
project.  In general, it postpones doing stuff as long as possible into 
idle time.  If a user opens some new big file in some big project for 
the first time, scrolls down and hits "complete" on a line, it will go 
off into la-la land for a while to perform the operation.

If the user instead opens that project browses around, gets a cup of 
coffee, and comes back and asks for a completion, it will be quite fast, 
often less than a second even on a relatively large project (think Linux 
Kernel sized.)

When CEDET is doing busy-work during idle time, it should always be 
interruptible.  If you press something like C-v or other nav command, it 
should stop and go do that instead.  If it doesn't then there is clearly 
a loop in part of the code that needs the interrupt handler added.  I've 
noticed this parsing big files sometimes but haven't found a good 
candidate spot to add the check.

If a particular kind of completion always takes a long time, there is a 
profiler setup command you can use to capture your case for analysis in 
semantic-elp.el.  It will save the results making it easier to share the 
results.

My longer term plans involve pushing chunks of the busy work off to a 
separate process to avoid much of these problems.  I also need the 
separate process to offload the database information from the Emacs 
process, keeping most of it on disk unless asked-for.  Super large 
projects (like what I work on at work) will cause your whole machine to 
slow down because Emacs' working set gets so huge.  (Eight Gig And 
Constantly Swapping?)

My current thoughts on making this work is to create a separate 
standalone program to be run as service, much the way databases like 
Postgres is a service.  It would fire off multiple "emacs -batch" slaves 
running CEDET which it would use to collect and process data.  It would 
then manage disk files of Tag data, possibly in some new format.  User 
run Emacses would also run CEDET, and connect to this service as a 
classic semanticdb backend.  To me, this seems like the only way to 
maximize code re-use while also getting the desired work offload from 
the main Emacs process.

I'll probably start digging into that seriously around November this 
year, but I'll be happy to discuss it before then if anyone has ideas 
for implementation short-cuts, etc.

Eric

Re: Efforts to attract more users?

[Leo]

On 2010-07-09 13:23 +0100, Alex Ott wrote:
> The biggest problem with CEDET is speed, and complexity of
> installation/configuration for projects - this is most often called
> problem, that I got as response for my articles and blog posts

I am dying to see Emacs having a general-purpose powerful lisp as its
foundation to build things upon.

Leo
-- 
Any Emacs contains an ad hoc, informally-specified, bug-ridden, slow
implementation of half of Common Lisp.

Re: Efforts to attract more users?

[Tom Tromey]

>>>>> "RMS" == Richard Stallman <rms@gnu.org> writes:

RMS> The Eclipse IDE has some nice features.  Maybe CEDET gives us some of
RMS> them, but maybe we still lack some.

RMS> I saw it once, and it used tabs a lot for switching between
RMS> different views.  We need to be able to do that too.

RMS> Also, one advantage of Eclipse's GUI interface is that it shows you a
RMS> lot of features when they might be useful.  So you don't have as much
RMS> to learn and remember.

I've used both Eclipse and Emacs for long stretches.  For instance, I
did most of my Classpath hacking in Eclipse for about 2 years.

I wouldn't say that perspectives or the GUI are strong features of
Eclipse.  They are ok-ish at best.  The Eclipse editor is notably bad,
but this is compensated for by other features.

I agree with you that the discoverability of Eclipse is better than that
of Emacs.  It still is not super, but it is certainly simpler in Eclipse
to figure out how to check out a new project from a CVS server that
you've never used before -- there is a wizard to walk you through all of
it, including letting you see what modules and branches exist.  (Some of
Eclipse's advantages here have been partially negated by vc-dir.)

The big feature in Eclipse that I loved was its excellent Java
environment.  The compiler works while you type.  It can show errors
immediately, suggest correct completions, show javadoc for the method
named under point in a popup, do simple refactorings.  The TAGS-like
feature is always up-to-date, even when you haven't saved buffers.

The CDT (Eclipse's C/C++ plugin) has similar features, but I have not
used it as much.  In the past it wasn't nearly as good as the Java
support, but I hear it has gotten better in recent years.


I still haven't used CEDET in a real way (my impression is that it is
still mostly a lot of infrastructure and no applications -- ?).  So, I
don't know how it compares.  Once nice thing about the Eclipse compiler
is that it provides both analysis and code-generation, so whenever you
save your buffers you are basically ready to start debugging.  (This is
only true for Java, not for C++.)


My view is that there are a few things holding Emacs back from
Eclipse-like awesomeness.  Here they are in the hopes that someone with
more time than me will fix them :-)

* Lack of any notion of a project.  .dir-locals is a step in that
  direction, but only a small one.  A bunch more things should be
  project-specific:

  * TAGS files.
  * Compilation commands and buffer.
  * Debugger commands and buffer.
  * Bug database searches.  (Emacs has nothing here, but you can
    hack it together with w3m; setting this up should be a lot simpler.)

  I could probably make most of this work already with the right
  buffer-local settings and some lisp hackery.  But, I really shouldn't
  have to.

* TAGS should auto-update at least on buffer save, maybe even dynamically.
  (I've made various failed stabs at this over the years.)

* In Eclipse you can set up a new-file skeleton.  This is nice for new
  users because it means their new files have the correct copyright
  header, etc, without any work.  In Emacs you have to set this up by
  hand.

* More things should be async; in fact, async operation should generally
  be the default, when possible.  Emacs has gotten a lot better here,
  though there is still the occasionally annoying blocking delay.
  Saving buffers is sometimes slow (when VC kicks in to run git status
  or something like that); GNUS is a perennial pain; I think I filed a
  few bugs along these lines.

* In Eclipse, compilation errors show up in the fringe of the
  appropriate buffer.  This is a nice feature.  Eclipse has a second
  non-scrolling fringe that shows markers for the whole buffer; you can
  click on these markers to jump to that position in the code.  So, you
  can see at a glance how many errors there are in a given file.

  In many cases these markers also have a "quick fix" option -- for
  simple errors you can just click and Eclipse will fix your code
  without you having to type at all.

Tom

RE: Efforts to attract more users?

[Drew Adams]

> I'm not sure if Emacs is attracting new users the way it used to be.

You're not sure.  Neither is anyone else.

> Certainly search volume has been going downhill for more than 
> several years (http://www.google.com/trends?q=emacs), and yet I
> don't hear this issue being addressed here strongly enough.

What issue?  What isn't strong enough for your taste?  Be specific.

While you're at it, look at the Google trends for "software", "electronics",
"web", "computer", "hand-held", "xml", "java", "lisp", "oracle", "ibm", "linux",
"gnu", "open source", "intellectual property", "programming", "database", "user
interface", "compiler", and "monitor".

These are all "going downhill" in a worrisome way, the same as the Emacs trend.

So are the trends for "music", "art", "genetics", "mathematics", "biology",
"law", "disease", "united states", "europe", "washington", "new york", "san
francisco", "mountains", "human rights", "literature", "magic mushrooms",
"science", "agriculture", "industry", "commerce", "television", "university",
"education", and "learning".

Someone should alert the UN *now* - these important terms are not being defended
anywhere nearly strongly enough.  "United nations" itself is on the decline, but
"un" is up.

On the other hand, trends for the following do not have a pronounced downward
trend: "god", "eggs", "peace", "war", "profit", "peanut butter", "heaven",
"crisis", "equality", "taxes", "liberty", "visual studio", "chocolate",
"market", "china", "apple", "shanghai", "paris", "darwin", "cassoulet", "bob
dylan", "rolling stones", "microsoft", and "coca cola".

It's hard to find anything flatter than "beer", "hamburger", "beauty", and
"house", but "woman" and "breakdown" come close.  Oh, and "duration" is also
here for the duration.

"Pizza" climbs steadily.  "Watermelon" buzzes only in the northern-hemisphere
summer, mirroring "depression" and "plow".  "Riviera" is apparently only
interesting when no one is there.  "Kama sutra" has had a slow decline, except
for a worm spike.  "Martin luther king", "valentine", "easter", and "aids" blip
onto the radar only for their nominal days.

"Skill" is slowly on the rise, but "knowledge" is in precipitous decline.
"Wisdom" pretends to steadily motor on, but "enlightenment" has no idea which
way to turn.

The good news is that the buzz for "happiness", "porn", "google", "twitter",
"facebook", "iphone", "texting", "walmart", "mcdonalds", "carrefour", and "gin
tonic" deafens!

"trends" itself is slowly on the way down.  Write a thesis on it.

Summary: Emacs "going downhill" does not seem particularly noteworthy, at least
as judged by your demonstration.

Maybe the Emacs buzz, like the buzz around some of the other terms, is in fact
slowyly droning down.  So what?  Buzz does not equate to attraction of new
users.  And attraction of new users is only one among many things that Emacs
development should aim for.

Periodically someone posts a message like yours here.  There is a brief flurry
of messages suggesting that Emacs urgently needs to add this or that feature of
some other editor, UI, IDE, program, website or video game.  The thread then
goes downhill rather quickly.

I would google-trend "emacs trend emacs-devel" right now, but I'm over-quota.

Re: Efforts to attract more users?

[Dan Nicolaescu]

Ken Hori <fplemma@gmail.com> writes:

> I'm not sure if Emacs is attracting new users the way it used to be.
> Certainly search volume has been going downhill for more than several years
> (http://www.google.com/trends?q=emacs), and yet I don't hear this issue being
> addressed here strongly enough.  I hate to ask pedestrian sort of a question
> like this, but are there any efforts specifically to attract more users?

Emacs is very decentralized, things get done because a person starts
something, and then other people might join.

If you have ideas what to do, by all means, just go ahead!

There are no direct efforts to attract users, more like efforts to
keep up with the latest technologies (Gtk+, dbus, etc), improve
usability, etc.

It would be nice if we could attract more developers, more developers,
means more interesting things done to attract users.
There are many people developing various elisp packages, but they are
mostly designed as add-ons, not with integration into emacs in mind.  
It would help a lot if we could convince more people to develop that way.

org-mode is a great example of development, the rate that it's adding
features, and how it integrates with just about anything is
astonishing.  We could use more of that... 

Re: Efforts to attract more users?

[Fren Zeee]

On Thu, Jul 8, 2010 at 4:28 PM, Dan Nicolaescu <dann@gnu.org> wrote:
>
> Ken Hori <fplemma@gmail.com> writes:
>
> > I hate to ask pedestrian sort of a question
> > like this, but are there any efforts specifically to attract more users?

Perhaps, by writing more colorful manuals more users could be attracted. :))

While on this topic, I googled for 15th edition of emacs.pdf but could
not find it. The 14th edition had blue hyperlinks but 16th is devoid
of it. A quick download link would be appreciated. Is there a page
where all the older official compiled version of emacs and its manuals
are stored ? Whats the command to check-out working sources for the
earliest compilable version of emacs ? I want to try that. I am
familiar with the following for example.

svn checkout http://software.googlecode.com/svn/trunk/ software-read-only

Cheers
Franz Xe

Re: Efforts to attract more users?

[Bernardo Barros]

I think if a person stay some time with emacs he/she will find it
fantastic. But I know people that just give up because they don't see
all the things Emacs can do, they just see a text editor that is
different from any standard, including the documentation terminology
and shortcuts. It mentions keys that just don't exist anymore, have
its own terminology for simple things like "copy" and "paste", and a
lot of it'sa shortcuts where design to keyboards that are not
manufactured anymore.

But they could leave before they realise they can customize every bit
of the program, and that this terminology has its charm after all.

I don't know... maybe just taking a look at the keyboards, see how
they really are today, and the largely used terminology shoud help a
lot.

2010/7/8 Fren Zeee <frenzeee@gmail.com>:
> On Thu, Jul 8, 2010 at 4:28 PM, Dan Nicolaescu <dann@gnu.org> wrote:
>>
>> Ken Hori <fplemma@gmail.com> writes:
>>
>> > I hate to ask pedestrian sort of a question
>> > like this, but are there any efforts specifically to attract more users?
>
> Perhaps, by writing more colorful manuals more users could be attracted. :))
>
> While on this topic, I googled for 15th edition of emacs.pdf but could
> not find it. The 14th edition had blue hyperlinks but 16th is devoid
> of it. A quick download link would be appreciated. Is there a page
> where all the older official compiled version of emacs and its manuals
> are stored ? Whats the command to check-out working sources for the
> earliest compilable version of emacs ? I want to try that. I am
> familiar with the following for example.
>
> svn checkout http://software.googlecode.com/svn/trunk/ software-read-only
>
> Cheers
> Franz Xe
>
>

Re: Efforts to attract more users?

[Stefan Monnier]

> I'm not sure if Emacs is attracting new users the way it used to be.
> Certainly search volume has been going downhill for more than several years
> (http://www.google.com/trends?q=emacs),

What are the units in the vertical direction?


        Stefan

Re: Efforts to attract more users?

[Bernardo Barros]

1.0 is the mean of the period

2010/8/2 Stefan Monnier <monnier@iro.umontreal.ca>:
>> I'm not sure if Emacs is attracting new users the way it used to be.
>> Certainly search volume has been going downhill for more than several years
>> (http://www.google.com/trends?q=emacs),
>
> What are the units in the vertical direction?
>
>
>        Stefan
>
>

Re: Efforts to attract more users?

[Stefan Monnier]

>>> I'm not sure if Emacs is attracting new users the way it used to be.
>>> Certainly search volume has been going downhill for more than several years
>>> (http://www.google.com/trends?q=emacs),
>> What are the units in the vertical direction?
> 1.0 is the mean of the period

So units are a ratio w.r.t all the searches.  Is there a way to know the
actual number of searches to which this corresponds?  This way we could
tell whether the number of searches is also going down (since it might
still be going up if the ratio is going down slower than the total
number of searches increases).


        Stefan

Re: Efforts to attract more users?

[Lennart Borgman]

On Mon, Aug 2, 2010 at 10:15 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>>> I'm not sure if Emacs is attracting new users the way it used to be.
>>>> Certainly search volume has been going downhill for more than several years
>>>> (http://www.google.com/trends?q=emacs),
>>> What are the units in the vertical direction?
>> 1.0 is the mean of the period
>
> So units are a ratio w.r.t all the searches.  Is there a way to know the
> actual number of searches to which this corresponds?  This way we could
> tell whether the number of searches is also going down (since it might
> still be going up if the ratio is going down slower than the total
> number of searches increases).


Seems like google does not want to display the absolute numbers:

 http://googlesystem.blogspot.com/2008/06/google-trends-with-numbers.html

It also looks like Emacs is loosing ground to vim:

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

Adding "eclipse" to the search shows that Eclipse is going up and that
both vim and emacs are searched for much less ....

Though the sun seems to be included in the eclipse searches. ;-)

Re: Efforts to attract more users?

[Jay Belanger]

Lennart Borgman <lennart.borgman@gmail.com> writes:
...
> It also looks like Emacs is loosing ground to vim:
>
>  http://www.google.com/trends?q=emacs,vim&ctab=0&geo=all&date=all&sort=0

The lettered references on the right would seem to indicate that a lot
of the "vim" searches have nothing to do with the text editor, though.

Re: Efforts to attract more users?

[Andreas Röhler]

Am 02.08.2010 22:15, schrieb Stefan Monnier:
>>>> I'm not sure if Emacs is attracting new users the way it used to be.
>>>> Certainly search volume has been going downhill for more than several years
>>>> (http://www.google.com/trends?q=emacs),
>>>>          
>>> What are the units in the vertical direction?
>>>        
>> 1.0 is the mean of the period
>>      
> So units are a ratio w.r.t all the searches.  Is there a way to know the
> actual number of searches to which this corresponds?  This way we could
> tell whether the number of searches is also going down (since it might
> still be going up if the ratio is going down slower than the total
> number of searches increases).
>
>
>          Stefan
>
>
>    

Hi Stefan,

with respect to attracting new users, Emacs could
do better right at the entrance:

Emacs tutorial starts explaining

  NOTICE: The main purpose of the Emacs tutorial is to teach you
  the most important standard Emacs commands (key bindings).

and proceeds that way walking the desert.

My suggestion: leave the keys aside at the very beginning,
tell user what Emacs is and why it should be used.

The WHY for me is its extensibility. Instead of keys,
I'd show with the first lines, how a function like "Go
to the end" is easily changed:

(defun stop-always-two-lines-before-end ()
   "This function will put the cursor at the second line from bottom up. "
   (interactive)
   (end-of-buffer)
   (forward-line -2))

BTW a missing function `backward-line' points to another
issue, Emacs may enhance in order to attract new users.

Thanks a lot for all your efforts

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/

Re: Efforts to attract more users?

[Stuart Hacking]

On 3 August 2010 07:40, Andreas Röhler <andreas.roehler@online.de> wrote:
>
> Hi Stefan,
>
> with respect to attracting new users, Emacs could
> do better right at the entrance:
>
> Emacs tutorial starts explaining
>
>  NOTICE: The main purpose of the Emacs tutorial is to teach you
>  the most important standard Emacs commands (key bindings).
>
> and proceeds that way walking the desert.
>
> My suggestion: leave the keys aside at the very beginning,
> tell user what Emacs is and why it should be used.

Would it be a simple first step to promote the 'Emacs Guided Tour' to
the top of the help menu? This contains a run-down of features that
would be interesting to new users. (By default this is on the start
page, but if you disable the start page then it takes two clicks to
find.)

Would anyone object to renaming the 'Emacs Tutorial' to 'Learn Emacs Shortcuts'?

--Stuart