Init error message

Init error message

[Kevin Reeder]

Ok. I give up. I'm a new user to GNU Emacs. My system is RH 7.3 & the
following error message appears:

	Wrong type argument: arrayp, up

I've run --debug-init and have the backtrace.

Undoubtedly this has been asked/answered before but I'm darned if I can
find it. Please direct me to a _searchable_ archive of usenet or mailing
list messages if unable to answer for me.

Kevin

Re: Init error message

[John Paul Wallington]

Kevin Reeder <avail@uponrequest.org> wrote:

> Ok. I give up. I'm a new user to GNU Emacs. My system is RH 7.3 & the
> following error message appears:
>
> 	Wrong type argument: arrayp, up

Probably you have

(global-set-key 'up 'whatever)

in your .emacs file.  If that is so, say

(global-set-key [up] 'whatever) instead.

> Please direct me to a _searchable_ archive of usenet

groups.google.com

Re: Init error message

[Kevin Reeder]

> Probably you have
> 
> (global-set-key 'up 'whatever)
> 
> in your .emacs file.  If that is so, say
> 
> (global-set-key [up] 'whatever) instead.


Thank you. That sovled the problem which had to do with emulating up/down
cmd history echoing in the shell.
 
>> Please direct me to a _searchable_ archive of usenet
> 
> groups.google.com

Went there and that's better than what I'd come up with on my own.
However, I need to get grounded in working with this .emacs file. The
syntax is a mystery and I just want to use the editor! Probably a common
whine. Is the only option to learn enough of LISP to hack it profitably
without having to cry for help over every little init error msg?

BTW, here's the new error:

	File error: "Cannot open load file", "auto-save"

I've located the line with the offending code; interesting it uses the
apostrophe instead of brackets (require 'auto-save) but when I switch I
get a different error on the same function which seems to be telling me
that it doesn't like the brackets. Like I said I'm in the woods here (but
willing to work).

Finally, I should confess to previously using an alternative to GNU Emacs
because I had found these configuration issues more solvable under the
alternative. Now I'm abandoning that program for GNU Emacs. Is it possible
that the .emacs coding varies between the two emacsen?

Kevin

Re: Init error message

[Kevin Rodgers]

Kevin Reeder wrote:

>>>Please direct me to a _searchable_ archive of usenet
>>
>>groups.google.com
> 
> Went there and that's better than what I'd come up with on my own.
> However, I need to get grounded in working with this .emacs file. The
> syntax is a mystery and I just want to use the editor! Probably a common
> whine. Is the only option to learn enough of LISP to hack it profitably
> without having to cry for help over every little init error msg?


Have you browsed the Emacs manual?  It's available in emacs via `C-h i'.
If you're not familiar with Info, type `m Info RET' to learn how to browse
the GNU manuals.  Then you can read the Customization node in the Emacs manual,
and its Key Bindings and Init File subnodes in particular.


> BTW, here's the new error:
> 
> 	File error: "Cannot open load file", "auto-save"
> 
> I've located the line with the offending code; interesting it uses the
> apostrophe instead of brackets (require 'auto-save) but when I switch I
> get a different error on the same function which seems to be telling me
> that it doesn't like the brackets. Like I said I'm in the woods here (but
> willing to work).


[up] is a vector constant; keys (i.e. event sequences) are represented as
vectors.

'auto-save evaluates to a symbol; feature names are represented by symbols.

"auto-save" is a string constant; file names are represented as strings.

`C-h f global-set-key RET' explains that it is a function that binds a KEY
to a COMMAND (an interactive function, usually represented by a symbol).

`C-h f require RET' explains that it loads the "FEATURE" file in order to
provide the FEATURE feature.  `C-h f load RET' explains that the directories
in `load-path' are searched for the "FILE" to load.  `C-h v load-path RET'
will show you what directories are being searched for the "auto-save.elc" and
"auto-save.el" files.

The real question is: Why are you trying to load the auto-save library?


> Finally, I should confess to previously using an alternative to GNU Emacs
> because I had found these configuration issues more solvable under the
> alternative. Now I'm abandoning that program for GNU Emacs. Is it possible
> that the .emacs coding varies between the two emacsen?

Of course it is possible, and it's almost certain that the installations are
different (e.g. the load-path directories' contents).  But you are wise to
migrate to the One True Editor.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Init error message

[Kai Großjohann]

Kevin Reeder <avail@uponrequest.org> writes:

> Went there and that's better than what I'd come up with on my own.
> However, I need to get grounded in working with this .emacs file. The
> syntax is a mystery and I just want to use the editor! Probably a common
> whine. Is the only option to learn enough of LISP to hack it profitably
> without having to cry for help over every little init error msg?

It seems that your errors come from copying and pasting things you
don't understand.  If you start slow and don't just snarf gobs of
Lisp code, it will be easier.

If you have a question, it's best to show the problematic Lisp code.
For example, I'm guessing that you had (require 'auto-save) in your
~/.emacs file for a reason -- maybe some additional lines that need
it?

Emacs does not have auto-save.el -- was the code from an XEmacs user?

For key bindings, I always recommend to use the kbd syntax.  It has
the advantage that C-h c, C-h k, and C-h l print out exactly the
syntax you need.  It works like this:

(global-set-key (kbd "<f4>") 'forward-char)

Instead of <f4> you can just put there whatever C-h k or C-h c or C-h
l tells you.  So after hitting Shift-F4 Ctrl-Meta-SPC, C-h l tells you

<S-f4> C-M-SPC

and this is ready for use.

-- 
A preposition is not a good thing to end a sentence with.

Re: Init error message

[kgold]

Not a whine, but certainly a pet peeve of mine.  

I would find the on-line help and .el file comments a lot more helpful
if it actually showed sample lisp code, instead of saying "set the
variable foo to bar" and leaving the novice to figure out how to do
it.

The good news is:

- the experts here seem infinitely patient and willing to help.

- you can cut and paste a lot of working code directly to your .emacs

- if you like 'customize', it will write lisp for you

Kevin Reeder <avail@uponrequest.org> writes:
> However, I need to get grounded in working with this .emacs file. The
> syntax is a mystery and I just want to use the editor! Probably a common
> whine. Is the only option to learn enough of LISP to hack it profitably
> without having to cry for help over every little init error msg?

-- 
-- 
Ken Goldman   kgold@watson.ibm.com   914-784-7646

Re: Init error message

[LLeweLLyn]

Kevin Reeder <avail@uponrequest.org> writes:

> Undoubtedly this has been asked/answered before but I'm darned if I can
> find it. Please direct me to a _searchable_ archive of usenet or mailing
> list messages if unable to answer for me.

groups.google.com

Re: Init error message

[Kevin Reeder]

Many thanks for the in-depth responses. Later today, possibly tomorrow,
I'll have a chance to work with the ideas you shared. Posting now so as
not to appear ungrateful.

As I recall when I installed Xemacs, a "sample" .emacs file was provided
which I copied into my ~/ and made a few customizations. It now seems
quite clear that there are important differences between what Xemacs
wants from that file and what GNU Emacs wants. Question: would it be best
to just start over rather than try to jerry rig the old file?

> . . .you are wise to migrate to the One True Editor.

What was I thinking???

Kevin

Re: Init error message

[Unknown]

Kevin Reeder wrote:

> Many thanks for the in-depth responses. Later today, possibly tomorrow,
> I'll have a chance to work with the ideas you shared. Posting now so as
> not to appear ungrateful.
> 
> As I recall when I installed Xemacs, a "sample" .emacs file was provided
> which I copied into my ~/ and made a few customizations. It now seems
> quite clear that there are important differences between what Xemacs
> wants from that file and what GNU Emacs wants. Question: would it be best
> to just start over rather than try to jerry rig the old file?

It's better to understand what each line of your ~/.emacs or ~/.xemacs/init.el 
does.  If you wholesale copy and paste stuff from random sources, you'll have 
problems no matter which emacs you use.

>> . . .you are wise to migrate to the One True Editor.
> 
> What was I thinking???

XEmacs is a fine emacs.  Use what you want.  But PLEASE don't go out of your 
way to antagonize people.

--
Le

Re: Init error message

[Kevin Reeder]

On Wed, 12 Mar 2003 18:14:10 -0800, Le Wang wrote:


> XEmacs is a fine emacs.  Use what you want.  But PLEASE don't go out of
> your way to antagonize people.
> 
> --
> Le

I'm puzzled by this last remark not only because the newsgroup is titled
GNU.emacs.help but also I'm wary of the delicate feelings connected with
peoples' relationship with their editor and chose my words carefully. One
responder brought up the issue of the Xemacs init file (see above, "Emacs
does not have auto-save.el -- was the code from an XEmacs user?"), so, in
responding, I included the information that I had, in fact, been using
that emacs. Finally, one clever responder made an ironic comment to which
I retorted a admittedly feeble effort at tasteful irony.

Altogether, it seems a stretch to say that I was deliberately antagonizing
people. I'll salt the lesson away, nonetheless.

Back to my init file efforts. I've set my old .emacs aside for now and
started with a blank slate (tabula rasa as it were). Next I've gotten
deeper into the Emacs info node (bonk!) as a new companion to my O'Reilly
manual. Thus, I'm moving ahead and learning as I go. Thanks for the tips
one and all.

Kevin

Re: Init error message

[Unknown]

>Kevin Reeder wrote:

> On Wed, 12 Mar 2003 18:14:10 -0800, Le Wang wrote:
> 
> 
>> XEmacs is a fine emacs.  Use what you want.  But PLEASE don't go out of
>> your way to antagonize people.
>> 
>> --
>> Le
> 
> I'm puzzled by this last remark not only because the newsgroup is titled
> GNU.emacs.help but also I'm wary of the delicate feelings connected with
> peoples' relationship with their editor and chose my words carefully.

I have "delicate" feelings about both my emacsen.  I think there are plenty of 
people in the same boat.  It's in my (and our) interest to see both efforts 
continue and thrive.

If something was said in e.e.xemacs that I think could hurt the feelings of 
XEmacs developers, I'd say something as well.

If you had pointed out some specific short comings of XEmacs (there are some), 
I wouldn't have minded.  But to make a general statement like:

>> . . .you are wise to migrate to the One True Editor.
>
>What was I thinking???

IMHO is wholly not appropriate.

--
Le

Re: Init error message

[David Kastrup]

Le Wang <lewang(at@)yahoo.com> writes:

> >Kevin Reeder wrote:
> 
> > On Wed, 12 Mar 2003 18:14:10 -0800, Le Wang wrote:
> > 
> >> XEmacs is a fine emacs.  Use what you want.  But PLEASE don't go
> >> out of your way to antagonize people.
> > 
> > I'm puzzled by this last remark not only because the newsgroup is
> > titled GNU.emacs.help but also I'm wary of the delicate feelings
> > connected with peoples' relationship with their editor and chose
> > my words carefully.
> 
> I have "delicate" feelings about both my emacsen.  I think there are
> plenty of people in the same boat.  It's in my (and our) interest to
> see both efforts continue and thrive.

No.  It is very much against anybody's interest to see both efforts
continue and thrive separately.

There are some matters that are better implemented in one version,
and some matters that are nicer in the other.  There are some things
that are better documented in one, and some that are better in the
other.

Any programmer for serious applications needs to cater for both
Emacsen.  That means that he always has to program for the worst API
in addition to the better API, and with the worst documentation from
both Emacsen.  This takes even more time and effort than if he was
merely stuck with the worst from both Emacsen: programming for an
additional API means additional work even if that additional API might
be better and better documented, too (which it more often than not is
not).

If there was a completely different mindshare involved (like
KDE/Qt/C++ vs GNOME/Gtk/C), applications would simply exist and be
developed independent for both Emacsen.  But as it is, important
applications have to be made to run under both.  And every nontrivial
Emacs project has at least man-months of work wasted on the Emacs
Schisma.

I am not interested in assigning blame, and everybody will tell me
his point of the story and how he is the good guy and the other the
bad one, but I am not interested.

I am just not going to swallow the lie that it is in the very best
interest of all that every Emacs developer with nontrivial projects
has to jump through all sorts of hoops to cater for two incarnations
of Emacs.

I don't see this change in my life time, but I am not going to applaud
it.  It's wasting my time as a free software developer, similarly
like catering for Windows ports does.  One does it in order not to
cut a substantial user base off, but there is no fun in it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Init error message

[John Paul Wallington]

Le Wang <lewang(at@)yahoo.com> wrote:

> It's in my (and our) interest to see both efforts continue and
> thrive.

This is a matter of opinion.  See for example:
http://groups.google.com/groups?q=&selm=rjd6z1x1qt.fsf%40ssv2.dina.kvl.dk

Do you think a merge is desirable?  Do you agree that in order to
merge the projects, one of the projects has to be shutdown?

Re: Init error message

[David Kastrup]

Let me add as a prerequisite that I have no talents to be polite or
diplomatic.  So don't take posts like this personal.  I have
Xpost/Fuped this to comp.emacs and comp.emacs.xemacs which I consider
more fitting to this discussion (even though it might be considered
sufficiently rehashed to death) than gnu.emacs.help.

John Paul Wallington <jpw@gnu.org> writes:

> Le Wang <lewang(at@)yahoo.com> wrote:
> 
> > It's in my (and our) interest to see both efforts continue and
> > thrive.
> 
> This is a matter of opinion.  See for example:
> http://groups.google.com/groups?q=&selm=rjd6z1x1qt.fsf%40ssv2.dina.kvl.dk
> 
> Do you think a merge is desirable?

Yes.

> Do you agree that in order to merge the projects, one of the
> projects has to be shutdown?

Yes.  There _is_ already merging going on all the time in the
direction Emacs->XEmacs.  This does not cut it for application
developers.

It is clear that the survivor must be GNU Emacs copyrighted by the
FSF.  Emacs is a core piece of GNU software, the FSF will not
relinquish control, Stallman himself is actively working on it.  This
does not mean that core pieces of XEmacs could or should not be
integrated into GNU Emacs and replace stuff there that is suboptimal,
but it means that integrators would need to be willing and legally
capable of signing over their work to the FSF, _and_ would need to get
along well enough with Stallman in order to progress with substantial
changes to a core project of his, including extensive changes and
documentation of internals.

Stallman is a very headstrong person.  While he is not malignant, it
can be a chore working with him.  Free Software needs a man of his
qualities, so I tend to arrange what it is necessary in order to
cooperate with him, even though there are times when he drives me up
the wall.

I don't see too much willingness of the _core_ developers of XEmacs to
cope with what would be necessary for a merge.  And frankly,
cooperating with Stallman on a comtinued basis is not something that
one could reasonably _demand_ from anybody to cope with.  If at all,
such participation would have to be voluntary, and on a project as
large as a merge of XEmacs and Emacs it would be very taxing to both
parties.

Personally, I think that one way to improve matters would be that if
XEmacs developers came up with some new functionality and/or API, they
would discuss it also on the Emacs developer lists and would offer to
sign the respective papers and stuff in order to help implementing it
also in Emacs.  And if the original plans get thwarted for some
different interface of comparable usefulness, rather implement that in
XEmacs.

Yes, it will expose them to GNU Emacs and Stallman more than they
like, but it will help lessen the amount in which application
programmers get screwed that have to cater for both Emacsen.

This will not buy us a unified Emacs, but it would lessen the bad
impact of the split.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum