RE: emacs mode line suggestions

["Drew Adams" <drew.adams@oracle.com>]

> > This is help-gnu-emacs. It's for getting help about using Emacs.
> 
> But it should not be too disturbing to gauge Emacs user's views on
> certain issues. The nature of a Help group often means there are more
> new users and new users are often a catalyst for new and good 
> ideas. Any half decent news reader features thread kill and keeping
> most in one or two threads is not disrupting. In addition discussion
> threads on functionality are often educational - many such threads
> have taught me new things about how and why things are in Emacs.

You can do as you like, of course; I'm not moderating this mailing list. I'm
really just trying to help.

The point is that such discussions are part of the _purpose_ of emacs-devel, and
help-gnu-emacs has a different purpose. If you want to influence Emacs
developers to make changes, emacs-devel is the place. To get changes made, there
will ultimately need to be a discussion at emacs-devel anyway - might as well
put it there to begin with.

Can discussion of possible Emacs improvements be educational and helpful for
users, new and old? Yes, of course. Absolutely. Users who are interested in
reading or participating in such discussions can subscribe to emacs-devel.
Personally, I encourage that. In the world of Emacs _in particular_, there is no
clear separation between user and designer or implementor.

Any and all users - new and old - who are interested in such discussion: Please
subscribe to emacs-devel, whether you just want to lurk or you want to
contribute. That will help improve both emacs-devel and Emacs. People, myself
included, sometimes complain that emacs-devel is not open enough or is too set
in its ways. The remedy for that is for more people to participate.

Like it or not, there is no substitute for arguing your case at emacs-devel for
a particular change you want. If you think Emacs needs fresh ideas and you have
some, bring them to emacs-devel, by all means. Be prepared to support them with
clear, logical argument, of course. And patience is advised: "You can't always
get what you want, but if you try sometimes well you just might find you get
what you need."

FWIW, I have contributed countless suggestions to emacs-devel for improving
(IMO) Emacs. Relatively few have been incorporated. But emacs-devel is still the
most effective place to discuss such things, IMO, not help-gnu-emacs. There is
no guarantee that your suggestions will be followed at emacs-devel - the
contrary is more likely. But they will be read and seriously considered.

Another, indirect way to influence Emacs development is to implement the changes
you propose and make them available somewhere in a library. That ultimately can
affect Emacs development by being food for thought or through direct inclusion
someday.

The developers who build and distribute Emacs can sometimes be persuaded by
sound argument if the idea is a good one, but working code that _shows_ them
what you want can be even more persuasive.

Even if your third-party code never changes the Emacs distribution, it can help
other users, and they will give you valuable feedback to further your own ideas
of improvement. There are many good libraries out there that have never been
added to the Emacs distribution and probably never will be. Yet they indirectly
affect the evolution of Emacs.

This is because the real designers and developers of Emacs are a much wider
group than those who modify and distribute the Emacs source code. All user
feedback and bug reports are part of Emacs development, as are third-party Emacs
libraries. 

This is of course true generally, but it is all the more true for Emacs, where
many (most?) users create their own Emacs through customization,  coding, and
reuse of third-party code. Emacs's users are its developers. If you are
interested in how Emacs evolves, please join the discussion at emacs-devel.