January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

rssh.el interactions with ange-ftp/efs 25 years, 10 months

Jan Vroonhof

Kai.Grossjohann(a)CS.Uni-Dortmund.DE writes: > I misquoted him. He actually said "I would not want to install > something into Emacs which uses ssh, which is non-free". Anyway. No > big deal. Hello Kai, I was looking (casually) into rssh.el today and although I didn't get it working (I do not know yet what caused it, sorry) I do have a proposal for you. Kai, may I suggest you change file names used to access rssh.el? I am also CC'ing some people involved in this as I also have a general suggestion. Currently you have for sssh.el paths /s:bblabla＠blabla:path the problem is that this also matches the efs path regexp. I haven't checked but it probably clashes with ange-ftp too. So if efs gets loaded (possibly automatically) after rssh.el has been installed the efs handler picks up the sssh path and complains. So after inspecting the regexps used I suggest you use something like /::xsh:user＠host:path (EFS paths cannot start with a colon) Ugly you say? Read on. However I suggest we go even further. What you really want is that the user simply times /user＠host:path and that Emacs figures out with remote access mechanism to use ( you have a variably remote-path-xsh-hosts or something like that). So I propose that a A. a new set of remote path names is introduced, which uniquely identifies the access method /::method:<method-specific-info> i.e. /::xsh:user＠host:path always uses Kai's stuff /::ftp:user＠host:path always EFS/ange-ftp In the future a http access method could be added etc. B. The general /user＠host:path remote filename specification is handled by a wrapper that decides what methods to use, based on specific values of user, host and path. C. file-remote-p and similar (if available) is changed to include the new types introduced by A. Jan P.S. The handler in B could even decide to just load the file if it is on a path that is also mounted on this machine.

1 participants
0 comments

Re: Need seperate .emacs file for testing 25 years, 10 months

Norbert Koch

"Clarence Donath" <donath(a)hks.com> writes: > I tried `xemacs -no-init-file -l my-init-file' like you suggested, > but all that does is give a blue 'load my-init-file' in the > upper-right corner of the window, and when I saved my changes, it > still saved to .emacs. > > It would be nice to have the option to use a different .emacs file > for a session, and any changes would be saved to that file. My > .emacs file also loads a config file called .xemacs-options so I > would be using another version of that called .xemacs-options-beta > so any changes would have to be saved to that file as well. Hmm, there is a variable `save-options-file' is a variable declared in Lisp. -- loaded from "/usr/local/src/xemacs/xemacs-21.2/xemacs/lisp/menubar-items.elc" Value: ".xemacs-options" Documentation: File to save options into. This file is loaded from your .emacs file. If this is a relative filename, it is put into the same directory as your .emacs file. Another variable is `custom-file' is a variable declared in Lisp. -- loaded from "cus-edit" Value: "~/.emacs" Documentation: File used for storing customization information. If you change this from the default "~/.emacs" you need to explicitly load that file for the settings to take effect. I assume that playing around with these two might give you a chance. Something like (setq save-options-file (expand-file-name "~/my-options-file") custom-file (expand-file-name "~/my-custom-file")) -norbert, guessing.

1 participants
0 comments

Re: Need seperate .emacs file for testing 25 years, 10 months

Clarence Donath

I tried `xemacs -no-init-file -l my-init-file' like you suggested, but all that does is give a blue 'load my-init-file' in the upper-right corner of the window, and when I saved my changes, it still saved to .emacs. It would be nice to have the option to use a different .emacs file for a session, and any changes would be saved to that file. My .emacs file also loads a config file called .xemacs-options so I would be using another version of that called .xemacs-options-beta so any changes would have to be saved to that file as well. Clarence On Jan 11, 15:41, Norbert Koch wrote: > Subject: Re: Need seperate .emacs file for testing > "Clarence Donath" <donath(a)hks.com> writes: > > > Is there a way to have my XEmacs beta use a different .emacs file > > than the one I use for XEmacs 20.4? I'd like to be able to run > > either version at any time, but I need to maintain different > > settings in each. I noticed there is a -no-init-file option and a > > -user option, but not one that lets me specify a name other than > > .emacs. > > Try a xemacs -no-init-file -l my-init-file > > -norbert. >-- End of excerpt from Norbert Koch

1 participants
0 comments

Re: set-text-properties question 25 years, 10 months

Colin Rafferty

Hrvoje Niksic writes: > Colin Rafferty <craffert(a)ms.com> writes: >> My basic problem is that I am copying strings from a buffer and >> writing them out. > Why don't you use `buffer-substring-no-properties', then? It seems > most suited for this operation. That's a very good idea. However, I'm getting the string in one place, and handling it in a different place. All that `b-s-n-p' does is call the blasphemous `set-text-properties', so I don't feel that bad. -- Colin

1 participants
0 comments

Re: Need seperate .emacs file for testing 25 years, 10 months

Norbert Koch

"Clarence Donath" <donath(a)hks.com> writes: > Is there a way to have my XEmacs beta use a different .emacs file > than the one I use for XEmacs 20.4? I'd like to be able to run > either version at any time, but I need to maintain different > settings in each. I noticed there is a -no-init-file option and a > -user option, but not one that lets me specify a name other than > .emacs. Try a xemacs -no-init-file -l my-init-file -norbert.

1 participants
0 comments

Need seperate .emacs file for testing 25 years, 10 months

Clarence Donath

Is there a way to have my XEmacs beta use a different .emacs file than the one I use for XEmacs 20.4? I'd like to be able to run either version at any time, but I need to maintain different settings in each. I noticed there is a -no-init-file option and a -user option, but not one that lets me specify a name other than .emacs. ____________________________________________________________ Clarence Donath Hibbitt, Karlsson and Sorensen, Inc. mrdo.com http://www.hks.com 1080 Main St., Pawtucket, RI 02860 \\\|/// Pawtucket: 401-727-4380 x5593 \\ _ _ // Providence: 401-454-4040 x5593 ( ＠＠ ) Fax: 401-727-4208 --oOOo-(_)-oOOo----- Troglodyte

1 participants
0 comments

Re: What to do with modules now ... 25 years, 10 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > Andy Piper <andyp(a)parallax.co.uk> writes: >> If this is the case (and I know that it is) doesn't this make >> dynamic loading less useful since you will have to have modules >> compiled for every sort of build (mule, non-mule etc) > Well, the modules will be distributed in source form, won't they? They'll have to be. There are too many subtle compile-time issues for it to be anything else. This is a good thing. > When you compile them, they get compile with the same options your > XEmacs was compiled against, and things work. Right.

1 participants
0 comments

Re: insertion of your web page 25 years, 10 months

Marcus Thiessel

Junichiro Hoken writes: | Dear Webmaster | | I am writing a book, "An Introduction to XEmacs", for beginners | in Japanese now. | The content of his book includes XEmacs basic manupilation and | Major Subsystems , for example VM, Gnus, Mew, and Emacs/W3. | I intend to increase XEmacs user in Japan publishing this book. | | So, I would like to insert you web top page (URL: http://www.xemacs.org) | hardcopy into my book. | I am very glad , you accept my request. Sorry for the delay in response. Unfortunately, I was out of town for a while. I think you can freely use the top page image for your book if none else (e.g. author of the current xemacs.gif) argues. I would appreaciate if you let us know when the book is in print that we could add a reference to it on http://www.xemacs.org. --Marcus

1 participants
0 comments

Re: What to do with modules now ... 25 years, 10 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> Now I will try to answer the points you make, but I admit > Hrvoje> that I no longer understand what point you are trying to > Hrvoje> make. > > My basic point is that I think that making Emchars and Bufbytes into > real objects with a linker-enforced interface would make it > (eventually) easier and less buggy to work with Mule and other > radical extensions of the idea that character == byte (text > properties?). But if Emchar were a real, linker-enforced object, then you would have to compile with Mule *always*, which is exactly what people bitch and moan about with FSFmacs. The slowdown might also be spectacular.

1 participants
0 comments

Re: What to do with modules now ... 25 years, 10 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: [...] Stephen, I'm not sure what we are discussing here anymore. Let me just stress two few points I consider important: * I hope I have now explained why it is technically very hard or impossible to *dynamically* load/unload an overwhelming extension such as Mule. This is what you apparently wanted from the new module stuff, and this is what I originally answered you about. * Mule coding conventions may be complex, but they are not bad, and not too hard to follow, once you get used to them (quite unlike GCPRO, I'd say.) And they *are* an abstraction -- at this time, with a flip of a lever (#define/undef MULE) you can build two totally different XEmacsen off the same general code. I can easily imagine there existing a third one, based on Unicode or whatnot. Now I will try to answer the points you make, but I admit that I no longer understand what point you are trying to make. > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > > >> Making people who have little direct interest in MULE conform > >> to complex coding conventions that they don't understand is > >> bad. If functions that must be MULE-aware could be localized > >> to a smaller set of modules, it would be a good thing. > > Hrvoje> You can't localize general concepts like "characters are > Hrvoje> not 1 byte". > > Of course you can, by making an opaque character object type and > manipulating instances only through messages. I believe that's what we have now (more or less), and it does involve a certain discipline. What is Emchar if not "opaque character object type"? > We may not like the amount of work involved or the efficiency loss. > The fact that 66 of the 201 .c files in my current xemacs-21/src > directory contain a reference to Emchar or Bufbyte suggests it'd be > horrendous. :-( What exactly do you find wrong with Emchar and Bufbyte? Why do you think a different implementation should get rid of those interfaces? > Hrvoje> If third-party contributors don't understand Mule coding > Hrvoje> conventions, too bad for them. Besides, the conventions > Hrvoje> are not all that complex, once you get to know them -- > Hrvoje> which goes for the rest of the XEmacs C sources. > > <DIV ATTITUDE="tongue-in-cheek"> > You are of course referring to the GCPRO convention? > </DIV> If you want it that way, yes, although you've intentionally chosen a very controversial point. To get a different point of view, try asking Michael Sperber what he thinks about "helpful" allocators that obviate the need for GCPRO. > I don't contest your points, pragmatically. But even now we still > have problems with integer vs. character comparisons cropping up > every once in a while. And your point is...? > Also, eventually we are going to have to modernize Mule; the current > implementation is just too constraining with the Japanese talking > about creating a completely new character set standard which will > have to coexist with the old one, only about 20% of the Chinese > standards implemented as yet, and Unicode not implemented at all. As I said above, I think it should be feasible to keep the current coding conventions, and change the underlying implementation.

2 participants
1 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta January 1999