Re: [Bug-zile] Windows binaries for Zile

[Reuben Thomas]

Andrzej Jan Kutylowski wrote:
>
> Hello,
> I appreciate obtaining comprehensive information from you off the list
> and would like to add a comment related in part to your efforts with Zile:
>
>
> On 13.03.2012 00:13, Reuben Thomas wrote:
>>
>> On 12 March 2012 18:40, Andrzej Jan Kutylowski
>> <address@hidden>  wrote:
>>>
>>>
>>> I find Emacs very comprehensive and multifaceted.
>>
>>
>> Of course. Zile is intended as a substitute when Emacs is not
>> available. The intention is that if Emacs can be used, it should be.
>> After all, it can run comfortably on terminals, it can be used to edit
>> remote files, and it can be used to edit files as the superuser. There
>> are very few times you need to use another editor.
>
>
>
> Imagine undergraduate students involved in some data analysis tasks
> without formal education: some of them shall enter graduate program.
> At first stage I would point them to Zile, without hiding existence of
> emacs. I would want them to start with Emacs keystrokes and basic concepts.
>
> There is a plethora of other editors: my vantage point is easy intro to
> Emacs. Since you are a programmer, you probably cannot imagine how
> people without any exposure to any form of programming except menus feel,
> think and reason. In my view they should start with a small, neat, tiny,
> unobtrusive editor--Emacs like. Perhaps 5% will move upward: this would be
> enough to secure progress.

I think a much more profitable route is to improve Emacs's default
interface. Indeed, I begin to suspect that this discussion should
really take place on an Emacs list.

There are a few reasons why this would be a good idea:

1. Improvements to Emacs's default interface benefit all novice users.
(Expert users generally don't care what the default interface looks
like, as they can (and probably have) customized it to their taste.
For example, I hide the menus or toolbar.)

2. This is much more likely to be maintained and updated. There have
been many customized versions of Emacs over the years, but few have
been maintained in the long term.

3. It's important not to underestimate how hard it is to install a
specialised Emacs; much better if a user can sit down at a new
computer, install Emacs (or perhaps it is already installed) and just
start using it in its default configuration. I have found that even as
an expert user I try, over time, to remove customization from my Emacs
configuration where possible, so that when I have to use Emacs on a
new computer I will be able to be productive without installing my
special setup.

> Emacs normally is not available in settings I have just described.

Again, if the installation of Emacs can be improved, that would be
good. It should be as easy as installing any other native application
on a GNU/Linux distro, or Windows, or Mac OS. My experience is that
this is not currently the case on Windows.

Many Emacs users are not primarily programmers, but use it as a
customisable and powerful front-end for other tools, e.g. statistics
packages. I think it's much more productive to concentrate on
improving Emacs for these users than trying to invent something new. I
suggest that a good model is to produce the following:

1. Installation instructions.

2. A tutorial.

3. Some elisp which customises Emacs to be the environment you want,
probably in the form of init files.

and then to engage in a continuous process of a) working out ways to
stop needing customisation and b) feeding improvements back upstream.
So for example, a couple of steps in the "how-to-install" instructions
might turn into some instructions on the official Emacs web pages, or
even some code in the installer which automates the relevant steps. To
give another example, some elisp customistion might turn into a patch
to a statistics package front-end.

One final suggestion: have you looked at TeXMacs?

-- 
http://rrt.sc3d.org