Is Emacs becoming Word?

Is Emacs becoming Word?

[Greg Novak]

As a longtime emacs user, I would like to register a complaint about
the direction of Emacs.  This is probably a cry in the wilderness, but
here goes:

Starting with Emacs21, the program has been creeping toward becoming a
WYSIWYG editor, instead of sticking to its roots as a _TEXT_ editor.

Some of these features are cool and useful: Eg, I use the ability to
display PNG files in a buffer to look at previews of math I've typeset
with Latex in the same buffer as the Latex source.  Cool, and useful.

While I'm not against implementing these wacky new feature, I request
that they remain _off by default_.  Today when I was editing source
code and tried to type pi/2 in a buffer, Emacs replaced it with some
special character that appeared as "1/2" as a single character.
Needless to say, this is not what I wanted and I find it quite
offensive that this is happening while editing source code.  

The other day I was editing Lisp code and found that instead of the
usual paren highlighting, Emacs was highlighting the entire enclosed
expression.  This is nice, and I can see how some people would find it
useful, but I'm used to the usual, subtle, paren highlighting.
Therefore it seemed like my code had just gotten back from Las
Vegas.  Again, I would have preferred "off by default."

I've had a long, sometimes rocky, but mostly loving relationship with
Emacs.  I find these developments troubling.

Ok, that's all.  Thanks for reading.
Greg

Re: Is Emacs becoming Word?

[Joe Corneli]

No.  It is not.  Word can not be used for programming.

But people who write new graphical or other features *should* make an
efort to tell users how to turn the features off.

Maybe there should be a way to mark up a new feature as such
(something like the autoload construct) that will cause a "What just
happened?" message to be displayed when a new feature is run, until
the feature is either "accepted" (at which point the messages go away)
or "rejected" (at which point the feature will no longer activate).
Something like this would certainly help with the weird WYSIWYG
behavior that has newly been added to TeX modes (and other modes??).

Lately they have been saying (about Las Vegas) that whatever happens
here, stays here.  Unless you win big, of course, in which case you
probably take your money home with you.  But that happens pretty
rarely.

Re: Is Emacs becoming Word?

[nfreimann]

I find them very useful. There is always a instance of emacs running on my system. 
I can do word processing without starting another application. Best of all the data
is portable from gnu/linux to winxp and vice versa. For most of my word processing
emacs is sufficient. Thanks to the developers.

-- 
Regards
-NF

Re: Is Emacs becoming Word?

[David Kastrup]

Joe Corneli <jcorneli@math.utexas.edu> writes:

> No.  It is not.  Word can not be used for programming.
>
> But people who write new graphical or other features *should* make
> an efort to tell users how to turn the features off.

C-h C-n (in Emacs-22-to-be) or C-h N (I believe, in Emacs-21).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is Emacs becoming Word?

[Joe Corneli]

   Joe Corneli <jcorneli@math.utexas.edu> writes:

   > No.  It is not.  Word can not be used for programming.
   >
   > But people who write new graphical or other features *should* make
   > an efort to tell users how to turn the features off.

   C-h C-n (in Emacs-22-to-be) or C-h N (I believe, in Emacs-21).


For a second I thought that my thought about autoload/autodisable
features was going to be listed there.

I think that a *lot* of new features do not get listed in the NEWS
file.

Re: Is Emacs becoming Word?

[Eli Zaretskii]

> From: Joe Corneli <jcorneli@math.utexas.edu>
> Date: Fri, 25 Mar 2005 15:30:42 -0600
> 
> I think that a *lot* of new features do not get listed in the NEWS
> file.

All user-visible new features should be there, so please report any
omissions as bugs (to the appropriate forums/mailing lists).

Re: Is Emacs becoming Word?

[David Kastrup]

Joe Corneli <jcorneli@math.utexas.edu> writes:

>    Joe Corneli <jcorneli@math.utexas.edu> writes:
>
>    > No.  It is not.  Word can not be used for programming.
>    >
>    > But people who write new graphical or other features *should* make
>    > an efort to tell users how to turn the features off.
>
>    C-h C-n (in Emacs-22-to-be) or C-h N (I believe, in Emacs-21).
>
>
> For a second I thought that my thought about autoload/autodisable
> features was going to be listed there.
>
> I think that a *lot* of new features do not get listed in the NEWS
> file.

I don't think so.  So if you want to convince me, find a few new
features that are not listed there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is Emacs becoming Word?

[Joe Corneli]

I don't think that it tells you to do

 (setq font-lock-maximum-decoration '((tex-mode . 2) (latex-mode . 2) (t . t)))

in order to have latex buffers look "normal", so I think that's one.

The stuff about "undo" is in there, but seem to explain how to make
the messages go away (and have undo information always discarded
automatically, which is the best thing I can think of to do with it).

These are perhaps the two most noticable changes to Emacs I've seen
over recent months.

At any rate, looking through the news file is kind of like looking for
a needle in a haystack.  It would be much nicer to have contextual
help on new commands.  Eg. the first time \pi turns into a greek
symbol, or the first time that you get some message about undo
buffers, something pops up -- maybe a talking paperclip, who knows, or
a freakin' thumb-tack if the paperclip is off-limits! -- and tells you
what's going on.

Re: Is Emacs becoming Word?

[Gian Uberto Lauri]

>>>>> "JC" == Joe Corneli <jcorneli@math.utexas.edu> writes:

JC>  Eg. the first time \pi turns into a greek
JC> symbol,

I   disagree  with  the   whole  argument   except  for   having  some
documentation that  tells you how to  replace an old  behaviour if you
don't like the new.

But US-ASCII bound people should consider that there are a few squared
meters  of  the  world   where  people  has  alphabets  that  includes
characters that did not took place in the holy 94 set.

Some  of these  people  speak  an almost  unknown  language that  uses
strange gliphs  as 

Re: Is Emacs becoming Word?

[Joe Corneli]

   >>>>> "JC" == Joe Corneli <jcorneli@math.utexas.edu> writes:

   JC>  Eg. the first time \pi turns into a greek
   JC> symbol,

   I   disagree  with  the   whole  argument   except  for   having  some
   documentation that  tells you how to  replace an old  behaviour if you
   don't like the new.

That IS the whole argument.  Anyone who says differently is selling
something.

   They use  them in their everyday  life. TeX has  grown and understands
   them.  It's fair that Emacs handles  them the right way and I love the
   True One Editor when it does it.

Have cake?  Eat it, too.

Re: Is Emacs becoming Word?

[David Kastrup]

GianUberto.Lauri@eng.it (Gian Uberto Lauri) writes:

>>>>>> "JC" == Joe Corneli <jcorneli@math.utexas.edu> writes:
>
> JC>  Eg. the first time \pi turns into a greek
> JC> symbol,
>
> I disagree with the whole argument except for having some
> documentation that tells you how to replace an old behaviour if you
> don't like the new.
>
> But US-ASCII bound people should consider that there are a few
> squared meters of the world where people has alphabets that includes
> characters that did not took place in the holy 94 set.

Well, so what?  Input encodings are not switched on by default, so
there is no reason to defend what is not a reality.

> They use them in their everyday life. TeX has grown and understands
> them.  It's fair that Emacs handles them the right way

But it does not do so without being asked, and that is good.

> P.S.

> I hope that nobody will consider stop emacs-bidi development as a
> good way to fight middle east terrorists... Mossad could get upset.

Well, emacs-bidi is not exactly very active or visible.  Luckily, in
Hebrew my name דוד is palindromic, so it does not affect me too much.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Bad iso-2022-jp encoding (was: Is Emacs becoming Word?)

[Reiner Steib]

On Sat, Mar 26 2005, Gian Uberto Lauri wrote:

| Content-Type: text/plain; charset=iso-2022-jp
| X-Mailer: VM 7.18 under Emacs 21.3.50.1

> [...] strange gliphs as ñ yust [...] ¡Carramba! [...]  A few more, a
> smaller number indeed, uses π [...]

Something is wrong either with your Emacs or VM.  The charset should
most probably should have been iso-2022-7bit instead of iso-2022-jp.
According to my Emacs, iso-2022-jp isn't suitable to encode those
characters.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Is Emacs becoming Word?

[David Kastrup]

Joe Corneli <jcorneli@math.utexas.edu> writes:

> I don't think that it tells you to do
>
>  (setq font-lock-maximum-decoration '((tex-mode . 2) (latex-mode . 2) (t . t)))
>
> in order to have latex buffers look "normal", so I think that's one.

Well, it says

    ** TeX modes:
[...]
    *** verbatim environments are now highlighted in courier by font-lock
    and super/sub-scripts are made into super/sub-scripts.

so the feature _is_ announced, although not how to remove it.  And I
don't see it in the Emacs manual.  Would you be so kind as to file a
bug report?  I could imagine that some people find that annoying, but
am not the right judge because I don't use font lock in the first
place.

> The stuff about "undo" is in there, but seem to explain how to make
> the messages go away (and have undo information always discarded
> automatically, which is the best thing I can think of to do with
> it).
>
> These are perhaps the two most noticable changes to Emacs I've seen
> over recent months.

If you have a particular suggestion how to improve the documentation,
you should send it to emacs-devel at gnu.org.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is Emacs becoming Word?

[Henrik Enberg]

Joe Corneli <jcorneli@math.utexas.edu> writes:

[...]

> I think that a *lot* of new features do not get listed in the NEWS
> file.

It would probably be a bad idea to list every minor change.  The file
would get so large no one would have the patience to read it all.

-- 
Vaya Con Satan

Re: Is Emacs becoming Word?

[Joe Corneli]

I already don't have the patience to read it.

It isn't exactly light reading.  Maybe it could be converted into a
screenplay, and a video could accompany every new release...


   > I think that a *lot* of new features do not get listed in the NEWS
   > file.

   It would probably be a bad idea to list every minor change.  The file
   would get so large no one would have the patience to read it all.

Re: Is Emacs becoming Word?

[Eli Zaretskii]

> From: Henrik Enberg <henrik.enberg@telia.com>
> Date: Sat, 26 Mar 2005 02:30:39 +0100
> 
> It would probably be a bad idea to list every minor change.  The file
> would get so large no one would have the patience to read it all.

No, it won't, since all user-visible changes are already listed there.
The single most important omission is that changes that fix bugs are
not listed.

Re: Is Emacs becoming Word?

[Eli Zaretskii]

> Date: Fri, 25 Mar 2005 10:05:31 -0800
> From: Greg Novak <novak@ucolick.org>
> 
> Starting with Emacs21, the program has been creeping toward becoming a
> WYSIWYG editor, instead of sticking to its roots as a _TEXT_ editor.
> 
> Some of these features are cool and useful: Eg, I use the ability to
> display PNG files in a buffer to look at previews of math I've typeset
> with Latex in the same buffer as the Latex source.  Cool, and useful.
> 
> While I'm not against implementing these wacky new feature, I request
> that they remain _off by default_.

Since you do like some of the ``wacky'' new features, please give a
list of those which you request to be left off by default.  We cannot
possibly guess them, and the two problems you mentioned _are_ already
off by default, see below.

> Today when I was editing source
> code and tried to type pi/2 in a buffer, Emacs replaced it with some
> special character that appeared as "1/2" as a single character.

This is off by default, so you should look into your customizations
and find what turns it on.

> The other day I was editing Lisp code and found that instead of the
> usual paren highlighting, Emacs was highlighting the entire enclosed
> expression.

This feature is off by default as well.  Something in your .emacs
turns it on.

> I've had a long, sometimes rocky, but mostly loving relationship with
> Emacs.  I find these developments troubling.

If these two examples are the only problems that bug you, it seems
like you are jumping to conclusions: the cause of your trouble is your
own customizations, and perhaps also a few packages that are not part
of the normal Emacs distribution.

If there are other WYSIWYG features that you find unhelpful and that
are on by default, please tell what are they.

Re: Is Emacs becoming Word?

[Joe Corneli]

   > While I'm not against implementing these wacky new feature, I request
   > that they remain _off by default_.

   Since you do like some of the ``wacky'' new features, please give a
   list of those which you request to be left off by default.  We cannot
   possibly guess them, and the two problems you mentioned _are_ already
   off by default, see below.

[...]

   > The other day I was editing Lisp code and found that instead of the
   > usual paren highlighting, Emacs was highlighting the entire enclosed
   > expression.

   This feature is off by default as well.  Something in your .emacs
   turns it on.

Saying that things are "off by default" and "something in your .emacs
turns them on" is not really what anyone needs to hear (except _maybe_
Greg Novak, in this particular case - but I'm not sure about that).  I
mean, just for example, running

  (setq font-lock-maximum-decoration 3)

in your .emacs has a different effect on subscripts in LaTeX buffers
now than it did a year ago.

I think the real point is that the same .emacs can produce different
behavior when the emacs version (or environment) changes.

But this is so obvious that no one (except persons who are extremely
confused about how computers work) needs to have it pointed out to
them.  And it is also true & obvious that emacs versions _do_ change.

As hinted at in my message 

 http://lists.gnu.org/archive/html/emacs-devel/2005-03/msg01238.html

in emacs-devel, I find these discussions of "how to turn features off"
to be somewhat tiresome.

There are certainly plenty of legitimate questions (Karl's question
yesterday comes to mind), but then there are also posts that border on
being flame-bait (and which may also contain legitimate questions).

The difference seems to have to do with how low-level the feature
being turned off is (low-level features somehow being less
contentious, remarkably).

In my opinion, it would be better if Emacs handled a considerably
larger portion of "on/off" concerns automatically, on a private,
individual basis.  See the aforementioned post for one set of ideas
and conjectures about how this might be done.

Re: Is Emacs becoming Word?

[Eli Zaretskii]

> From: Joe Corneli <jcorneli@math.utexas.edu>
> Date: Sat, 26 Mar 2005 11:11:40 -0600
> 
>    This feature is off by default as well.  Something in your .emacs
>    turns it on.
> 
> Saying that things are "off by default" and "something in your .emacs
> turns them on" is not really what anyone needs to hear

In this case, the OP was complaining about things that are turned on
by default on him.  So I think the response was appropriate, and
precisely what he needed to hear, since he should look for the reasons
in his own customizations.

Re: Is Emacs becoming Word?

[Greg Novak]

* Eli Zaretskii <eliz@gnu.org> wrote:
> This is off by default, so you should look into your customizations
> and find what turns it on.
> ... 
> This feature is off by default as well.  Something in your .emacs
> turns it on.
> ...
> So I think the response was appropriate, and precisely what he
> needed to hear, since he should look for the reasons in his own
> customizations.

This is the fourth time in this thread that I've been told that I must
have turned on the features myself.  This is in direct conflict with
the information I provided in the original post.  The strange behavior
started after a version upgrade, _not_ after hacking around in my
.emacs file, fooling with any customization options, or anything.  

I object to being told that I must be mistaken about the basic facts
of what happened in my office yesterday.  I'm prepared to guarantee
that my .emacs didn't change one bit in between the time emacs was
behaving "normally" and the time when it started exhibiting "strange"
behavior. 

* Thomas A. Horsley <tom.horsley@att.net> wrote:
> Perhaps not his own customizations: I know (from my experience beating them
> into submission) that the redhat fedora distribution and the suse
> distribution both do wacky stuff to emacs. I was able to fix redhat with my
> .emacs file once I discovered their annoying site-lisp/default.el file, but

It is now clear that this is almost certainly what happened, given the
several posts telling me that I must be suffering from amnesia since I
could only have edited my .emacs file and turned on the features
myself.  Shame on me for changing more than one thing at once;
initially, emacs itself seemed like the most obvious cause of my
trouble, but now it's clear that it's probably the packager who's to
blame. 

> As far as new features being on by default goes, I can understand why
> leaving them on might be a good idea. If I hate them it gives me an
> incentive to read up on them to figure out how to turn them off, and if I
> like them, I'd probably never see them unless they were on by default,

True, but I think a good compromise would be Joe Corneli's idea in the
post he referenced where new features would be "tentatively" turned on
and would explain what they're doing, perhaps in the minibuffer, when
they do something that could be considered "strange."  This could also
include instructions about how to turn the behavior off.

Re: Is Emacs becoming Word?

[Eli Zaretskii]

> Date: Sat, 26 Mar 2005 17:08:04 -0800
> From: Greg Novak <novak@ucolick.org>
> 
> > So I think the response was appropriate, and precisely what he
> > needed to hear, since he should look for the reasons in his own
> > customizations.
> 
> This is the fourth time in this thread that I've been told that I must
> have turned on the features myself.  This is in direct conflict with
> the information I provided in the original post.  The strange behavior
> started after a version upgrade, _not_ after hacking around in my
> .emacs file, fooling with any customization options, or anything.  

There's no conflict here (as you've been told several times): it's
quite possible that something in your .emacs has different effects
before and after the upgrade.

What is important that you should go through your .emacs and look for
customizations that turn on the features that annoy you.  As I already
told here, the Python mode would be my first suspect, unless similar
problems occur in buffers that are not in Python mode.

Re: Is Emacs becoming Word?

[David Kastrup]

Greg Novak <novak@ucolick.org> writes:

> * Eli Zaretskii <eliz@gnu.org> wrote:
>> This is off by default, so you should look into your customizations
>> and find what turns it on.
>> ... 
>> This feature is off by default as well.  Something in your .emacs
>> turns it on.
>> ...
>> So I think the response was appropriate, and precisely what he
>> needed to hear, since he should look for the reasons in his own
>> customizations.
>
> This is the fourth time in this thread that I've been told that I must
> have turned on the features myself.  This is in direct conflict with
> the information I provided in the original post.  The strange behavior
> started after a version upgrade, _not_ after hacking around in my
> .emacs file, fooling with any customization options, or anything.  

As long as you refuse to try the effects of

    emacs -q -no-site-file

there is nothing much that can be done for you.  It is not like I
didn't explain that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is Emacs becoming Word?

[Steinar Børmer]

Greg Novak wrote:

| * Eli Zaretskii <eliz@gnu.org> wrote:
| > This is off by default, so you should look into your customizations
| > and find what turns it on.
| > ... 
| > This feature is off by default as well.  Something in your .emacs
| > turns it on.
| > ...
| > So I think the response was appropriate, and precisely what he
| > needed to hear, since he should look for the reasons in his own
| > customizations.
| 
| This is the fourth time in this thread that I've been told that I must
| have turned on the features myself.  This is in direct conflict with
| the information I provided in the original post.  The strange behavior
| started after a version upgrade, _not_ after hacking around in my
| .emacs file, fooling with any customization options, or anything.

I've seen several cases where a customization in ~/.emacs that's been
there for years (and across several major versions) suddenly stops
working.  That is, the variable might be changed or renamed, and so the
customization that used to work so well suddenly doesn't.  This is
especially common with language or character set settings for people
outside the 7-bit world.

What I'm trying to say is that the reasons some people might have for
saying "It's your customizations" are more diverse than they might
appear.

| I object to being told that I must be mistaken about the basic facts
| of what happened in my office yesterday.  I'm prepared to guarantee
| that my .emacs didn't change one bit in between the time emacs was
| behaving "normally" and the time when it started exhibiting "strange"
| behavior.

As I explain above, sometimes a change in ~/.emacs isn't necessary to
provoke such strangeness.

| * Thomas A. Horsley <tom.horsley@att.net> wrote:
| 
| > As far as new features being on by default goes, I can understand
| > why leaving them on might be a good idea. If I hate them it gives me
| > an incentive to read up on them to figure out how to turn them off,
| > and if I like them, I'd probably never see them unless they were on
| > by default,
| 
| True, but I think a good compromise would be Joe Corneli's idea in the
| post he referenced where new features would be "tentatively" turned on
| and would explain what they're doing, perhaps in the minibuffer, when
| they do something that could be considered "strange."  This could also
| include instructions about how to turn the behavior off.

This would be similar to the features that are currently "disabled" for
new users, such as scroll-left.

-- 
SB

Re: Is Emacs becoming Word?

[Joe Corneli]

   | > As far as new features being on by default goes, I can understand
   | > why leaving them on might be a good idea. If I hate them it gives me
   | > an incentive to read up on them to figure out how to turn them off,
   | > and if I like them, I'd probably never see them unless they were on
   | > by default,
   | 
   | True, but I think a good compromise would be Joe Corneli's idea in the
   | post he referenced where new features would be "tentatively" turned on
   | and would explain what they're doing, perhaps in the minibuffer, when
   | they do something that could be considered "strange."  This could also
   | include instructions about how to turn the behavior off.

   This would be similar to the features that are currently "disabled" for
   new users, such as scroll-left.


But now I'm thinking that it might be even nicer to be able to get
help on the last event, or sequence of events... (apropos "history")
doesn't seem to list anything quite like what I'm thinking of.  The
idea would be that something that behaved like `command-history' (or
`view-lossage') but that lists events coming from Emacs, rather than
things coming from the user.  Furthemore, instead of just saying *what
happened*, one should be able to get further information about the
functions that have run, specifically, information about their
configuration.

This would mean that no particular set of distinguished functions
would have to be turned on "tentatively", but rather, one could get
good contextual help on pretty much any user-visible event.

Re: Is Emacs becoming Word?

[Greg Novak]

* Joe Corneli <jcorneli@math.utexas.edu> wrote:
> But now I'm thinking that it might be even nicer to be able to get
> help on the last event, or sequence of events... 

I was thinking along the same lines and was just about to try to throw
together a proof-of-principle bit of code.  When something odd
happens, the user would use something like "M-x what-just-happened"
and get info about what Emacs thinks its doing, how to shut it off,
etc.

A perhaps simpler alternative would be to have new user-visible
functionality come enabled by default, but with verbose mini-buffer
entries, like "Type 'M-x describe-extended-character-sets' for more
information."  Fully enabling the new functionality would make the
mini-buffer entries go away.

As I see it, the advantages of the first approach ("M-x
what-just-happened") are:
1) As already pointed out, it's a facility for generic contextual help
2) It's unobtrusive unless the user asks for the information.

Disadvantages include:
1) Retrofitting existing code to actually provide good
context-sensitive information would seem to be a herculean task.
2) This will only help Emacs users who know that the
what-just-happened command exists.  That is, the situation which
prompted this discussion was that Emacs was translating certain inputs
into special characters and I didn't understand why.  If I didn't know
about the what-just-happened command, I would remain confused.

Advantages of the second (verbose minibuffer messages for tentatively
enabled functionality) approach include:
1) By design, the information only has to be added to new user-visible
functionality.  This seems much easier than trying to bring a fully
general contextual help system to fruition.
2) Presumably all Emacs users read messages in the minibuffer, so the
information about new user-visible changes will reach everyone as they
encounter it, rather than having to go digging for it in the NEWS
file, for example.  One could think of this as a dynamic way of
reading the NEWS file.

Disadvantages include:
1) This approach cannot be described as unobtrusive.  All Emacs users
would see an increased number of messages in the minibuffer, at least
until they decide to permanently enable the new functionality.  

I've only recently started digging through significant amounts of
elisp code, so I defer to the judgment of others concerning the
feasibility of either of these two ideas.

Greg

Re: Is Emacs becoming Word?

[Joe Corneli]

   > But now I'm thinking that it might be even nicer to be able to get
   > help on the last event, or sequence of events... 

   I was thinking along the same lines and was just about to try to throw
   together a proof-of-principle bit of code.  When something odd
   happens, the user would use something like "M-x what-just-happened"
   and get info about what Emacs thinks its doing, how to shut it off,
   etc.

I think it probably wouldn't be too ungodly hard to write a
`what-just-happened' function (but I'm not sure).  

Like you pointed out,

   Retrofitting existing code to actually provide good
   context-sensitive information would seem to be a herculean task.

But nevertheless, documentation of this sort _should_ exist.  Unless
we're told how to turn things off (for example) we'll get confused.
Writing the documentation would probably be the hard part, patching it
in to `what-just-happened' seems like it would be relatively easy.

One thing that would be especially useful would be code that would
show where exactly the variables relevant to a certain event were set.

It probably isn't hard to say where a given variable is set.  The
difficulty is in specifying internally which variables are relevant
to which events.

   2) This will only help Emacs users who know that the
   what-just-happened command exists.  That is, the situation which
   prompted this discussion was that Emacs was translating certain inputs
   into special characters and I didn't understand why.  If I didn't know
   about the what-just-happened command, I would remain confused.

I don't think this is a huge concern, because if the command existed
it would be listed by C-h ? and either you'd have figured that out, or
you'd have posted here and been told about the command, then used it,
and probably still found it to be useful quite useful.  (I.e. once you
learn of the command it would reduce confusion many times, and you
only have to learn it once.)

   Advantages of the second (verbose minibuffer messages for tentatively
   enabled functionality) approach include:
   1) By design, the information only has to be added to new user-visible
   functionality.  This seems much easier than trying to bring a fully
   general contextual help system to fruition.
   2) Presumably all Emacs users read messages in the minibuffer, so the
   information about new user-visible changes will reach everyone as they
   encounter it, rather than having to go digging for it in the NEWS
   file, for example.  One could think of this as a dynamic way of
   reading the NEWS file.

   Disadvantages include:
   1) This approach cannot be described as unobtrusive.  All Emacs users
   would see an increased number of messages in the minibuffer, at least
   until they decide to permanently enable the new functionality.  

But it could be turned off.

   I've only recently started digging through significant amounts of
   elisp code, so I defer to the judgment of others concerning the
   feasibility of either of these two ideas.


The second one requires appears to be technically no different from
`disable-command'.  The first one is harder, but if you can write a
`what-just-happened' prototype, certainly people can begin to do the
gruntwork (german/english pun :)) to further populate its output with
useful documentation.

Re: Is Emacs becoming Word?

[Thomas A. Horsley]

>I think it probably wouldn't be too ungodly hard to write a
>`what-just-happened' function (but I'm not sure).  

I don't know about that. Certainly the lisp interpreter should know
what function slots it has been executing through. Seems like it would
be primarily a job of adding a gazillion entry "recently called functions"
array together with some AI for filtering which functions in the
array are important to describe "what just happened" (something like
keeping track of how frequently each entry was called and recognizing
that someone saying "what just happened" was probably startled
by some function that hasn't been called much up to this point. Maybe
toss in some weighting factor for functions that have changed or are new
since the last release as well). Seems almost doable (says someone
who is not volunteering :-).
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
      email: Tom.Horsley@worldnet.att.net icbm: Delray Beach, FL      |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+

Re: Is Emacs becoming Word?

[Henrik Enberg]

tom.horsley@att.net (Thomas A. Horsley) writes:

>>I think it probably wouldn't be too ungodly hard to write a
>>`what-just-happened' function (but I'm not sure).  
>
> I don't know about that. Certainly the lisp interpreter should know
> what function slots it has been executing through. Seems like it would
> be primarily a job of adding a gazillion entry "recently called functions"
> array together with some AI for filtering which functions in the
> array are important to describe "what just happened" (something like
> keeping track of how frequently each entry was called and recognizing
> that someone saying "what just happened" was probably startled
> by some function that hasn't been called much up to this point. Maybe
> toss in some weighting factor for functions that have changed or are new
> since the last release as well). Seems almost doable (says someone
> who is not volunteering :-).

C-h v last-command RET

-- 
Vaya Con Satan

Re: Is Emacs becoming Word?

[Joe Corneli]

   tom.horsley@att.net (Thomas A. Horsley) writes:

   >>I think it probably wouldn't be too ungodly hard to write a
   >>`what-just-happened' function (but I'm not sure).  
   >
   > I don't know about that. Certainly the lisp interpreter should know
   > what function slots it has been executing through. Seems like it would
   > be primarily a job of adding a gazillion entry "recently called functions"
   > array together with some AI for filtering which functions in the
   > array are important to describe "what just happened" (something like
   > keeping track of how frequently each entry was called and recognizing
   > that someone saying "what just happened" was probably startled
   > by some function that hasn't been called much up to this point. Maybe
   > toss in some weighting factor for functions that have changed or are new
   > since the last release as well). Seems almost doable (says someone
   > who is not volunteering :-).

   C-h v last-command RET

That would appear to be of only passing relevance.  It is considerably
easier to keep track of a list of interactive functions (commands)
than it is to sort out the list of all functions that have run, and
separate them into "user-visible" and not-user-visible.  But
`command-history' has an infrastructure that could be used, I'm sure.

On Thomas's "AI" - how about just screening out the functions that
overlap with Common Lisp, and a list of other built-in functions
(`goto-char', etc.) that aren't likely to do anything particularly
interesting in and of themselves.

And in terms of "volunteering", someone should produce a
`last-function' command (maybe 100 entry array would be enough for
testing purposes :)), then a bunch of people could collaborative on a
list of functions to filter out.  A wiki could be used to generate
that list...

I'm pretty sure I've already seen something closer to `last-function'
than `last-command', but I don't remember what it is.

Re: Is Emacs becoming Word?

[Greg Novak]

* Thomas A. Horsley <tom.horsley@att.net> wrote:
>>I think it probably wouldn't be too ungodly hard to write a
>>`what-just-happened' function (but I'm not sure).  
> I don't know about that. Certainly the lisp interpreter should know
> what function slots it has been executing through. Seems like it would
> be primarily a job of adding a gazillion entry "recently called functions"
> array together with some AI for filtering which functions in the
> array are important to describe "what just happened" 
> ...

Hmm.  I was thinking of something considerably simpler.  It would be
incumbent upon the programmer to identify things that the user might
find confusing.  At the end of this mail I've included very simple
code that defines a new major mode to do what I was imagining. 

I'm relatively new to elisp, so don't laugh too hard.  I'd appreciate
comments on the code if anyone has them to offer, but it'd probably be
best to send them directly to me rather than to the whole list.

I also took a shot at implementing the "last-function" command by
advising eval, apply, and/or funcall.  Advising funcall didn't seem to
do much that was interesting.  Advising eval worked, but I only got
the top level form.  Ie, giving eval before-advice to print its
arguments to a buffer before evaluating them, then evaluating 
(+ (* 1 2) (* 3 4))
Results in the buffer containing this:
 (+ (* 1 2) (* 3 4))
not this (as I might have hoped):
 (+ (* 1 2) (* 3 4))
 (* 1 2)
 (* 3 4)

Looking through the code for eval, it looks like it calls eval
recursively on each argument, so I'd expect the latter behavior. 
However, it doesn't seem to be getting the advice on the subsequent
calls.

Finally, it seems that ad-activate calls apply, so trying to advise
apply doesn't work so well... the max recursion depth is exceeded, in
spite of fiddling with flags to try to get it to stop the recursion.

Also, should this discussion be moved to emacs-devel at this point?
I've left it here to preserve continuity in the mailing list archive.

Greg

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; The "what just happened" stuff:
(defvar just-happened nil) ; list of recent interesting functions

(defun docstring (f)
  "Return the docstring of a function"
  (caddr (symbol-function f)))

(defun this-just-happened (f)
  "Record an interesting event by consing the function's docstring
  into just-happened"
  (setq just-happened (cons (docstring f) just-happened)))

(defun what-just-happened ()
  "Pop a buffer with a list of recent intersting events along with 
   information about how to turn the features off, etc.  The list is
   ordered so that the most recent event is last."
  (interactive)
  (pop-to-buffer "*What Just Happened*")
  (erase-buffer)
  (mapc (lambda (x) (insert (concat "*** " x "\n"))) 
        (reverse just-happened)))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; An odd editing mode that substitutes "star" for "*" and 
; "dollar" for "$".

; if non-nil, substitute "star" for "*"
(defvar write-out-mode-star-substitution t)
; if non-nil, substitute "dollar" for "$"
(defvar write-out-mode-dollar-substitution t)

(define-derived-mode odd-mode
  text-mode "odd"
  "Major mode for odd editing.
          \\{odd-mode-map}"
  (setq case-fold-search nil))

(defun write-out-star ()
  "Substitute \"star\" for \"*\".  To turn this behavior off, put 
  (setq write-out-mode-star-substitution nil) in your .emacs file"
  (interactive)
  (if (not write-out-mode-star-substitution)
      (insert "*")
    (this-just-happened 'write-out-star)
    (insert "star")))

(defun write-out-dollar ()
  "Substitute \"dollar\" for \"$\".  To turn this behavior off, put 
  (setq write-out-mode-dollar-substitution nil) in your .emacs file"
  (interactive)
  (if (not write-out-mode-dollar-substitution)
      (insert "*")
    (this-just-happened 'write-out-dollar)
    (insert "dollar")))

(define-key odd-mode-map "*" 'write-out-star)
(define-key odd-mode-map "$" 'write-out-dollar)

Re: Is Emacs becoming Word?

[Joe Corneli]

Neat proof of concept code.

I think the best thing to do would be to post it to gnu-emacs-sources.

A couple typos I noticed, in `write-out-dollar' you should have:

      (insert "$")

and a few docstrings need periods at the end.

Another thing you might consider would be to make it so that the
`just-happened' function had a constant length (say, the last 50
events or whatever, this number could be customizable).  And it should
print out the name of the function that is being described.

Finally, if you could find a way implement the whole system using
advice to `write-out-star' & `write-out-dollar' rather than calling
`this-just-happened' from within those functions, I think the system
would have a cleaner feel to it, but that's just a personal opinion.

Re: Is Emacs becoming Word?

[Thien-Thi Nguyen]

Greg Novak <novak@ucolick.org> writes:

> comments on the code if anyone has them to offer

the advice facility is not powerful enough to do what you are
seeking to do.  see instead: edebug.

thi

Re: Is Emacs becoming Word?

[Thomas A. Horsley]

>If these two examples are the only problems that bug you, it seems
>like you are jumping to conclusions: the cause of your trouble is your
>own customizations, and perhaps also a few packages that are not part
>of the normal Emacs distribution.

Perhaps not his own customizations: I know (from my experience beating them
into submission) that the redhat fedora distribution and the suse
distribution both do wacky stuff to emacs. I was able to fix redhat with my
.emacs file once I discovered their annoying site-lisp/default.el file, but
I never did figure out why suse emacs was so strange - I finally just built
a nice clean emacs distribution from source and ignored suse's utterly and
all my suse emacs problems disappeared.

As far as new features being on by default goes, I can understand why
leaving them on might be a good idea. If I hate them it gives me an
incentive to read up on them to figure out how to turn them off, and if I
like them, I'd probably never see them unless they were on by default,
because I certainly never read the NEWS file unless I'm forced to :-).

I do think it would be a good idea if every item in NEWS came with
a snippit of lisp code you could cut & paste into your .emacs to turn
it off (most of them time, additional research is required once
you learn the name of the feature to discover how to actually disable
it).
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
      email: Tom.Horsley@worldnet.att.net icbm: Delray Beach, FL      |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+