Pete Forman | 1 Oct 09:28 2003

Re: RPM Spec file for tramp

At 2003-09-30 12:20 -0600, Andrew Taylor wrote:
>I've coded up a quick Redhat RPM spec file for building an RPM package for 
>tramp 2.0.36.

Does that work for XEmacs as well?

--

-- 
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman <at> westerngeco.com    -./\.-   opinion of Schlumberger, Baker
http://petef.port5.com           -./\.-   Hughes or their divisions.
Norbert Koch | 1 Oct 17:55 2003
X-Face
Picon

Re: tramp (2.0.36); su and sudo hangs on FreeBSD when saving file

Michael Albinus <Michael.Albinus <at> alcatel.de> writes:

> Finally, I've committed the patch into CVS.

Thanks.

> But I'm a little bit confused: On my Debian, XEmacs is installed by
> default at "/usr/share/xemacs21"; the infodir is at
> "/usr/share/xemacs21/site-packages/info".
>
> Your patch would always require a "lib" subdirectory. Is there
> something wrong with Debian?

Uh, "wrong" might be too strong a word for it, but it deviates from
the intended standard layout [a].  I don't know what prompts the
respective maintainers to do so, but there might be reasons.

norbert.

Footnotes: 
[a] Other distros do the same, ie to deviate from the standard not to
    use Debian's structure.
Michael Albinus | 1 Oct 14:07 2003
Picon
Picon

Re: tramp (2.0.36); su and sudo hangs on FreeBSD when saving file

Michael Albinus <Michael.Albinus <at> alcatel.de> writes:

> Norbert Koch <nk <at> viteno.net> writes:
>
>> BTW, I've just stumbled across an error in the texi's Makefile
>> (generated).  I think the following patch is correct.  If you prefer
>> you can check for both share and lib as in the case of lisp dir, but
>> standard is lib (xemacs is a sibling to xemacs-$version which holds
>> the core information).
>
> Thanx for the patch. If Kai isn't able to checkin due to his movement,
> I'll apply the patch when I'm back from my recent business trip.

Finally, I've committed the patch into CVS.

But I'm a little bit confused: On my Debian, XEmacs is installed by
default at "/usr/share/xemacs21"; the infodir is at
"/usr/share/xemacs21/site-packages/info".

Your patch would always require a "lib" subdirectory. Is there
something wrong with Debian?

>> norbert.

Best regards, Michael.
SAITO Takuya | 3 Oct 18:50 2003
Picon

tramp (2.0.36); Error message on loading vc

When I start emacs with "emacs -q" and load byte-compiled bytecomp,
tramp, and vc in order, then
"Error: Symbol's function definition is void: cl-byte-compile-compiler-macro"
is displayed in *Compile-Log* buffer.

With evaluating this:
(progn
  (require 'bytecomp)
  (require 'tramp)
  (debug-on-entry 'byte-compile-report-error)
  (require 'vc))

I got this backtrace:

----
Debugger entered--entering a function:
* byte-compile-report-error((void-function cl-byte-compile-compiler-macro))
  byte-compile(advice-compilation)
  ad-compile-function(vc-workfile-unchanged-p)
  ad-activate-advised-definition(vc-workfile-unchanged-p nil)
  ad-activate(vc-workfile-unchanged-p nil)
----

I guess this is caused by the use of tramp-file-name-multi-method
and similar functions in defadvice for vc-workfile-unchanged-p,
because 'tramp-file-name-multi-method's 'byte-compile property is
'cl-byte-compile-compiler-macro.

 (get 'tramp-file-name-multi-method 'byte-compile)
    => cl-byte-compile-compiler-macro
(Continue reading)

Yoichi NAKAYAMA | 4 Oct 18:57 2003
X-Face

sync tramp_ja.texi with tramp.texi rev 2.98

Hello,
I've synchronized tramp_ja.texi with tramp.texi rev 2.98.
Attached diff is that, and small fixes on tramp.texi.

Regards,
--

-- 
Yoichi Nakayama
Attachment (tramp.texi.diff.gz): application/octet-stream, 787 bytes
Attachment (tramp_ja.texi.diff.gz): application/octet-stream, 39 KiB
_______________________________________________
Tramp-devel mailing list
Tramp-devel <at> nongnu.org
http://mail.nongnu.org/mailman/listinfo/tramp-devel
Alex Bernardin | 7 Oct 23:07 2003

problem with texi2dvi under cygwin


hi,

i've searched in the archives and found a couple of apparently related
problems, but the solutions provided didn't help me, so i'm posting
fresh.  i'm describing two problems that i encountered on install; one of
which i worked around, and one which i am stuck on. suggestions
appreciated; more detailed information available...

i've got NTemacs (version 20.7.1) installed on windows XP.  it's not
xemacs.

i've got the latest (as of 2003 october 1) cgywin installed, with the
following bash:

$ bash --version
GNU bash, version 2.05b.0(1)-release (i686-pc-cygwin)
Copyright (C) 2002 Free Software Foundation, Inc.

NOTE: i did not install the emacs that comes with cygwin, however, i
symlinked the NTemacs rnuemacs.exe to /bin/emacs.  it is possible to
start emacs from the cygwni cmd shell, but running it in batch mode
returns no output.

+++++++++++++++++++++++

the first problem that i ran into when installing tramp is that emacs run
from the cygwin bash seems problematic in batch mode.  the configure script
executes:
    ${EMACS} --no-site-file -batch -eval "(let ((x ${elisp}))
(Continue reading)

David Hanak | 8 Oct 12:11 2003
Face
Picon

Feature request/suggestion

Hi,

It seems to me (perhaps it's just an illusion) that the initialization
phase of a new tramp connection is a bit slower than in earlier versions.
(Not just via network, even /su:root <at> localhost initializes quite slowly.)
Anyhow, a little speedup would be welcome.  I thought that perhaps a cache
of host capabilities (ls -n, mimencode, etc.) would render some of the
checks unnecessary.  If you like the idea, I could try to implement it.

(Please followup in private, too, I'm not subscribed - yet.)
--

-- 
David Hanak
                                http://www.inf.bme.hu/~dhanak/index_en.html
Dept. of Computer Science and Information Theory          dhanak <at> inf.bme.hu
Budapest University of Technology and Economics        PGP key ID: 266BC45F
Kai Großjohann | 8 Oct 13:23 2003
Picon
Picon

Re: Feature request/suggestion

> It seems to me (perhaps it's just an illusion) that the initialization
> phase of a new tramp connection is a bit slower than in earlier versions.
> (Not just via network, even /su:root <at> localhost initializes quite slowly.)
> Anyhow, a little speedup would be welcome.  I thought that perhaps a cache
> of host capabilities (ls -n, mimencode, etc.) would render some of the
> checks unnecessary.  If you like the idea, I could try to implement it.

Currently, the checks are performed by sending a single command to the other
end, then waiting for the shell prompt, then sending another command, and so
on.  I think it could be quite a bit faster to send a shell script that does
all the detecting in one go.  This would also avoid all the problems with
caching.  There is already a little bit of that -- setting the remote path is
done with a single shell script.  It works quite well.

WDYT?

Kai

--

-- 
I like BOTH kinds of music!

NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++
Skip Montanaro | 8 Oct 15:26 2003
Picon

Re: Feature request/suggestion


    David> Hi, It seems to me (perhaps it's just an illusion) that the
    David> initialization phase of a new tramp connection is a bit slower
    David> than in earlier versions.  (Not just via network, even
    David> /su:root <at> localhost initializes quite slowly.)

I don't think it's an illusion.  Startup seems much slower to me as well.

    David> Anyhow, a little speedup would be welcome.  I thought that
    David> perhaps a cache of host capabilities (ls -n, mimencode, etc.)
    David> would render some of the checks unnecessary.  If you like the
    David> idea, I could try to implement it.

Please do.  Another thing which might help is to store the perl stuff
(file-attributes, etc) which tramp currently uploads on the remote host
(maybe in a user-specified remote directory) to avoid having to upload them
with each connection.

--

-- 
Skip Montanaro
Got gigs? http://www.musi-cal.com/
          http://www.mojam.com/
Got spam? http://spambayes.sf.net/
Steve Youngs | 8 Oct 23:45 2003
X-Face
Picon

Re: Feature request/suggestion

|--==> "KG" == Kai Großjohann <kai.grossjohann <at> gmx.net> writes:

  KG> I think it could be quite a bit faster to send a shell script
  KG> that does all the detecting in one go.  This would also avoid
  KG> all the problems with caching.

I know I've mentioned this before, but a reminder can't hurt. :-)
Have Tramp "learn" what the settings are for different hosts.

For an initial connect to a host, connect and detect as normal, but
save the results to ~/.tramp/known_hosts.el.  Subsequent connects
would have Tramp consulting ~/.tramp/known_hosts.el[1] and then
skipping the detect phase if it isn't needed.

You would also need a way to force a "connect/detect" process
regardless of what is in the known_hosts.el file.  In the event of
things changing on the remote host.  Probably the best way would be
and addition to the filename (prefix args are already used for
find-file and friends),  for example:

Right now, I use

        /[method/host]path/

If I wanted to force a detect during connection, I could

        /[DET/method/host]path/

Or if I didn't want the detection results saved to known_hosts.el:

(Continue reading)


Gmane