defvaralias

defvaralias

[Luc Teirlinck]

Output of C-h f defvaralias:

defvaralias is a built-in function.
(defvaralias SYMBOL ALIASED &optional DOCSTRING)

Make SYMBOL a variable alias for symbol ALIASED.  

Setting the value of SYMBOL will subsequently set the value of ALIASED, 
and getting the value of SYMBOL will return the value ALIASED has.
ALIASED nil means remove the alias; SYMBOL is unbound after that.
Third arg DOCSTRING, if non-nil, is documentation for SYMBOL.

My remarks:

This suggests that (defvaralias 'var nil) will make `var' cease to be
an alias if it was one and unbind var, if var was bound.  Instead, var
becomes, pretty logically, an alias for `nil'.  I looked at the code
in eval.c and the code makes not the slightest attempt to implement
any special behavior when ALIASED is `nil'.  I propose to just remove
the next to last line in the doc string and could commit this change
if desired.  I just want to make sure that the described behavior is
not _really_ intended (and hence the bug would be in the code rather
than in the doc string).

Sincerely,

Luc.

Re: defvaralias

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> This suggests that (defvaralias 'var nil) will make `var' cease to be
> an alias if it was one and unbind var, if var was bound.  Instead, var
> becomes, pretty logically, an alias for `nil'.  I propose to just remove
> the next to last line in the doc string and could commit this change
> if desired.

Conceptually, `making a variable an alias for nil' seems like a
confusing way of doing (defconst VAR nil); in practice, it additionally
makes it impossible to set the variable (but I'm not sure this is
particularly useful, compared to say, more general enforcement of
defconst).  Removing a variable alias _does_ seem like a useful
function, so wouldn't it make more sense to make the code follow the
doc-string?

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: defvaralias

[Luc Teirlinck]

Miles Bader wrote:

   Removing a variable alias _does_ seem like a useful function, so
   wouldn't it make more sense to make the code follow the doc-string?

I have no strong opinion on the subject.  I just want the function and
its doc string to be in sync, which can be accomplished either way.
But one of the two needs to be done.

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

Please do make the docstring fit the behavior of the function.

defvaralias

[Luc Teirlinck]

The old docstrings of define-obsolete-{function,variable}-alias
contained statements that if no docstring was provided, that is,
`(define-obsolete-{function,variable}-alias 'old 'new)', then OLD
would get the docstring of NEW, _unless_ it already had one.  This has
been replaced with references to the `defalias' and `defvaralias '
docs, which have no such "unless" statements.  The "unless" appears to
be definitely false in the `function' case.  But it is true in the
variable case.  That is because it is false for defalias, but true for
defvaralias.

There are two solutions for the variable case.  Document the fact in
the docstring and Elisp documentation of defvaralias, or make
defvaralias behave exactly like defalias and get rid of the "unless"
behavior.  I prefer the latter.  The patch below would implement
it.  I can install if desired.

To be more concrete:

After:

(defvar var1 "DOC1")
(defvar var2 "DOC2")
(defvaralias 'var1 'var2)

C-h v var1 RET

now shows "DOC1", whereas after the patch below it shows "DOC2", which
is behavior consistent with defalias.

===File ~/eval.c-diff=======================================
*** eval.c	03 May 2005 20:44:24 -0500	1.237
--- eval.c	05 May 2005 19:42:50 -0500	
***************
*** 747,752 ****
--- 747,754 ----
    LOADHIST_ATTACH (symbol);
    if (!NILP (docstring))
      Fput (symbol, Qvariable_documentation, docstring);
+   else
+     Fput (symbol, Qvariable_documentation, Qnil);
  
    return aliased;
  }
============================================================

Re: defvaralias

[Luc Teirlinck]

>From my previous message:

   After:

   (defvar var1 "DOC1")
   (defvar var2 "DOC2")
   (defvaralias 'var1 'var2)

should have been:

   After:

   (defvar var1 nil "DOC1")
   (defvar var2 nil "DOC2")
   (defvaralias 'var1 'var2)

Sincerely,

Luc.

defvaralias

[Nick Roberts]

Luc Teirlinck writes:
 > The old docstrings of define-obsolete-{function,variable}-alias
 > contained statements that if no docstring was provided, that is,
 > `(define-obsolete-{function,variable}-alias 'old 'new)', then OLD
 > would get the docstring of NEW, _unless_ it already had one.  This has
 > been replaced with references to the `defalias' and `defvaralias '
 > docs, which have no such "unless" statements.  The "unless" appears to
 > be definitely false in the `function' case.  But it is true in the
 > variable case.  That is because it is false for defalias, but true for
 > defvaralias.

That was my mistake. I looked at the behaviour of defvaralias and assumed
defalias behaved the same way.

 > There are two solutions for the variable case.  Document the fact in
 > the docstring and Elisp documentation of defvaralias, or make
 > defvaralias behave exactly like defalias and get rid of the "unless"
 > behavior.  I prefer the latter.  The patch below would implement
 > it.  I can install if desired.
 > 
 > To be more concrete:
 > 
 > After:
 > 
 > (defvar var1 "DOC1")
 > (defvar var2 "DOC2")
 > (defvaralias 'var1 'var2)

I think if an alias is made only then only one of the variables needs to be
declared.

 > C-h v var1 RET
 > 
 > now shows "DOC1", whereas after the patch below it shows "DOC2", which
 > is behavior consistent with defalias.

As Stefan has pointed out defvaralias has a symmetry in its arguments (unlike
define-obsolete-variable-alias neither) but clearly it would make sense to be
consistent with defalias.

Nick

Re: defvaralias

[Luc Teirlinck]

Nick Roberts wrote:
    
    > (defvar var1 "DOC1")
    > (defvar var2 "DOC2")
    > (defvaralias 'var1 'var2)

   I think if an alias is made only then only one of the variables needs to be
   declared.

So the idea of the present behavior would be to do a
(defvaralias 'var1 'var2) with a defvar for var1 instead of for var2?
I do not believe that would be appropriate.

   As Stefan has pointed out defvaralias has a symmetry in its
   arguments (unlike define-obsolete-variable-alias neither)

I do not understand.  The variable alias structure is a directed
graph, not an undirected graph.  The arguments to defvaralias are
asymmetric in their meaning.  The first argument is the alias, the
second the base variable.

(defvaralias 'var1 'var2)

is different (in non-trivial ways) from 

(defvaralias 'var2 'var1)

in as far as `indirect-variable', cyclic variable indirection errors
and such are concerned.

Sincerely,

Luc.

Re: defvaralias

[Luc Teirlinck]

Nick Roberts wrote:

   As Stefan has pointed out defvaralias has a symmetry in its arguments

Looking at the old message, I believe that what Stefan said is that in
defvaralias (unlike in `define-obsolete-variable-alias'), there are no
"old" and "new" variables or "obsolete" and "updated" variables.
(With which I agree.)  But that is not the same as saying that there
is symmetry.  The asymmetry in the relation is that one is the alias,
the other the base variable.

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

    There are two solutions for the variable case.  Document the fact in
    the docstring and Elisp documentation of defvaralias, or make
    defvaralias behave exactly like defalias and get rid of the "unless"
    behavior.  I prefer the latter.

I think that is cleaner, but it is also an incompatible change.
I'd rather warn people we will change this after version 22.

Re: defvaralias

[Luc Teirlinck]

Richard Stallman wrote:

   I think that is cleaner, but it is also an incompatible change.
   I'd rather warn people we will change this after version 22.

But the function is new in 22.1, so if we change this in 23, we have
aberrant behavior for just one single release.  All current
documentation, including the NEWS, describes the behavior as being
what the behavior _would_ be after my patch.  So the current actual
behavior appears to be unintentional.  The change only affects
docstrings, so can not introduce severe bugs.  The change only makes a
difference in cases which should not really occur to begin with (at
least not in the Emacs source code): a variable defined twice, once
with defvar and once with defvaralias.

Not making the small code change would require the documentation
(docstring, Elisp manual and NEWS) to become more complex.  We would
have to document the exceptional case and then warn that it will go
away in Emacs 23.

Sincerely,

Luc.

Re: defvaralias

[Nick Roberts]

Luc Teirlinck writes:
 > Nick Roberts wrote:
 >     
 >     > (defvar var1 "DOC1")
 >     > (defvar var2 "DOC2")
 >     > (defvaralias 'var1 'var2)
 > 
 >    I think if an alias is made only then only one of the variables needs to be
 >    declared.
 > 
 > So the idea of the present behavior would be to do a
 > (defvaralias 'var1 'var2) with a defvar for var1 instead of for var2?
 > I do not believe that would be appropriate.

I mean:

(defvar var2 "DOC2")
(defvaralias 'var1 'var2)

is doesn't give compiler warnings. Presumably defvaralias is a declaration
for var1.

 >    As Stefan has pointed out defvaralias has a symmetry in its
 >    arguments (unlike define-obsolete-variable-alias neither)
 > 
 > I do not understand.  The variable alias structure is a directed
 > graph, not an undirected graph.  The arguments to defvaralias are
 > asymmetric in their meaning.  The first argument is the alias, the
 > second the base variable.
 > 
 > (defvaralias 'var1 'var2)
 > 
 > is different (in non-trivial ways) from 
 > 
 > (defvaralias 'var2 'var1)
 > 

Yes, you're right and I'm misquoting Stefan. There must be some symmetry,
however as:

(defvar var2 "DOC2")
(defvaralias 'var1 'var2)
(defvar var1a "DOC1")
(defvaralias 'var1a 'var2a)

doesn't give compiler warnings either.


Nick


 > in as far as `indirect-variable', cyclic variable indirection errors
 > and such are concerned.
 > 
 > Sincerely,
 > 
 > Luc.

Re: defvaralias

[Luc Teirlinck]

Nick Roberts wrote:

   I mean:

   (defvar var2 "DOC2")
   (defvaralias 'var1 'var2)

Of course, but I did a prior (defvar var1 "DOC1") to give var1 a
docstring.  Apart from that the (defvar var1 "DOC1") is really bad.  A
defvaralias form, like a defalias form, constitutes a definition and
one should not define var1 twice with different definitions.  But how
else do I give var1 a prior docstring other than manually manipulating
the variable-documentation property of var1 before doing the
defvaralias, which I should not be doing either?

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

    There are two solutions for the variable case.  Document the fact in
    the docstring and Elisp documentation of defvaralias, or make
    defvaralias behave exactly like defalias and get rid of the "unless"
    behavior.  I prefer the latter.

I think the latter is cleaner, but it is also an incompatible change.
I'd rather warn people we will change this after version 22.

Re: defvaralias

[Stefan Monnier]

>    (defvar var2 "DOC2")
>    (defvaralias 'var1 'var2)

> Of course, but I did a prior (defvar var1 "DOC1") to give var1 a
> docstring.  Apart from that the (defvar var1 "DOC1") is really bad.  A
> defvaralias form, like a defalias form, constitutes a definition and
> one should not define var1 twice with different definitions.  But how
> else do I give var1 a prior docstring other than manually manipulating
> the variable-documentation property of var1 before doing the
> defvaralias, which I should not be doing either?

What's wrong with (defvaralias 'var1 'var2 "var1 docstring") ?


        Stefan

Re: defvaralias

[Luc Teirlinck]

Stefan Monnier wrote:

   What's wrong with (defvaralias 'var1 'var2 "var1 docstring") ?

Nothing.  What we are struggling with is an unintentional misfeature
whereby if var1 already has a docstring then after
`(defvaralias 'var1 'var2)' it keeps its docstring instead of getting
var2's docstring as intended and currently documented.  This really
never should matter, as it can only occur if var1 has two competing
definitions, a defvar or defcustom and a defvaralias, which should not
happen.  My example with the deliberately bad code was meant to
illustrate the misfeature.

I proposed a small trivial patch to eliminate the misfeature, but
Richard said that this constituted an incompatible change and that we
should document the feature and tell people not to use it since the
feature will be eliminated in Emacs 23.  (I have a hard time
understanding why this is an incompatible change, since the function
defvaralias in _new_ in Emacs 22, and the behavior only can occur if
there already is a bug anyway.)

Sincerely,

Luc.

Re: defvaralias

[Luc Teirlinck]

>From my previous message:
  
  and the behavior only can occur if there already is a bug anyway.

Well, bug is probably not the correct word.  The behavior can only
occur if there is already very unclean code.

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

       I think that is cleaner, but it is also an incompatible change.
       I'd rather warn people we will change this after version 22.

    But the function is new in 22.1,

The ChangeLog files say it was present in 21.1.
If it were new in 22.1 then indeed we could change it painlessly now.

Re: defvaralias

[Richard Stallman]

    (defvar var2 "DOC2")
    (defvaralias 'var1 'var2)

    is doesn't give compiler warnings. Presumably defvaralias is a declaration
    for var1.

In theory, it should warn, but I would rather put that in TODO
and not change it now.

    Yes, you're right and I'm misquoting Stefan. There must be some symmetry,
    however as:

    (defvar var2 "DOC2")
    (defvaralias 'var1 'var2)

That should not warn.  It defines var2 once and var1 once.

    (defvar var1a "DOC1")
    (defvaralias 'var1a 'var2a)

That should warn.  It defines var1a twice.

But this can wait till after the release.

Re: defvaralias

[Luc Teirlinck]

Richard Stallman wrote:

       But the function is new in 22.1,

   The ChangeLog files say it was present in 21.1.

That is indeed true.   The confusion arose because I forgot that `C-h v
did not work for variables defined in the C code in 21.3.

Sincerely,

Luc.

Re: defvaralias

[Luc Teirlinck]

>From my pevious message:

   That is indeed true.   The confusion arose because I forgot that `C-h v
   did not work for variables defined in the C code in 21.3.

I of course meant that I forgot that `C-h f" did not work for
functions defined in the C code (such as defvaralias).

Sincerely,

Luc.

Re: defvaralias

[Juanma Barranquero]

> The ChangeLog files say it was present in 21.1.
> If it were new in 22.1 then indeed we could change it painlessly now.

Luc's right. The first reference to defvaralias is:

  2001-10-04  Gerd Moellmann  <gerd@gnu.org>

        This adds `defvaralias' and `indirect-variable'.  Changes not
        directly related to this feature are there to gain the same
        performance again as before variable aliases.

and the previous entry on ChangeLog.9 is:

  2001-10-04  Gerd Moellmann  <gerd@gnu.org>

        * Branch for 21.1.

so it seems like Gerd branched for 21.1 and immediately afterwards
commited a bunch of things on the main trunk, `defvaralias' among
them.

It's a little weird, though. `defvaralias' is mentioned on
lisp\ChangeLog on 21.[1-4]:

  2001-05-20  Gerd Moellmann  <gerd@gnu.org>

        * font-lock.el (lisp-font-lock-keywords-1): Add `defvaralias'.

and the corresponding font-lock code indeed has:

  "(\\(def\\("
  ;; Function declarations.
  "\\(advice\\|varalias\\|alias\\|generic\\|macro\\*?\\|method\\|"
  [etc]

even when the function is not available.

And, from 21.2+, lisp\w32-fns.el has this:

  ;; Set system coding system initially from locale-coding-system.
  ;; In future, when defvaralias is available, this will become an alias.
  (set-w32-system-coding-system locale-coding-system)

-- 
                    /L/e/k/t/u

Re: defvaralias

[Juanma Barranquero]

> That is indeed true.   The confusion arose because I forgot that `C-h v
> did not work for variables defined in the C code in 21.3.

Uh?

  *** Welcome to IELM ***  Type (describe-mode) for help.
  ELISP> (defvar *x* 1)
  *x*
  ELISP> (defvaralias '*y* '*x*)
  *** Eval error ***  Symbol's function definition is void: defvaralias
  ELISP> emacs-version
  "21.3.1"
  ELISP> 

-- 
                    /L/e/k/t/u

Re: defvaralias

[Luc Teirlinck]

Juanma Barranquero wrote;

   > That is indeed true.   The confusion arose because I forgot that `C-h v
   > did not work for variables defined in the C code in 21.3.

   Uh?

     *** Welcome to IELM ***  Type (describe-mode) for help.
     ELISP> (defvar *x* 1)
     *x*
     ELISP> (defvaralias '*y* '*x*)
     *** Eval error ***  Symbol's function definition is void: defvaralias
     ELISP> emacs-version
     "21.3.1"
     ELISP> 

You are right.  I guess I just forgot _how_ I checked it yesterday.
After seeing Richard's message, I just _assumed_ that I must have done
something wrong.

Richard, shall I go ahead and install my patch then?

Sincerely,

Luc.

Re: defvaralias

[Richard Stallman]

    so it seems like Gerd branched for 21.1 and immediately afterwards
    commited a bunch of things on the main trunk, `defvaralias' among
    them.

Thanks for noticing this.  This being so, let's make the change in doc
string handling change now.

Re: defvaralias

[Luc Teirlinck]

Richard Stallman wrote:

   This being so, let's make the change in doc string handling change now.

Done.

Sincerely,

Luc.

defvaralias

[largo-linux]

i have emacs from fedora core 4 (version 21.4-5 i believe).  i tried to
install journal.el from the emacswiki page, but it complains that the
function defvaralias is void...  where can i get defvaralias?  or is
there a workaround for this.  it seems that defvaralias just creates a
link between two variables

in the code defvaralias is used once :

(defvaralias 'journal-default-page 'emacs-wiki-default-page)

it would seem that emacs-wiki-default page is set elsewhere and i could
just copy emacs-wiki-default-page to journal-default-page...

(setq 'journal-default-page 'emacs-wiki-default-page) ;; ???

any help greatly appreciated.

Re: defvaralias

[Charles philip Chan]

[-- Attachment #1.1: Type: text/plain, Size: 418 bytes --]

On  5 Aug 2005, joelvsmith@earthlink.net wrote:

> in the code defvaralias is used once :

> (defvaralias 'journal-default-page 'emacs-wiki-default-page)


You must first install emacs-wiki-mode: 

http://www.emacswiki.org/cgi-bin/wiki/EmacsWikiMode



Charles

-- 
"Are [Linux users] lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?"
(By Matt Welsh)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: defvaralias

[largo-linux]

i did install emacwiki (i.e. untarred and gunzipped the package and
then put in my .emacs where to find the package and require the
package)...

in fact in my first work around taken from someone's post i simply
blanked out defvaralias but when it tried to save the default page it
returned a wrong argument error.

Re: defvaralias

[Charles philip Chan]

[-- Attachment #1.1: Type: text/plain, Size: 1544 bytes --]

On  5 Aug 2005, joelvsmith@earthlink.net wrote:

> i did install emacwiki (i.e. untarred and gunzipped the package and
> then put in my .emacs where to find the package and require the
> package)...

What is the ouput of C-hv emacs-wiki-default-page? It should return
WelcomePage, if emacs-wiki is setup properly. Does your Wiki directory
exist? Have you customized it? You can use customize-group: the group
name is emacs-wiki.

> in fact in my first work around taken from someone's post i simply
> blanked out defvaralias but when it tried to save the default page it
> returned a wrong argument error.

The problem is somewhere else since there is no way your copy of emacs
doesn't have defvaralias because it is a built in function:

,----[ defvaralias ]
| defvaralias is a built-in function in `C source code'.
| (defvaralias NEW-ALIAS BASE-VARIABLE &optional DOCSTRING)
| 
| Make NEW-ALIAS a variable alias for symbol BASE-VARIABLE.  Setting the
| value of NEW-ALIAS will subsequently set the value of BASE-VARIABLE, and
| getting the value of NEW-ALIAS will return the value BASE-VARIABLE has.
| Third arg DOCSTRING, if non-nil, is documentation for NEW-ALIAS.  If it
| is omitted or nil, NEW-ALIAS gets the documentation string of
| BASE-VARIABLE, or of the variable at the end of the chain of aliases, if
| BASE-VARIABLE is itself an alias.  The return value is BASE-VARIABLE.
`----

Charles

-- 
"Oh, I've seen copies [of Linux Journal] around the terminal room at The
Labs."
(By Dennis Ritchie)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: defvaralias

[largo-linux]

thanks for your response.  here is what i get when i (require 'journal)

Debugger entered--Lisp error: (void-function defvaralias)
  (defvaralias (quote journal-default-page) (quote
emacs-wiki-default-page))
  eval-buffer(#<buffer  *load*> nil "journal" nil t)
  load-with-code-conversion("/scratch/emacs-wiki-2.70/journal.el"
"journal" nil t)
  require(journal)
  eval((require (quote journal)))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
* call-interactively(eval-last-sexp)

also c-h n (search for defvaralias yields nothing)...  emacs-version ==
2.4.1

Re: defvaralias

[largo-linux]

forgot to say that welcomepage is 'emacs-wiki-default-page.  i also hit
M-x customize-group emacs-wiki.  i looked at some things but i didn't
change anything...  i didn't compile emacs-wiki, because it was
optional...

Re: defvaralias

[Charles philip Chan]

[-- Attachment #1.1: Type: text/plain, Size: 1001 bytes --]

On  5 Aug 2005, joelvsmith@earthlink.net wrote:

> Debugger entered--Lisp error: (void-function defvaralias)
> (defvaralias (quote journal-default-page) (quote
> emacs-wiki-default-page))
> eval-buffer(#<buffer  *load*> nil "journal" nil t)
> load-with-code-conversion("/scratch/emacs-wiki-2.70/journal.el"
> "journal" nil t)
> require(journal)
> eval((require (quote journal)))
> eval-last-sexp-1(nil)
> eval-last-sexp(nil)
> * call-interactively(eval-last-sexp)

I will look at this further. Did you require emacs-wiki before journal?

> also c-h n (search for defvaralias yields nothing)...

Huh, C-h n is for showing what is new in Emacs. Try:

C-h f defvaralias

Also, what is returned when you do:

C-h v emacs-wiki-default-page

> emacs-version == 2.4.1

There is no such version. What does it say when you go to "Help" ==>
"About Emacs"?

Charles

-- 
Linux: Because a PC is a terrible thing to waste.
(By komarimf@craft.camp.clarkson.edu, Mark Komarinski)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: defvaralias

[largo-linux]

I have the following in my .emacs

(add-to-list 'load-path "/scratch/emacs-wiki-2.70")
(require 'emacs-wiki)

i read somewhere that in the NEWS (C-h n) defvaralias has an entry...
C-h f defvaralias --> no entry

C-h v emacs-wiki-default-page
emacs-wiki-default-page's value is "WelcomePage"

Documentation:
Name of the default page used by M-x emacs-wiki-find-file.
This is also used to resolve a link to a project that has no Wiki
page specified.

You can customize this variable.

Defined in `emacs-wiki'.

i don't see an "about emacs" in "help"  but there is an "emacs version"
it returns

GNU Emacs 21.4.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2005-05-18 on decompose.build.redhat.com

thank you.

Re: defvaralias

[Charles philip Chan]

[-- Attachment #1.1: Type: text/plain, Size: 794 bytes --]

On  5 Aug 2005, joelvsmith@earthlink.net wrote:

> i read somewhere that in the NEWS (C-h n) defvaralias has an entry...
> C-h f defvaralias --> no entry

I see what you mean now.

> GNU Emacs 21.4.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
> of 2005-05-18 on decompose.build.redhat.com

This is really strange because according to my research defvaralias was
introduced in Emacs 21.4 (there must be something screwy with the
Redhat's build). You have 2 choices:

(1) Upgrade your Emacs.

(2) Ask your question on the emacs-wiki list:
    http://www.emacswiki.org/cgi-bin/wiki/EmacsWikiMailingList

    I am sure someone can help you there.

Charles

-- 
We are MicroSoft.  You will be assimilated.  Resistance is futile.
(Attributed to B.G., Gill Bates)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: defvaralias

[Tim X]

"Charles philip Chan" <cpchan@sympatico.ca> writes:

> 
> > i read somewhere that in the NEWS (C-h n) defvaralias has an entry...
> > C-h f defvaralias --> no entry
> 
> I see what you mean now.
> 
> > GNU Emacs 21.4.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
> > of 2005-05-18 on decompose.build.redhat.com
> 
> This is really strange because according to my research defvaralias was
> introduced in Emacs 21.4 (there must be something screwy with the
> Redhat's build). You have 2 choices:
> 
> (1) Upgrade your Emacs.
> 
> (2) Ask your question on the emacs-wiki list:
>     http://www.emacswiki.org/cgi-bin/wiki/EmacsWikiMailingList
> 
>     I am sure someone can help you there.
> 

I'm running emacs 21.4.1 on debian and there is no defvaralias defined
and no mention of it in the News file either. As I understand it, the
only difference between 21.3 and 21.4 was a security patch - no ew
features werre introduced.

Tim
 

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!