[ When others could benefit, please don't take this off -beta. ] |--==> "MEM" == Meinhard E Mayer <hardy(a)weyl.ps.uci.edu&gt; writes: MEM> Thanks for your feedbak:0 MEM> gnus (from button) still crashes xemacs, MEM> I don't think I have it turned on -- unless that means that the MEM> description of the button appears in the mini-buffer. I looked MEM> all over in customization but found no way of turning this off. You would know if it was on, balloon-help pops up a tiny frame. You obviously don't have it on. :-) MEM> copy/paste with the mouse only (as in the non-gtk-version) does MEM> not work. One still needs to highlight a region, click on the MEM> copy button, move to new locaten, click the paste button. >>I couldn't reproduce this either. Do you have similar problems with >>other X apps? MEM> No -- gtk-xemacs is the only one where mosuse-highting does not MEM> copy into the clipboard/cut-buffer (in fact if I click on the MEM> middle button the minbuffer says so: "No selection clipboard or MEM> cut buffer available". This is reminiscent of Mac OX X behaviour MEM> (where I have to Command-C a region before pasting it with MEM> Command-V). MEM> cut buffer Does this mean that it _does_ work in an XEmacs configured with '--with-gtk=no'? Perhaps ping Bill Perry (Cc'd) MEM> The info-lockups seem to be due to the fact that if MEM> /usr/share/info is not group-writeable, and info-files are MEM> gzipped, info hangs trying to gunzip some file. My workaround MEM> was to make /usr/share/info writeable by me as non-root. >>Yep, you guessed it, couldn't reproduce this either. Not sure about >>this, maybe one or more of these could have something to do with >>it... >>,----[ What's the value of these variables? ] >>| Info-auto-generate-directory >>| Info-save-auto-generated-dir >>| Info-annotations-path >>`---- MEM> They all come up with "void" (unless I am invoking them MEM> incorrectly: MEM> (eval 'Info-save-auto-generated-dir) MEM> (eval 'Info-annotations-path) You need to have loaded info (M-x info) before XEmacs knows about those variables. But it sounds to me like you haven't changed them from their default values anyway (you would have said otherwise). MEM> This needs to be fixed, since most users don't have root MEM> privileges. >>I agree, but I don't think I've seen anyone else reporting this kind >>of behaviour. MEM> It did not happen to me before either -- or on another platform -- MEM> it seems to have to doo with the way RedHat installs info files MEM> in /usr/share/info. Is it just the gzipped files in /usr/share/info? Are the permissions on that directory, or the file therein, any different from say '/usr/info' or '/usr/local/info'? On my system (SteveWare GNU/Linux), /usr/info drwxr-xr-x root root (0755 user=root, group=root) and the files are all /usr/info/*.info.gz rw-r--r-- root root (0644 user=root, group=root) MEM> I had used some Mandrake stuff, and they MEM> bz2 their info-files. -- Those were theones -- I think -- did not MEM> work with standalone info. XEmacs will handle .bz2 info files, as will newer versions of the standalone info program. MEM> I don't use info that often -- MEM> thinking thet my 15 years of emacs-experience exempt me from this MEM> ... Wow! You've seen a lot of changes, I hope most of them have been good.:-) -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|