headers
BJörn Lindqvist | 2 Mar 2006 10:22
Picon

vc-svn.el from subversion is in the way

When you install emacs 22 from svn, emacs should do something about
the /usr/share/emacs/site-lisp/vc-svn.el file. The file has the
contents:

(error
 "http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/lisp/vc-svn.el
  is the new canonical location of vc-svn.el, in the FSF Emacs tree.")

That file gets in the way of /usr/share/emacs/22.0.50/lisp/vc-svn.elc
that emacs installs. Because of this conflict you can't use emacs 22's
svn vc until you remove the file /usr/share/emacs/site-lisp/vc-svn.el.
Therefore, I think it would be nice if emacs would remove that file
when it installs. Or atleast warn about it.

--
mvh Björn
Permalink | Reply | 0 comments |
headers
occ | 2 Mar 2006 01:39
Picon
Favicon

emacsclient --eval has slightly counterintuititve behaviour.

I've noticed something which may be a bug in the  -eval command in the
handling in the emacsclient/server. 

Summary: "emacsclient --eval" never returns if the passed elisp string
is invalid or fails. 

Version:  CVS (as of today) 

Example: 
emacsclient.emacs-snapshot --eval some_invalid_elisp

emacs *Messages* report: 
error in process filter: Symbol's value as variable is void:
some_invalid_elisp

(which is to be expected) 

emacsclient then sits there indefinitely trying to read from the server
socket. 

Expected result: at the very least emacsclient should return, at best
return with an error. 

Is there ever a way for an lisp expression invoked from emacsclient  to
write stuff back to emacsclient?  If not then having --eval -->
--no-wait in emacsclient would be sufficient to solve the problem. 

(although i think making the server always respond with at least a empty
write when it is invoked without -nowait is the polite thing to do)
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Sullivan via RT | 3 Mar 2006 17:44
Picon

[gnu.org #276495] Broken links re Emacs Lisp reference manual

> [edelsont <at> mac.com - Mon Feb 27 20:57:13 2006]:
> 
> At http://www.gnu.org/software/emacs/elisp/, these two links:
> 
> 
> #  formatted in HTML with one web page per node.
> 
> # formatted in HTML (900K gzipped tar file) with one web page per node.
> 
> 
> 
> are showing "Not found", while others are OK.  Is this temporary?
> 

Hello,

Thanks for the report. We don't seem to have those versions of the
manual built at the moment, so I have disabled the links. I'm CCing the
Emacs bug list to make sure that they are aware of the missing files.

--
John Sullivan
GNU Chief Webmaster
Permalink | Reply | 0 comments |
headers
Richard Stallman | 4 Mar 2006 14:37
Picon
Picon

Re: dangerous command in Makefile.in uninstall rule

    The cleanest way I know of is to have a single list of main Info files
    (i.e., without the -[0-9] etc. suffixes, and then do something like
    this:

       for f in ${INFO_FILES} do
	 rm -f $$f $$f-[1-9] $$f-[1-9][0-9]
       done

    We could then have the install target use INFO_FILES as well.

That is indeed clean.  Please install that.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 3 Mar 2006 13:35
Picon

Re: dangerous command in Makefile.in uninstall rule

> From: Richard Stallman <rms <at> gnu.org>
> Date: Mon, 27 Feb 2006 18:47:01 -0500
> Cc: bug-gnu-emacs <at> gnu.org
> 
>     $ rm -f cl* ada-mode*
>     autotype* calc* ccmode* ebrowse* efaq* eintr elisp*
>     eshell* eudc* idlwave* message* pcl-cvs* reftex*
>     speedbar* tramp* widget* woman* dired-x* ediff* emacs*
>     emacs-xtra* flymake* forms* gnus* info* mh-e*
>     newsticker* org* sc* ses* vip* smtpmail* url* rcirc*
>     erc*
> 
> We could make these more specific.  For instance, it could be
> 
> cl cl-*
> 
> or even
> 
> cl cl-[0-9] cl-[0-9][0-9]
> 
> for each one of the manuals.
> 
> But that is rather clumsy.  Is there any cleaner way to do it?

The cleanest way I know of is to have a single list of main Info files
(i.e., without the -[0-9] etc. suffixes, and then do something like
this:

   for f in ${INFO_FILES} do
     rm -f $$f $$f-[1-9] $$f-[1-9][0-9]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Karl Berry | 4 Mar 2006 23:58

Re: dangerous command in Makefile.in uninstall rule

                 rm -f $$relfile $$relfile-[0-9] $$relfile-[0-9][0-9]; \

Isn't that exactly what rms suggested?

It seems better (and way less work) than writing a new program that
parses info files to find out the filenames to me.
Permalink | Reply | 0 comments |
headers
Claudio Fontana | 5 Mar 2006 00:16
Picon
Favicon

Re: dangerous command in Makefile.in uninstall rule


--- Karl Berry <karl <at> freefriends.org> ha scritto: 

>                  rm -f $$relfile $$relfile-[0-9]
> $$relfile-[0-9][0-9]; \
> 
> Isn't that exactly what rms suggested?

yes, only enveloped in a for.

> It seems better (and way less work) than writing a
> new program that
> parses info files to find out the filenames to me.

Agreed.

CLaudio

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 5 Mar 2006 05:23
Picon

Re: Build fails on network home directories mounted over AFP + Parallel make doesn't work

> From: Alastair Houghton <alastair <at> alastairs-place.net>
> Date: Tue, 28 Feb 2006 14:30:46 +0000
> 
> Additionally, GNU Make's parallel make feature prevents Emacs from  
> building successfully (typically this results in "require" failures  
> when loading Elisp files).

Thanks, but please show the transcript of a build session where the
problems due to parallelism are clearly visible.  We need to fix this
problem.
Permalink | Reply | 2 comments |
headers
Andreas Schwab | 5 Mar 2006 11:44
Picon

Re: Build fails on network home directories mounted over AFP + Parallel make doesn't work

Alastair Houghton <alastair <at> alastairs-place.net> writes:

> Additionally, GNU Make's parallel make feature prevents Emacs from  
> building successfully (typically this results in "require" failures  
> when loading Elisp files).

I couldn't reproduce that with -j16 when building for ia64-linux, using
the current CVS sources.

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Permalink | Reply | 1 comment |
headers
Eli Zaretskii | 5 Mar 2006 20:52
Picon

Re: Build fails on network home directories mounted over AFP + Parallel make doesn't work

> From: Andreas Schwab <schwab <at> suse.de>
> Date: Sun, 05 Mar 2006 11:44:24 +0100
> Cc: bug-gnu-emacs <at> gnu.org
> 
> Alastair Houghton <alastair <at> alastairs-place.net> writes:
> 
> > Additionally, GNU Make's parallel make feature prevents Emacs from  
> > building successfully (typically this results in "require" failures  
> > when loading Elisp files).
> 
> I couldn't reproduce that with -j16 when building for ia64-linux, using
> the current CVS sources.

And I can build on MS-Windows using -j and -jN with N from 2 to 10.
That's why I asked for a transcript.
Permalink | Reply | 0 comments |

Gmane