Re: w32 does not have emacsclient/server
In emacsclient.c I've got rid of all AF_UNIX stuff. Doesn't sound so good. I'd rather make it possible to choose between Unix and TCP sockets (default to Unix when possible, and TCP otherwise). Oh. Well, the AF_UNIX code should be conditionally commented out on Windows, or do you mean to choose at run-time? As much as possible, it should be chosen at runtime, but under w32, the choice would have to be done at compile time since IIRC AF_UNIX doesn't exist, so the compilation would otherwise fail. I'd rather see server-name which could be a path to a unix socket (like now) or just a relative name of a unix socket (like now) or the name of a server to be found in ~/.emacs.servers. I.e. if there is no unix socket of that name, lookup ~/.emacs.servers for TCP servers. I'm not sure I'm getting what you intend with this. Why would you do have several servers on the same .emacs.server(s) file? - To run several instances of Emacs, each one a server, using the same .emacs.server? I think that would cause all kinds of race conditions; it'd be better to simply use different server files. Maybe you're right, and .emacs.servers should be a directory. So if you run emacsclient --server-name foo it would look for /tmp/emacsuid/foo for a unix socket and if that fails it'd look for ~/.emacs.servers/foo for a file holding the host/port/auth info. Sounds very good. To the host, port, and auth, I'd add a server name entry, which would default to server, to reproduce the socket-name thingy. OK. If the server name is in the file name, it doesn't need to be added inside the file. - Or, for one single Emacs to have several server instances? I don't I'm not sure this can currently work. I wouldn't worry about this case. The last change has been to make it consider \path and c:path as absolute paths (previously it would prepend the current directory to Windows-style absolute paths). Of course this should only be done under w32. Why? As I see it, the name you send is interpreted by the server, so the client has to be able to send absolute and relative paths for all environments (in fact, VMS or Mac ones should also be grokked, if emacsclient works on these environments). I mean, if I'm on a GNU/Linux, and the server is running on a Windows machine, emacsclient c:\my\file.txt is likely to be a file on the server... I'd basically assume that cross-host uses would only work right if both machines share the same file-system (and layout). In other cases, it's not really clear which behavior is right in which case. I.e. in your example where the command issued on the client refers to a path on the server, it may be preferable to use --eval (find-file c:\\my\\file.txt) to make it clear what is the intention. After all, * and other meta chars will be handled by the shell under the assumption that the argument to emacsclient is a local file name. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
Juanma Barranquero [EMAIL PROTECTED] writes: However, I tend to assume that people on the Emacs developers' list already knows such things this is not guaranteed. even if it were guaranteed, it is not guaranteed a universal reaction to exposure to already-known things. (the traffic on this list is public; we are just traipsing around on stage, according to some dead writer of poetry and prose.) it is good that you know what kinds of things you find insulting, the trick now is to use this self-knowledge to munge what you can munge. (give personally, but don't take it so -- less gray hair that way.) thi ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
One point that feels mysterious when you are new to these is the storing. Is this the same for all different mail agents in Emacs? The Emacs Lisp values should all be stored by Emacs the same way. Emacs is a virtual lisp machine. Everything that is in an Emacs Lisp expression is interpreted by the virtual machine. Programs that are not part of the virtual machine are often operating system dependent and their executables are architecture dependent. Thus, the variable rmail-delete-after-output has a value that is kept by the Emacs virtual machine. Regarding your second question, Another mysterious point is the settings for different mail agents. The setting above seems to suggest that this if for RMAIL only? Any variable can be used anywhere in Emacs. They are global. But the naming convention suggests they are for rmail only. It certainly makes sense that rmail-pop-password be advertized to other email clients by changing the name. We think of `rmail' as standing only for `read mail' but it could also stand for `retrieve mail' ... That alternative expansion suggests that we use the `retrieve mail' variables and functions in various programs. In any event, nowadays, I think your point should be well taken. The variable should be called mail-retrieve-remote-password (or something like that) rather than rmail-remote-password as is currently suggested. Moreover, all the movemail code should be moved to a new Emacs Lisp library called mail-retrieve-remotely.el (or something like that). For the past 20 or 30 years, rmail has been the default mail reader for Emacs. Since its beginning, Emacs has gained many email readers. For example MHE was originally written in 1983 for Gosling Emacs and ported to GNU Emacs shortly after. (From this perpective, as a mail reader, gnus is recent.) My thought is that the current names and lack of a separate library are a consequence of Emacs' history. (I am not sure of this; I have not paid attention to rmail.) RMAIL variables are like laws and social customs that may once have returned value greater than losses resulting from their suppression of cooperation but do not do so now. However, Emacs variables are global and voluntary so they do less damage to cooperation as they go obsolete than laws, since laws are involuntary. -- Robert J. Chassell [EMAIL PROTECTED] GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
No. But that does not make us, the people who use and work with Windows, unethical. Our priorities are a bit different, that's all. To use Windows is participating in an unethical activity. I would not go so far as to label each person who does so as unethical--they could be just negligent--but the act itself is unethical. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
What Bob has said in these messages is valid, and people who don't know it should learn it. However, it is true that the people on this list generally know these points. So I think the right way to mention them here is with a brief reminder, rather than an essay explaining the points as if to people who had not heard them. These essays can be useful to publish in places where they will be read by people who are not already aware of the issues. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Yes. And it might be reasonable to postpone _that_ until after the release. Even though it would probably be of the don't use it, and it won't break anything variety. I would really like it if people would turn their attention from this to the tasks listed in FOR-RELEASE. We could get a release made this year if people start doing those tasks. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/7/05, Richard M. Stallman [EMAIL PROTECTED] wrote: I would really like it if people would turn their attention from this to the tasks listed in FOR-RELEASE. We could get a release made this year if people start doing those tasks. Don't you think that TCP servers on Windows taking 100% CPU is a bug worth fixing before the release? -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
... Or are you referring to the fact that I do use Windows? By providing resources to a government-enforced monopoly that restricts what people I know and what I can do, you hurt me and my friends. I suspect you do not do much hurting and that you try to compensate, but nonetheless, you are hurting me and my friends. That is why I become angry. Technology has advanced over the past half century. Things that you `cannot drop on your foot', such as software programs, have become easier to manufacture. Indeed, they have become so easy to manufacture that we do not refer to the duplication process as `manufacturing'; we refer to it has `copying'. If I worked at Toyota, it would not sound strange for me to say, `we manufactured another car'. But it does sound strange to say that `I manufactured another Emacs' when I copied an instance. Software takes many resources to write the first instance of a program. (And it takes many resources to buy a computer.) But it takes few resources to make copies. It takes huge resources -- very competent people, in particular -- to write and maintain Emacs. But it takes few resources to make another copy of Emacs -- so few resources that I did not think twice this morning when I updated my CVS. Software is a `high initial/low incremental' cost good. Law and social customs that apply to `high initial/high incremental' cost goods should not be applied to items with low incremental costs. But they are. Partly this is because of social and legal inertia. Partly this is because people don't know a better way to fund high initial costs. Many people do not think of companies reducing complementary costs, of consortiums, of trade associations, of universities, of governments, and (to go by Aristotle) of individuals' rising wealth as providing ways to fund high initial cost actions. And partly this is because those who profit from charging this kind of high incremental prices need not themselves pay the whole cost. I wish you would help more to change laws and social customs that apply to `high initial/low incremental' cost activities rather than support, even just a little, inethical laws and social customs. But I do not know you or your conditions; only that you are hurting me and people I know. -- Robert J. Chassell [EMAIL PROTECTED] GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
Robert J. Chassell wrote: Law and social customs that apply to `high initial/high incremental' cost goods should not be applied to items with low incremental costs. But they are. Partly this is because of social and legal inertia. Partly this is because people don't know a better way to fund high initial costs. Many people do not think of companies reducing complementary costs, of consortiums, of trade associations, of universities, of governments, and (to go by Aristotle) of individuals' rising wealth as providing ways to fund high initial cost actions. And partly this is because those who profit from charging this kind of high incremental prices need not themselves pay the whole cost. I wish you would help more to change laws and social customs that apply to `high initial/low incremental' cost activities rather than support, even just a little, inethical laws and social customs. But I do not know you or your conditions; only that you are hurting me and people I know. Are you really sure that you are telling us something we have not thought about and discussed numerous times? Are you really sure that you are the one of us who have penetrated this area most? Are you really sure you are the one of us who have tried to change this most? Are you really sure we are not working with this? Are you really sure you are doing more than we working with this? Are you really sure that you are not hurting us? Could you please ask us about if we are with you or against you if that matters to you? You are very welcome to do that. Maybe we should save the list from much of this though. Maybe you could put up a blog about this? It is important issues and I will do that myself in a while. Maybe you can put up a blog and send us the link? I would be interested and I would try to give you feedback. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
Robert J. Chassell wrote: As far as I can see, `mail-host-address' is irrelevant when `user-mail-address' is set. Perhaps, I should just avoid setting it at all. Thanks for the clarification. Then the variables that that I think are salient to a .emacs file and that should be the same regardless of operating system would be: user-mail-address mail-default-reply-to rmail-delete-after-output rmail-confirm-expunge rmail-display-summary rmail-pop-password-required rmail-pop-password rmail-preserve-inbox Thanks also for these. One point that feels mysterious when you are new to these is the storing. Is this the same for all different mail agents in Emacs? Another mysterious point is the settings for different mail agents. The setting above seems to suggest that this if for RMAIL only? Is that the case? If not why are for example rmail-pop-password not called just mail-pop-password? It does not really look agent specific to me. Or does the different agents inherit from some common values? I would expect an inheritance from mail-pop-password = rmail-pop-password if the latter was not set. It feels natural and from a beginners point it would be very good. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
On 8/7/05, Robert J. Chassell [EMAIL PROTECTED] wrote: By providing resources to a government-enforced monopoly that [...] do not know you or your conditions; only that you are hurting me and people I know. Thanks for not saying anything new. Again. I think we're both ready to drop this thread. Still, if I ever ask anything related to Windows on this list (as I will surely do), I'd really appreciate if either you don't answer my question, or don't include your politics into it. Consider it as a personal plea. Thanks, /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
On 8/7/05, Eli Zaretskii [EMAIL PROTECTED] wrote: (Yes, it's my turn to preach ;-) FWIW, I like your preaching a lot. Thanks. (And yes, enough of this, at least from my quarters.) /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Date: Sat, 6 Aug 2005 02:02:40 +0200 From: Juanma Barranquero [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], emacs-devel@gnu.org Would someone *please* try and comment the changes? Or is there no interest on an emacs client/server accessible across the network and Windows-compatible too? I'd say, if no one posts any practical comments in a week or so, go ahead and commit the changes. After all, the Emacs development rules do not mandate any peer review at all. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Cc: Juanma Barranquero [EMAIL PROTECTED], emacs-devel@gnu.org From: Jason Rumney [EMAIL PROTECTED] Date: Sat, 06 Aug 2005 08:12:50 +0100 MUCH easier. In fact, it doesn't need any setup at all just to read messages and reply to them. You will only need to customize if you want to use features like archiving mail in folders separated by subject etc. That's not really true if you do not have the mail spool on your local machine. ??? Perhaps this is a misunderstanding. I didn't mean to say that nothing has to be done to configure how mail is fetched from the mailbox. But that part is not specific to RMAIL: _any_ mail package in Emacs will need to set this up, and the setup is (AFAIR) identical no matter what Emacs mail front end you use. Am I missing something? (For the record: my mailbox is not local, I fetch my mail from gnu.org machines using a Windows SSH client.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Eli Zaretskii wrote: ??? Perhaps this is a misunderstanding. I didn't mean to say that nothing has to be done to configure how mail is fetched from the mailbox. But that part is not specific to RMAIL: _any_ mail package in Emacs will need to set this up, and the setup is (AFAIR) identical no matter what Emacs mail front end you use. Am I missing something? (For the record: my mailbox is not local, I fetch my mail from gnu.org machines using a Windows SSH client.) Perhaps your missing that some of us just do not know how to do it. Could those of you that are using some mail client in Emacs on w32 perhaps post to the list and tell how this setup is done? Or if you think it is not relevant for this list post it to me and I will try to condense it to some useful instructions? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RMAIL settings [was: Re: w32 does not have emacsclient/server]
... some of us just do not know how to do it. Could those of you that are using some mail client in Emacs on w32 ... Microsoft is a corporation that endeavors to restrict both your economic freedom and mine. By that decision it has decided to require either that I behave illegally or that I transfer resources to it in a non-economic fashion. I have not done either and cannot help you directly. But in GNU/Linux, here are the RMAIL and mail setting that I specify in my .emacs file. You might adapt these: ;; Specify local inbox (setq rmail-primary-inbox-list '(/var/mail/bob)) ;; Do this to get mail directly from remote and local mail boxes: ;; (setq rmail-primary-inbox-list '(po:bob:fp.gnu.org /var/mail/bob)) ;; (setq rmail-pop-password-required t) ;; (setq rmail-pop-password XXX) ;; (setq rmail-preserve-inbox nil) ;; Set this value so that the From field is correct (setq mail-host-address [EMAIL PROTECTED]) ;; You must also set `user-mail-address' so that the From field is correct. (setq user-mail-address [EMAIL PROTECTED]) ;; Set the `reply-to' field for mail so people don't automatically ;; reply to root rather than bob when I am using root. (setq mail-default-reply-to [EMAIL PROTECTED]) ;; Do not automatically delete a message after it is copied to ;; another file using `o'. (setq rmail-delete-after-output nil) ;; Do not ask for confirmation when expunging (setq rmail-confirm-expunge nil) ;; Automatically display summary (setq rmail-display-summary t) My mail-user-agent's value is sendmail-user-agent, which is the default. -- Robert J. Chassell [EMAIL PROTECTED] GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/6/05, Eli Zaretskii [EMAIL PROTECTED] wrote: I'd say, if no one posts any practical comments in a week or so, go ahead and commit the changes. After all, the Emacs development rules do not mandate any peer review at all. You're right. I would've liked some comments, though, for two reasons: - It's an incompatible change, if small: --socket-name does not exist, and you *must* use either the EMACS_SERVER_FILE environment variable or the --server-file argument to emacsclient; otherwise emacsclient will refuse to work. - I've been vocal in stressing that I think our freeze is not very cold at all. So I'd like someone with a more objective POV to decide whether this (making emacsclient/server work on Windows and from remote machines) is a bug fix or a new feature. Of course I'd like to include it now, but I won't complain if the decision goes to shelving it for the moment being. -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Hi Lennart. Lennart Borgman said: Perhaps your missing that some of us just do not know how to do it. Could those of you that are using some mail client in Emacs on w32 perhaps post to the list and tell how this setup is done? Or if you think it is not relevant for this list post it to me and I will try to condense it to some useful instructions? Well i used gnus togehter with fetchmail (cygwin) on win32. That was a while ago and now i moved to debian gnu/linux for reading mails but the gnus setup i have did not change very much. So it should still work. I can post it here if you could need the info. However i'm no longer sure which of the settings are required and which go beyond basic setup. Regard, -- Stephan Stahl ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/6/05, Eli Zaretskii [EMAIL PROTECTED] wrote: ??? Perhaps this is a misunderstanding. I didn't mean to say that nothing has to be done to configure how mail is fetched from the mailbox. But that part is not specific to RMAIL: _any_ mail package in Emacs will need to set this up, and the setup is (AFAIR) identical no matter what Emacs mail front end you use. Am I missing something? AFAIK, gnus can fetch mail from a POP3 mail server; I don't need to worry about fetching the mail by hand with another program or anything. I gather is not so with RMAIL? -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
On 8/6/05, Robert J. Chassell [EMAIL PROTECTED] wrote: ... some of us just do not know how to do it. Could those of you that are using some mail client in Emacs on w32 ... Microsoft is a corporation that endeavors to restrict both your economic freedom and mine. By that decision it has decided to require either that I behave illegally or that I transfer resources to it in a non-economic fashion. I have not done either and cannot help you directly. Sorry, Robert, but this is ridiculous. Lennart asks for people who's using an email client on w32, and you do help by saying I don't, and then the usual rants about Microsoft. I know the politics of software freedom is on-topic on this list (judging by Richard's posts). But some of us *do* use Windows, MS-DOS, OS X and other non-free operating systems. Speaking for myself and no one else, I strongly think that getting political answers to technical questions, and in particular political tirades that are not new, that won't change my stance, and which do not add anything new to the debate is absurd. Perhaps some day I will abandon propriety operating systems (I would if there were a single GNU/Linux distribution I felt I was not going to hate in a few months), but if I do, it most definitely *won't be* because of your's (or anyone else's) rebukes. When I read paragraphs like the one above, I feel I'm being severely patronized, as if I were a child who doesn't know better. Not very nice, IMO. -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Juanma Barranquero [EMAIL PROTECTED] writes: On 8/6/05, Eli Zaretskii [EMAIL PROTECTED] wrote: I'd say, if no one posts any practical comments in a week or so, go ahead and commit the changes. After all, the Emacs development rules do not mandate any peer review at all. You're right. I would've liked some comments, though, for two reasons: - It's an incompatible change, if small: --socket-name does not exist, and you *must* use either the EMACS_SERVER_FILE environment variable or the --server-file argument to emacsclient; otherwise emacsclient will refuse to work. Uh what? Isn't there a default file name? - I've been vocal in stressing that I think our freeze is not very cold at all. So I'd like someone with a more objective POV to decide whether this (making emacsclient/server work on Windows and from remote machines) is a bug fix or a new feature. It is a new feature fixing a bug. Of course I'd like to include it now, but I won't complain if the decision goes to shelving it for the moment being. In my opinion it is one thing worth the hassle of ironing out, though it is definitely new. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Juanma Barranquero [EMAIL PROTECTED] writes: On 8/6/05, Lennart Borgman [EMAIL PROTECTED] wrote: Yes times are tough not to lose we must be rough follow rules Very funny. Still... Would someone *please* try and comment the changes? Or is there no interest on an emacs client/server accessible across the network and Windows-compatible too? Oh, there is. Actually, one thing I would like as added functionality in emacsclient is an option -t for tramp which would fork a shell and let it act as a tramp connection. That way, I could use emacsclient from a su-shell (by pointing EMACS_CLIENT_whatever to the respective credentials) to edit files without having to reenter a password. And of course, I'd like something that will let me use my local Emacs for editing files in some ssh session. This would require similar functionality, and probably some port forwarding. Lots of potential... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/6/05, David Kastrup [EMAIL PROTECTED] wrote: Oh, there is. Actually, one thing I would like as added functionality in emacsclient is an option -t for tramp which would fork a shell and let it act as a tramp connection. That way, I could use emacsclient from a su-shell (by pointing EMACS_CLIENT_whatever to the respective credentials) to edit files without having to reenter a password. I think after the new emacsclient is committed (if ever), I'll leave the implementation of what you're proposing to someone else with more knowledge of tramp, SSH and su. -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/6/05, David Kastrup [EMAIL PROTECTED] wrote: Uh what? Isn't there a default file name? No, there's not. What should it be? $HOME/.emacs.server, I suppose? It is a new feature fixing a bug. Well, thanks for clarifying it ;-) In my opinion it is one thing worth the hassle of ironing out, though it is definitely new. Ah, OK :-) -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Date: Sat, 06 Aug 2005 11:30:02 +0200 From: Lennart Borgman [EMAIL PROTECTED] CC: Jason Rumney [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org Could those of you that are using some mail client in Emacs on w32 perhaps post to the list and tell how this setup is done? I don't do anything that is not already described in the manual. There's no need: movemail works on Windows as well as on Posix platforms, and with exactly the same command-line options. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
So the options are, losing my computer, or Emacs losing a Windows maintainer? :-) I would rather see you living in freedom and maintaining Emacs for GNU/Linux. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/6/05, Richard M. Stallman [EMAIL PROTECTED] wrote: I would rather see you living in freedom and maintaining Emacs for GNU/Linux. Thanks. I appreciate your feelings. On that vein, I would much prefer to live in freedom and maintain Emacs for GNU/Hurd. Unfortunately, I'm not a kernel hacker so I'm not able to help in that project... -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
On 06 Aug 2005 19:09:30 -0400, Thien-Thi Nguyen [EMAIL PROTECTED] wrote: probably a great many injustices occur when the decision making process focuses purely on the technical or purely on the political. Of course. However, I tend to assume that people on the Emacs developers' list already knows such things, and has given some thought to the kind of issues Robert's bringing up. We're here developing not for an open source project, but for one of the flagships of the Project GNU. Restating the issues is often pointless. Restating them when the questions are technical is IMO almost insulting. Restating them as if people were clueless about, that's outright insulting. -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: RMAIL settings [was: Re: w32 does not have emacsclient/server]
... Worse still, you give the clear impression that you think that you know what's better for me, ... My apologies for giving that impression. That was not my intent. I am talking about what you are doing to me and to people I know well. I do not know what you prefer. Are you talking about free speech? Only partly. In this instance, mostly I am talking about being forced under penalty of law to transfer resources unfairly. -- Robert J. Chassell [EMAIL PROTECTED] GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
The same patch, but attached (I hate the things Gmail does to patches). -- /L/e/k/t/u server.patch Description: Binary data ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/5/05, Eli Zaretskii [EMAIL PROTECTED] wrote: May I suggest to use Emacs? Well, I can read Gmail at places where I don't have Emacs. And Gmail is generally so nice that I've started using it as my main e-mail interface, which says something, as I've always hated web-based e-mail and used run-of-the-mill POP3 clients. That said, what would you recommend as e-mail interface for a mostly-Windows Emacs user? Gnus? -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
The same patch, with a fix (there was a buffer overflow on emacsclient; not a security problem, but still...). send_to_emacs() is now much more rational. -- /L/e/k/t/u server.patch Description: Binary data ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Date: Fri, 5 Aug 2005 11:09:45 +0200 From: Juanma Barranquero [EMAIL PROTECTED] Cc: emacs-devel@gnu.org That said, what would you recommend as e-mail interface for a mostly-Windows Emacs user? Gnus? I use RMAIL, but Gnus should also work. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
That said, what would you recommend as e-mail interface for a mostly-Windows Emacs user? Gnus? I recommend that you defenestrate your computer. Either throw Windows out of the computer, or throw the computer out the window. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Richard M. Stallman [EMAIL PROTECTED] writes: That said, what would you recommend as e-mail interface for a mostly-Windows Emacs user? Gnus? I recommend that you defenestrate your computer. Either throw Windows out of the computer, or throw the computer out the window. The latter is just feasible for local delivery. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/5/05, Eli Zaretskii [EMAIL PROTECTED] wrote: I use RMAIL, but Gnus should also work. Is RMAIL easier to set up than Gnus? -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 8/6/05, Lennart Borgman [EMAIL PROTECTED] wrote: Yes times are tough not to lose we must be rough follow rules Very funny. Still... Would someone *please* try and comment the changes? Or is there no interest on an emacs client/server accessible across the network and Windows-compatible too? -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 7/15/05, Stefan Monnier [EMAIL PROTECTED] wrote: Actually, I don't think so. IIRC What we need for emacsclient/server to work on Windows is to make it work over TCP sockets rather than only over Unix sockets (because Windows supports TCL sockets but not Unix sockets). A good approach could be something like: in server.el, use a TCP server socket (on a non-specified port). Once opened, check to see which port was used. Write the port and hostname together with a secret random string into ~/.emacs_server. When a connection comes in, check that the first bytes sent are exactly the same as the random string (authentication). The following is a first cut at implementing this. server.el now creates an AF_INET socket, at an unspecified port. The host address is local (127.0.0.1) unless the user customizes the variable `server-host' to the IP or name to use to bind the socket. The server generates a 64-byte random string (not random bytes, but printable characters in the range `!'..`~'; it's still about 420 bits of entropy) and writes in `server-file' (by default ~/.emacs.server) the host, port and authentication string. Connections are expected to pass as the first thing in a communication exchange the string -auth AUTHENTICATION-STRING where AUTHENTICATION-STRING is the 64-byte secret key; otherwise the connection is closed immediately. In emacsclient.c I've got rid of all AF_UNIX stuff. I've also changed the code to use send/recv instead of writing to a file handle (was easier than fighting two Windows C compilers' idiosincrasies) and added buffering so data is only sent on receiving \n or filling the buffer. Argument `socket-name' has been replaced by `server-file', to indicate the path to the server config/auth file (alternatively, the variable EMACS_SERVER_FILE can be set to point to the file; and BTW, a better name for the variable would be very welcome). The last change has been to make it consider \path and c:path as absolute paths (previously it would prepend the current directory to Windows-style absolute paths). As it stands, it builds on Windows XP with GCC and MSVC. I'd like help with: - testing on other Windows environments - building *and* testing on non-Windows environments (it should work, but...) - configuration of lib-src/Makefile.w32-in (my change is a bit of a mess, I think) To do: - more testing - a bit of a cleanup, perhaps - documentation changes and of course any change, fix or redesign that is deemed necessary. Personally I'd like to add an option to force the host port and allow alternative (or even null) authentication strings, so in secure environments it'd be posible to use emacsclient/server.el with a fixed address/port and no .emacs.server file (emacsclient would have to grow --server-address and --server-port options, of course). But I digress... -- /L/e/k/t/u Index: lib-src/emacsclient.c === RCS file: /cvsroot/emacs/emacs/lib-src/emacsclient.c,v retrieving revision 1.74 diff -c -r1.74 emacsclient.c *** lib-src/emacsclient.c 4 Jul 2005 15:24:11 - 1.74 --- lib-src/emacsclient.c 5 Aug 2005 00:33:54 - *** *** 20,25 --- 20,28 Boston, MA 02110-1301, USA. */ + #define AUTH_STRING_LENGTH 64 + #define SEND_BUFFER_SIZE 4096 + #define NO_SHORTNAMES #ifdef HAVE_CONFIG_H *** *** 30,45 #include ctype.h #include stdio.h ! #include getopt.h #ifdef HAVE_UNISTD_H #include unistd.h #endif #ifdef VMS ! # include vms-pwd.h #else ! # include pwd.h #endif /* not VMS */ char *getenv (), *getwd (); char *(getcwd) (); --- 33,53 #include ctype.h #include stdio.h ! #include getopt.h #ifdef HAVE_UNISTD_H #include unistd.h #endif + #ifdef WINDOWSNT + #include winsock2.h + #else /* not WINDOWSNT */ + #include sys/socket.h #ifdef VMS ! #include vms-pwd.h #else ! #include pwd.h #endif /* not VMS */ + #endif /* not WINDOWSNT */ char *getenv (), *getwd (); char *(getcwd) (); *** *** 47,52 --- 55,72 #ifndef VERSION #define VERSION unspecified #endif + + #define SEND_STRING(data) (send_to_emacs (s, (data), 0)) + #define SEND_QUOTED(data) (quote_file_name (s, (data))) + + #ifndef EXIT_SUCCESS + #define EXIT_SUCCESS 0 + #endif + + #ifndef EXIT_FAILURE + #define EXIT_FAILURE 1 + #endif + /* Name used to invoke this program. */ char *progname; *** *** 61,71 char *display = NULL; /* If non-NULL, the name of an editor to fallback to if the server !is not running. --alternate-editor. */ ! const char * alternate_editor = NULL; ! /* If non-NULL, the filename of the UNIX socket. */ ! char *socket_name = NULL; void print_help_and_exit (); --- 81,96 char *display = NULL; /* If non-NULL, the name of an editor to fallback to if the server !is not running.
Re: w32 does not have emacsclient/server
OK but, what about connecting to a remote server? You don't need read access to the filesystem to do it, do you? How's that currently done? Currently it doesn't work. It'd be a new feature provided by TCP sockets. But for it to work safely, it needs authentication, which is what the random string is for. Since you need to get the random string, you may as well get the port number with it. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 7/15/05, Stefan Monnier [EMAIL PROTECTED] wrote: Actually, I don't think so. IIRC What we need for emacsclient/server to work on Windows is to make it work over TCP sockets rather than only over Unix sockets (because Windows supports TCL sockets but not Unix sockets). I'm taking a stab at this. Modifying server.el to use TCP sockets is trivial, and modifying emacsclient.c should not be hard *if* the Unix socket support is to be scrapped. in server.el, use a TCP server socket (on a non-specified port). Once opened, check to see which port was used. Write the port and hostname together with a secret random string into ~/.emacs_server. When a connection comes in, check that the first bytes sent are exactly the same as the random string I suppose this is to avoid choosing a port number as the standard Emacs server port? I'd rather choose a number, and let the user set it up on server.el and pass it to emacsclient.c in case there's a conflict on her system... Another parameter to pass would be the ip address, wouldn't? I'm assuming it's frequent on non-Windows environments to emacsclient against an Emacs server at another machine... -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Juanma Barranquero wrote: in server.el, use a TCP server socket (on a non-specified port). Once opened, check to see which port was used. Write the port and hostname together with a secret random string into ~/.emacs_server. When a connection comes in, check that the first bytes sent are exactly the same as the random string I suppose this is to avoid choosing a port number as the standard Emacs server port? I'd rather choose a number, and let the user set it up on server.el and pass it to emacsclient.c in case there's a conflict on her system... Multiple users can start servers on the same machine, so assigning a standard port is likely to conflict. It is better to let the socket library choose a free socket. The client will be reading it from a file anyway, so the user does not need to know what port has been chosen. Another parameter to pass would be the ip address, wouldn't? Stefan's spec above already includes the hostname. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Juanma Barranquero wrote: On 7/27/05, Jason Rumney [EMAIL PROTECTED] wrote: Multiple users can start servers on the same machine, so assigning a "standard" port is likely to conflict. It is better to let the socket library choose a free socket. The client will be reading it from a file anyway, so the user does not need to know what port has been chosen. OK but, what about connecting to a remote server? You don't need read access to the filesystem to do it, do you? How's that currently done? You need to be able to transfer the authorization file somehow. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 7/15/05, David Kastrup [EMAIL PROTECTED] wrote: Well, again this is an issue that the only people qualified to comment on are those that have actually experience with Windows, MSVC and the JPEG libraries, and it is likely that pretty much the only person qualified to comment on it is the one posting the questions in the first place. So nobody else chimes in. It basically becomes largely a one-man show of one person who keeps a record of his doubts and struggles in public. I think you're right on the general principle. But I'm talking of one specific problem (the JPEG/filehandle issue) that does not match your explanation: - The main issue I'm expecting to hear comments about is *legal*, not technical: whether the code from a file in jpeglib can be used or not (there are reasons why I think it could, that I did explain in my original message). - The change is not Windows-specific: it would affect every platform (in trivial ways, in fact). - The fix is not Windows-specific: the code has no Windows particularities of any kind, it's just a relatively straight change to call FILE*-oriented read/write functions directly instead of relying on the ones embedded in the image library. - If the decision of the legal issue is that the code in my patch can not be used (because it is lifted from a file in jpeglib), I can no re-code it (I think) because I'm tainted by having read and copied the original. Someone else should have to write three or four functions, no more than twenty or thirty lines of code. So, any kind of input on this issue, and pointers on how to approach it to push it to a conclusion, would be very appreciated. It is does no harm asking for second opinions and documenting what you are doing, but expecting continuous feedback for something where others are at least equally out of depth is a recipe for misery, and stumbling through foreign code is misery, anyway. Of course. In fact, the problem with library image crashes consisted of two similar, though unrelated, issues: one with jpeglib, the other with pnglib. I asked about both, and after a while I installed the pnglib patch, because it had no legal implications. So I'm fully aware that sometimes the answer to Warnock's Dilemma is: 6) Some people understood the question just fine, but had no insight to share, for whatever reason. I have no problem committing the code in this case, and I've done quite a few times. My comment about feeling a little left out is about the *other* cases, the ones where the feedback *is* important. That's why I've brought this up about... what, four times now? -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
There's a large number of issues specific to using Emacs on Windows that is not explained anywhere in the Emacs Manual. I would not be opposed to adding a certain amount of material to the existing section. However, if it is going to become large, it should be moved out of the manual. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Yes, I think Windows-specific appendix in the manual is sorely needed, to at least describe all those w32-SOMETHING functions and variables, if nothing else. I would rather not put them in the printed Lisp Manual. I was talking about user-level features and the User's Manual, not the Lisp Manual. The appendix that is suggested does not belong in the Emacs Manual. There already is a section on Windows usage in the Emacs Manual. But it is not the mission of the Emacs Manual to describe all those w32-SOMETHING functions and variables, any more than it is its mission to describe all the functions and variables that are NOT specifically for Windows. In nearly every aspect of Emacs, _completeness is not the goal_. Would people please stop making suggestions that we aim to do this or that in _complete_ manner? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
From: Richard M. Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-devel@gnu.org Date: Sun, 17 Jul 2005 13:36:19 -0400 I was talking about user-level features and the User's Manual, not the Lisp Manual. The appendix that is suggested does not belong in the Emacs Manual. Why not, if it describes user-level features? There already is a section on Windows usage in the Emacs Manual. No, there's an appendix called MS-DOS which describes mostly the DOS port and a small number of Windows related issues. But it is not the mission of the Emacs Manual to describe all those w32-SOMETHING functions and variables, any more than it is its mission to describe all the functions and variables that are NOT specifically for Windows. In nearly every aspect of Emacs, _completeness is not the goal_. This is not about completeness in any sense; perhaps the word all in all those w32-SOMETHING functions misled you to think that is what I was asking for. It isn't. There's a large number of issues specific to using Emacs on Windows that is not explained anywhere in the Emacs Manual. Some of the w32-SOMETHING functions and variables should be made known to Emacs users because they provide essential features without which some users would be simply lost. In addition, there are quite a few Windows-specific issues not related directly to any function or variable that should also be available in the manual. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Lennart Borgman [EMAIL PROTECTED] writes: Jason Rumney wrote: Ghostscript is not installed that way on w32. It is not supposed to be find in the PATH. Why? It seems very inconvenient to require programs to find other programs by searching for them manually in a registry, rather than using the PATH features that are built into the OS. There are several reasons I think. One reason is that installing new programs should not change system overall behaviour. Then why install them in the first place? A more important reason is that programs on w32 communicate differently than on GNU/Linux. The w32 way, COM (or what the current name for it is, it changes now and then), is rather similar to Corba on a conceptual level. Programs can call other programs through COM and get a result back. The Registry keeps track of the available COM components. Well, PATH keeps track of the available programs. COM is designed as interfaces with version control so it gives a rather flexibel environment. What use is there in interfaces with version control in a system that does not even support different versions of DLLs to be installed at the same time? Whatever we think of that this is the w32 way and to integrate in the w32 environment as first class citizens this must be accepted. It is not a goal for Emacs to be a first class w32 citizen. The goal for Emacs on Windows is to be as good an Emacs as elsewhere. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
David Kastrup wrote: There are several reasons I think. One reason is that installing new programs should not change system overall behaviour. Then why install them in the first place? I am sorry but this does not make sense. A more important reason is that programs on w32 communicate differently than on GNU/Linux. The w32 way, COM (or what the current name for it is, it changes now and then), is rather similar to Corba on a conceptual level. Programs can call other programs through COM and get a result back. The Registry keeps track of the available COM components. Well, PATH keeps track of the available programs. I am sorry again, you are simply oversimplifying. What use is there in interfaces with version control in a system that does not even support different versions of DLLs to be installed at the same time? Sorry, but obviously some users care about what version they are using and sometimes want to have different versions installed simultaneaously. Whatever we think of that this is the w32 way and to integrate in the w32 environment as first class citizens this must be accepted. It is not a goal for Emacs to be a first class w32 citizen. The goal for Emacs on Windows is to be as good an Emacs as elsewhere. I found this comment worth noting. The meaning of what you are writing here is not self evident. It must be further developed to be useful. One thing to think about is for example what do users on different system require of the programs they are using?. Even if users are not explicitly mentioned in your statement they are of course implicitly. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Lennart Borgman [EMAIL PROTECTED] writes: David Kastrup wrote: There are several reasons I think. One reason is that installing new programs should not change system overall behaviour. Then why install them in the first place? I am sorry but this does not make sense. Why bother to install software if it is not intended to make any difference? Whatever we think of that this is the w32 way and to integrate in the w32 environment as first class citizens this must be accepted. It is not a goal for Emacs to be a first class w32 citizen. The goal for Emacs on Windows is to be as good an Emacs as elsewhere. I found this comment worth noting. The meaning of what you are writing here is not self evident. It must be further developed to be useful. One thing to think about is for example what do users on different system require of the programs they are using?. Even if users are not explicitly mentioned in your statement they are of course implicitly. We are not bothered about Windows users. We are bothered about Emacs users. Making Emacs a first class w32 application is not a project goal. Making w32 a first class Emacs platform might be one. It may not have the same priority as other operating systems, but as long as somebody is willing to do the work, there is no principal problem as far as I can see. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
From: David Kastrup [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 00:33:52 +0200 Cc: Emacs Devel emacs-devel@gnu.org, Jason Rumney [EMAIL PROTECTED] Ghostscript is not installed that way on w32. It is not supposed to be find in the PATH. That is because the w32 architecture is different. You can only find Ghostscript through the registry (or searching the whole disk ;-) Does not sound too intelligent. The fact that it's different from the Posix paradigm does not mean it's not intelligent. Modifying global environment variables has its drawbacks. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
From: David Kastrup [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 08:14:10 +0200 Cc: Emacs Devel emacs-devel@gnu.org, Jason Rumney [EMAIL PROTECTED] Look, it is getting annoying. You have not _once_ in this whole thread clearly spelled out _what_ your problem is and what you want done. Actually, he did. Perhaps you weren't listening. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
From: David Kastrup [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 08:02:16 +0200 Cc: Emacs Devel emacs-devel@gnu.org, Jason Rumney [EMAIL PROTECTED] What use is there in interfaces with version control in a system that does not even support different versions of DLLs to be installed at the same time? Actually, it does. Perhaps you don't know enough about this issue to post such definitive opinions. The goal for Emacs on Windows is to be as good an Emacs as elsewhere. Yes. And reaching that goal sometimes requires Windows-only solutions, as much as reaching the same goal on GNU/Linux sometimes requires solutions that don't work on any other OS, even on Unix. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
From: David Kastrup [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 11:03:37 +0200 Cc: Emacs Devel emacs-devel@gnu.org, Jason Rumney [EMAIL PROTECTED] Lennart Borgman [EMAIL PROTECTED] writes: David Kastrup wrote: There are several reasons I think. One reason is that installing new programs should not change system overall behaviour. Then why install them in the first place? I am sorry but this does not make sense. Why bother to install software if it is not intended to make any difference? David, please stop this attitude. This thread is complicated even without nitpicking, and the fact that neither you nor Lennart are native English speakers doesn't help. Did you consider the possibility that you simply misunderstand each other? If you keenly don't understand something, may I suggest that next time you ask a question instead of posting ridicule? What Lennart was saying (AFAIU) is that installing a program should not affect the behavior of the parts of the system which have nothing to do with the program being installed. For example, installing Ghostscript should not affect an FTP client such as NcFTP in any way. If you modify PATH (or any other global environment variable), the potential for the unwanted effect is there. Now, I'm not saying that I could sign my name under this principle, but it certainly isn't ridiculous. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Date: Fri, 15 Jul 2005 19:55:13 +0200 From: Lennart Borgman [EMAIL PROTECTED] Cc: Emacs Devel emacs-devel@gnu.org I can for sure be more specific. Paper size on w32 must be fetched from the windows Registry because it is stored there. All major applications on w32 I know of does this. Here's one plan to attack and solve this problem: Step 1: Design a Lisp-level API for using the paper size. This API should be useful on all supported platforms. If necessary, discuss the design here and implement any corrections/suggestions. Step 2: Implement the API support for the w32 port. If that needs to read the Registry, do that in w32-specific files. (Jason already said, and I agree, that this doesn't require a general-purpose facility to read the Registry. In fact, Emacs already does read the Registry in several places without having such a GP facility.) Step 3: Ask experts for other platforms to implement the same functionality for their configurations. Better yet, if you have enough knowledge and/or help from those experts, implement it yourself, as part of adding this new API. If the functionality is useful, I don't see why this plan would fail or be met with resistance. Do you? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii wrote: Here's one plan to attack and solve this problem: Step 1: Design a Lisp-level API for using the paper size. This API should be useful on all supported platforms. If necessary, discuss the design here and implement any corrections/suggestions. Step 2: Implement the API support for the w32 port. If that needs to read the Registry, do that in w32-specific files. (Jason already said, and I agree, that this doesn't require a general-purpose facility to read the Registry. In fact, Emacs already does read the Registry in several places without having such a GP facility.) Step 3: Ask experts for other platforms to implement the same functionality for their configurations. Better yet, if you have enough knowledge and/or help from those experts, implement it yourself, as part of adding this new API. If the functionality is useful, I don't see why this plan would fail or be met with resistance. Do you? This is very good and I have hoped for this type of suggestions ever since I joined here. I might disagree to whether there should be a general facility to reading the Registry, but that is a minor point right now. Just as I guess you and Jason think there is a possibility that such a facility is misused and w32 only solutions are developed. I believe however that they can easily be converted to cross platform solutions and that they might help in fact help GNU/Linux by pushing the needs for common access of certain things. (But I do not know GNU/Linux sufficiently well. This is just a guess and I would welcome corrections.) Unfortunately I do not know how to do this on other platform. I will come back with a suggestion for an interface, if no one does suggest a posix style solution before me (which would be very nice!). ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Date: Fri, 15 Jul 2005 23:39:44 +0200 From: Lennart Borgman [EMAIL PROTECTED] Cc: Emacs Devel emacs-devel@gnu.org Paper size is one I remember right now. Another is the location of Ghostscript. How about adding some code to `openp' so that, on w32 platforms, it would look for the program/file in the Registry, in addition to the list of directories it gets as its argument? In other words, searching for a file or a program is already a functionality for which we have an established API in Emacs. Extending that API to handle Ghostscript and similar cases is something that IMHO will be met with less resistance than inventing a Windows-only API. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii wrote: Date: Fri, 15 Jul 2005 23:39:44 +0200 From: Lennart Borgman [EMAIL PROTECTED] Cc: Emacs Devel emacs-devel@gnu.org Paper size is one I remember right now. Another is the location of Ghostscript. How about adding some code to `openp' so that, on w32 platforms, it would look for the program/file in the Registry, in addition to the list of directories it gets as its argument? In other words, searching for a file or a program is already a functionality for which we have an established API in Emacs. Extending that API to handle Ghostscript and similar cases is something that IMHO will be met with less resistance than inventing a Windows-only API. A note for non w32 users: On w32 application paths are (if the installation process is welbehaved) stored in a Registry key under App Paths (with a path prepended, the registry has an hierarchical view looking like a tree structured file system). For those applications that uses this possibility I think this could be used. I found it however a bit hard to think of a seamless way to integrate this in openp. Could you elaborate a little bit more? My primary thoughts are that this could be restricted to the case when you search for an .exe file on w32 and this is not found in the path. In openp there is needed a piece of w32 specific code at the end that calls the w32 procedure. Not too disturbing perhaps. And it should work out of the box in most places in Emacs. Quite nice. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Jason Rumney wrote: Eli Zaretskii [EMAIL PROTECTED] writes: Date: Fri, 15 Jul 2005 23:39:44 +0200 From: Lennart Borgman [EMAIL PROTECTED] Cc: Emacs Devel emacs-devel@gnu.org Paper size is one I remember right now. Another is the location of Ghostscript. How about adding some code to `openp' so that, on w32 platforms, it would look for the program/file in the Registry, in addition to the list of directories it gets as its argument? Where do you look? This is the first time I have ever heard of looking for a path in the registry. You'd need to have a mapping of known programs to where they store their registry key telling you where their path is. There is no standard for doing this! HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\. There you will find for example a key named firefox.exe under which you find the actual path to firefox.exe. But you are right, not all programs use this, unfortunately. So in many cases you need a more specific mean to get the path, but it is still often in the Registry. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii [EMAIL PROTECTED] writes: Date: Fri, 15 Jul 2005 23:39:44 +0200 From: Lennart Borgman [EMAIL PROTECTED] Cc: Emacs Devel emacs-devel@gnu.org Paper size is one I remember right now. Another is the location of Ghostscript. How about adding some code to `openp' so that, on w32 platforms, it would look for the program/file in the Registry, in addition to the list of directories it gets as its argument? Where do you look? This is the first time I have ever heard of looking for a path in the registry. You'd need to have a mapping of known programs to where they store their registry key telling you where their path is. There is no standard for doing this! ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Lennart Borgman [EMAIL PROTECTED] writes: A note for non w32 users: On w32 application paths are (if the installation process is welbehaved) stored in a Registry key under App Paths (with a path prepended, the registry has an hierarchical view looking like a tree structured file system). This is misleading. The App Paths registry key is used for finding DLLs loaded by that application. Nothing more. To find this registry key requires knowing where the executable file it, since the path to this key within the registry is stored in the executable itself. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Cc: Eli Zaretskii [EMAIL PROTECTED], emacs-devel@gnu.org From: Jason Rumney [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 12:50:14 +0100 Lennart Borgman [EMAIL PROTECTED] writes: HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\. I see. The path is not as unpredictable as I thought. However, gs.exe or gswin32.exe is not listed in my registry, even though I have it installed, so this is not useful for finding ghostscript. We have a specific situation where looking in the Registry was suggested: finding Ghostscript. Lennart, can you tell how the Registry is used to find Ghostscript, and what applications do that? Then we could reason about possible utility of whatever those applications do to our case. Without the specifics, this argument sounds a bit academic. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Date: Sat, 16 Jul 2005 12:28:20 +0200 From: Lennart Borgman [EMAIL PROTECTED] CC: emacs-devel@gnu.org I found it however a bit hard to think of a seamless way to integrate this in openp. Could you elaborate a little bit more? Something like a call to a w32-specific function (whose code should be in some w32*.c file) near the beginning of openp sounds like the right thing to do. (I'm suggesting to look in the Registry _before_ you look along PATH because this is simpler and faster. But if there are good reasons to look along PATH first, let's hear them.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii wrote: Cc: Eli Zaretskii [EMAIL PROTECTED], emacs-devel@gnu.org From: Jason Rumney [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 12:50:14 +0100 Lennart Borgman [EMAIL PROTECTED] writes: HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\. I see. The path is not as unpredictable as I thought. However, gs.exe or gswin32.exe is not listed in my registry, even though I have it installed, so this is not useful for finding ghostscript. We have a specific situation where looking in the Registry was suggested: finding Ghostscript. Lennart, can you tell how the Registry is used to find Ghostscript, and what applications do that? Then we could reason about possible utility of whatever those applications do to our case. Without the specifics, this argument sounds a bit academic. In the case of Ghostscript it is actually quite complicated. I have code for finding Ghostscript in the file w32-regdat.el which is part of EmacsW32. This uses an external program to read the Registry. The actual Registry interface is in w32-reg-iface.el (also in EmacsW32). It is quite much code to put here on the list. If this is interesting for the arguments here then maybe you could look in the zip file found here: http://ourcomments.org/Emacs/DL/EmacsW32/ Finding GSview is in contrast very simple since it is in App Paths. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii wrote: Date: Sat, 16 Jul 2005 12:28:20 +0200 From: Lennart Borgman [EMAIL PROTECTED] CC: emacs-devel@gnu.org I found it however a bit hard to think of a seamless way to integrate this in openp. Could you elaborate a little bit more? Something like a call to a w32-specific function (whose code should be in some w32*.c file) near the beginning of openp sounds like the right thing to do. (I'm suggesting to look in the Registry _before_ you look along PATH because this is simpler and faster. But if there are good reasons to look along PATH first, let's hear them.) I think the page I sent a link to in reply to Jason suggests that looking in the Registry is done after searching the pach for ShellExecute. Testing the behaviour from Start Menu - Run also suggests so. So I think it should be at the end. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Jason Rumney wrote: Lennart Borgman [EMAIL PROTECTED] writes: HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\. I see. The path is not as unpredictable as I thought. However, gs.exe or gswin32.exe is not listed in my registry, even though I have it installed, so this is not useful for finding ghostscript. Yes, at the moment not, but I think this is something the authors of this packages should be noted of. Also, these keys are documented as being extra paths for that application to find its DLLs. Since the directory where the executable resides is automatically searched, it is not necessary to include that path in this key, so it is not a reliable way to find the executable. I do not think it is only for DLLs. I can not say that MS is very clear in their documentation, some info is hard to find. But look here, this page says that ShellExecute looks in App Paths: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_perceived_types.asp If you have firefox installed (and you do not have it in your path) you can try this: Open Start Menu - Run and enter firefox.exe. It will start Firefox. However just typing firefox.exe in a cmd.exe window does not work. This could be by intent (backward compatibility, trying to behave as other shells) or just a bug. In any case I believe that looking in App Paths for an entry could be useful -- and this behaviour would be in accordance with what ShellExecute does. Unfortunately it is for many applications more difficult to find the path. This is actually one of the reasons I think there should be a way to read the Registry from elisp. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Date: Sat, 16 Jul 2005 14:53:04 +0200 From: Lennart Borgman [EMAIL PROTECTED] CC: Jason Rumney [EMAIL PROTECTED], emacs-devel@gnu.org In the case of Ghostscript it is actually quite complicated. I have code for finding Ghostscript in the file w32-regdat.el which is part of EmacsW32. This uses an external program to read the Registry. The actual Registry interface is in w32-reg-iface.el (also in EmacsW32). Are you saying that w32-regdat.el's method of finding Ghostscript is how other programs, like GSView, find it? This is so ridiculously complicated that it's simpler to tell the users add the GS directory to your PATH. Note that the node MS-DOS Printing (which deals with Windows as well as DOS problems) already advises to use a full absolute file name of the Ghostscript executable in setting up ps-lpr-command. Is this the only place where a user would need to know the Ghostscript installation directory? Finding GSview is in contrast very simple since it is in App Paths. But we shouldn't need to launch GSview, should we? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 7/15/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Whats wrong with the situation extisting the last 10 years (estimated ;-): 1. Installing w32-emacs 2. Installing gnuserv/gnuclient 3. setting up gnuserv/gnuclient (AFAIK ~ 2 line in .emacs) 4. Having a well working Emacs-server on w32... Nothing, except: 1.1 Locating gnuserv/gnuclient. 1.2 Determining which one of the several available versions is best/newest. -- /L/e/k/t/u ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Date: Sat, 16 Jul 2005 14:40:00 +0200 From: Lennart Borgman [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-devel@gnu.org I do not think it is only for DLLs. I can not say that MS is very clear in their documentation, some info is hard to find. But look here, this page says that ShellExecute looks in App Paths: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_perceived_types.asp According to that article, there are a few more directories where openp should look for executables: the Windows directory and the Windows/System32 (Windows/system on Windows 9X) directory. Perhaps w32.c:init_environment should prepend these two directories to the value of PATH it sets up. Then they will be automatically searched. If you have firefox installed (and you do not have it in your path) you can try this: Open Start Menu - Run and enter firefox.exe. It will start Firefox. However just typing firefox.exe in a cmd.exe window does not work. This could be by intent (backward compatibility, trying to behave as other shells) or just a bug. So it sounds like adding to openp the search in App Paths would be useful at least in some cases. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii wrote: According to that article, there are a few more directories where openp should look for executables: the Windows directory and the Windows/System32 (Windows/system on Windows 9X) directory. Perhaps w32.c:init_environment should prepend these two directories to the value of PATH it sets up. Then they will be automatically searched. Maybe. Are they not in the path all the time? Also prepending them might cause problems. I have had problems with w32 find.exe and GNU find.exe. Appending might then be better? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii wrote: In the case of Ghostscript it is actually quite complicated. I have code for finding Ghostscript in the file w32-regdat.el which is part of EmacsW32. This uses an external program to read the Registry. The actual Registry interface is in w32-reg-iface.el (also in EmacsW32). Are you saying that w32-regdat.el's method of finding Ghostscript is how other programs, like GSView, find it? This is so ridiculously complicated that it's simpler to tell the users add the GS directory to your PATH. Yes, this is how GSView does it. I believe there might be a point in doing it the same way as GSView does it. Note that the node MS-DOS Printing (which deals with Windows as well as DOS problems) already advises to use a full absolute file name of the Ghostscript executable in setting up ps-lpr-command. Is this the only place where a user would need to know the Ghostscript installation directory? I believe so, is not printing.el using this too? The only thing I do is setting up this automatically for the user (since Ghostscript/GSview are not in the path). Finding GSview is in contrast very simple since it is in App Paths. But we shouldn't need to launch GSview, should we? I think I added this because printing.el uses it. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii [EMAIL PROTECTED] writes: Date: Fri, 15 Jul 2005 23:39:44 +0200 From: Lennart Borgman [EMAIL PROTECTED] Cc: Emacs Devel emacs-devel@gnu.org Paper size is one I remember right now. Another is the location of Ghostscript. How about adding some code to `openp' so that, on w32 platforms, it would look for the program/file in the Registry, in addition to the list of directories it gets as its argument? I remember just being told that the main advantage of the registry was that it was able to refer to several different installed versions of the same software. I don't see how this would be able to disambiguate between those installed versions. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii [EMAIL PROTECTED] writes: From: David Kastrup [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 08:14:10 +0200 Cc: Emacs Devel emacs-devel@gnu.org, Jason Rumney [EMAIL PROTECTED] Look, it is getting annoying. You have not _once_ in this whole thread clearly spelled out _what_ your problem is and what you want done. Actually, he did. Perhaps you weren't listening. Perhaps. So what is the particular application for which he needs the system paper size, and who has vetoed that anything be implemented that would make it accessible? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Yes, I think Windows-specific appendix in the manual is sorely needed, to at least describe all those w32-SOMETHING functions and variables, if nothing else. I would rather not put them in the printed Lisp Manual. A separate manual that we don't print would be better. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii [EMAIL PROTECTED] writes: According to that article, there are a few more directories where openp should look for executables: the Windows directory and the Windows/System32 (Windows/system on Windows 9X) directory. Perhaps w32.c:init_environment should prepend these two directories to the value of PATH it sets up. Then they will be automatically searched. Those directories are normally in the PATH already (at the start by default). If we want to make sure they are, I suggest appending, not prepending, as advanced users may prepend other directories deliberately, for example to get a Unix style find command instead of the Windows find.exe. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Eli Zaretskii [EMAIL PROTECTED] writes: (I'm suggesting to look in the Registry _before_ you look along PATH because this is simpler and faster. But if there are good reasons to look along PATH first, let's hear them.) Few users will know about this registry App Path (it was news to me), so they might find it surprising that their changes to PATH do not take effect. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Jason Rumney [EMAIL PROTECTED] writes: Eli Zaretskii [EMAIL PROTECTED] writes: (I'm suggesting to look in the Registry _before_ you look along PATH because this is simpler and faster. But if there are good reasons to look along PATH first, let's hear them.) Few users will know about this registry App Path (it was news to me), so they might find it surprising that their changes to PATH do not take effect. In particular, Emacs is a haven for people that are forced for some reason to use Windows. Those people will know how to manipulate PATH, and will be pretty much floored if it does not work. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Look, it is getting annoying. You have not _once_ in this whole thread clearly spelled out _what_ your problem is and what you want done. Actually, he did. Perhaps you weren't listening. With so much mail in this thread, I don't see how he could even read all of it. I can't even start. If someone wants to contribute code to make these features (which already exist on GNU-like systems) work on Windows also, then assuming it is clean and we get the papers for it, we can install it. Perhaps that settles the issue. (I couldn't read all the mail, so I can't be sure what the issue is.) Would people please terminate this argument? It is getting in the way of work on Emacs. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Ghostscript is a port of a Unix program, It's not a Unix program--it was developed for the GNU system, and GNU's Not Unix ;-). ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Cc: Lennart Borgman [EMAIL PROTECTED], emacs-devel@gnu.org From: David Kastrup [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 14:00:57 +0200 How about adding some code to `openp' so that, on w32 platforms, it would look for the program/file in the Registry, in addition to the list of directories it gets as its argument? I remember just being told that the main advantage of the registry was that it was able to refer to several different installed versions of the same software. If something can be found through the Registry, `openp' can be taught to do that. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org From: David Kastrup [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 13:56:43 +0200 Look, it is getting annoying. You have not _once_ in this whole thread clearly spelled out _what_ your problem is and what you want done. Actually, he did. Perhaps you weren't listening. Perhaps. So what is the particular application for which he needs the system paper size, and who has vetoed that anything be implemented that would make it accessible? Please read the rest of the thread, it's all there. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
From: Richard M. Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-devel@gnu.org, [EMAIL PROTECTED] Date: Sat, 16 Jul 2005 16:45:32 -0400 Yes, I think Windows-specific appendix in the manual is sorely needed, to at least describe all those w32-SOMETHING functions and variables, if nothing else. I would rather not put them in the printed Lisp Manual. I was talking about user-level features and the User's Manual, not the Lisp Manual. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Lennart Borgman [EMAIL PROTECTED] writes: I just want to tell that w32 still have no working emacsclient/server. Gnuserver/client is a workaround, but as far as I understand this can currently not be part of Emacs because of license problems. This sums up (in my opinion) that we can not distribute a fully working Emacs on w32. What should we do about this? Well, obviously port emacsclient. Somebody already took a look of it IIRC, but nothing has been heard of it since. And with any other stuff: if nobody does the work, it will not be done. As far as I remember, this is a simple nobody-did-it-yet case. It is not part of any strategy or something. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
David Kastrup wrote: Well, obviously port emacsclient. Somebody already took a look of it IIRC, but nothing has been heard of it since. And with any other stuff: if nobody does the work, it will not be done. As far as I remember, this is a simple nobody-did-it-yet case. It is not part of any strategy or something. Yes, nobody has done it yet and I believe there is no one working on it actively at the moment. I raised the issue to see if someone could do it. I have suggested that there might be too few developers on the w32 side. In that sense it may actually be part of a strategy. I would be glad to be proven wrong. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Jason Rumney wrote: Lennart Borgman wrote: I just want to tell that w32 still have no working emacsclient/server. Gnuserver/client is a workaround, but as far as I understand this can currently not be part of Emacs because of license problems. This sums up (in my opinion) that we can not distribute a fully working Emacs on w32. What should we do about this? Lennart, I am not sure what you are suggesting here. Are you suggesting that we withdraw all support for Windows due to the support we do have not being fully working? Are you suggesting that someone(TM) should drop every thing else in their life and port emacsclient now? If so, are you willing to pay for that to happen? Please don't shoot the messenger. What is wrong with carrying on with what we have been doing for the last 10 years, ie doing the best we can with the limited resources we have? I know we have done as much as we can but I do not think we have reached our goal in this case. I am looking for a way to handle this and I hope for good suggestions. The first thing is to hope for someone who can and want to do this. If this fail I think we at least should tell the truth about the state of Emacs in this respect. Maybe that could be done by simply writing that special documentation for w32 that someone (Eli?) suggested. I think this is very important. On my first tries with Emacs on w32 I just came to the conclusion that it was badly broken. Without the client/server capabilities it is not of much use for me. I did not found those so I just left. The actual reason I was looking at Emacs was that I was trying to get rid of a proprietary implementation of vi that actually had the client/server capabilities. I tried Vim which was better in some respect, but it did not have sufficiently good integration with w32 and therefore lacked good client/server capabilities. It took me too much time to use Vim therefore. When trying Emacs I got into the same problem. I saw these difficulties as failures of Emacs and Vim. Some people might see them as failures of w32, but I think that does not lead to anything useful. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
I have suggested that there might be too few developers on the w32 side. In that sense it may actually be part of a strategy. There is no conspiracy here. The number of developers reflects the number of volunteers. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Lennart Borgman [EMAIL PROTECTED] writes: David Kastrup wrote: Lennart Borgman [EMAIL PROTECTED] writes: Yes, nobody has done it yet and I believe there is no one working on it actively at the moment. I raised the issue to see if someone could do it. I have suggested that there might be too few developers on the w32 side. In that sense it may actually be part of a strategy. Oh nonsense. How many developers are _assigned_ to ports of Emacs on free operating systems? How many are _assigned_ to ports on proprietary Unix-like systems? Sorry, I think you are misunderstanding me. So how about actually saying what you mean? You make the same guess as I do. What should be allowed and what should not be allowed must be handled with care otherwise it will not make sense. Not doing that is just exercising power without saying so. If you have a concrete complaint to make about anything in particular that is not handled with care, feel free to do so. But general insinuations are completely useless. I personally find it quite disturbing that the policies do not allow for fetching for example paper size from within Emacs. Nonsense. If they are implemented as a general feature that would, for example, consult LC_PAPER on Posix-compliant systems, there is nothing speaking about doing this. But there will be no Windows-only features. If people want an Emacs that is fully useful only on Windows, then they can create their own fork instead of demand that their Winmacs be maintained and catered for by free software developers. You can work around that, but in the end you have done far less useful work than if it was allowed from within Emacs. It is not prohibited at all, as far as I can see. But that does not change that things like porting emacsclient don't happen by either magic or decree. I do not believe in either magic or decree ;-) Fine, then what are you complaining about? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Juanma Barranquero [EMAIL PROTECTED] writes: On 7/15/05, Jason Rumney [EMAIL PROTECTED] wrote: There is no conspiracy here. The number of developers reflects the number of volunteers. I absolutely agree with David and you on this issue. OTOH, as in any volunteer development effort, people often feels a bit left out. Warnock applies much more that many of us would like. That's totally justified (no one has the obligation to answer, or even read, every email), but sometimes it *is* a bit discouraging. God knows I'd like to finish the issue of the JPEG image libraries crashing on MSVC builds, but repeated requests for help or comment had gone unnoticed... Well, again this is an issue that the only people qualified to comment on are those that have actually experience with Windows, MSVC and the JPEG libraries, and it is likely that pretty much the only person qualified to comment on it is the one posting the questions in the first place. So nobody else chimes in. It basically becomes largely a one-man show of one person who keeps a record of his doubts and struggles in public. Actually, at the current point of time, I see this much more with Luc than with any Windows developer. He is working on a lot of things that nobody else seemingly has touched for quite a while. It is does no harm asking for second opinions and documenting what you are doing, but expecting continuous feedback for something where others are at least equally out of depth is a recipe for misery, and stumbling through foreign code is misery, anyway. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
On 7/15/05, Jason Rumney [EMAIL PROTECTED] wrote: There is no conspiracy here. The number of developers reflects the number of volunteers. I absolutely agree with David and you on this issue. OTOH, as in any volunteer development effort, people often feels a bit left out. Warnock applies much more that many of us would like. That's totally justified (no one has the obligation to answer, or even read, every email), but sometimes it *is* a bit discouraging. God knows I'd like to finish the issue of the JPEG image libraries crashing on MSVC builds, but repeated requests for help or comment had gone unnoticed... So my (possibly wrong) personal take on Lennart's words is that he's simply venting out a little bit of frustration. -- /L/e/k/t/u The problem with no response is that there are five possible interpretations: 1) The post is correct, well-written information that needs no follow-up commentary. There's nothing more to say except Yeah, what he said. 2) The post is complete and utter nonsense, and no one wants to waste the energy or bandwidth to even point this out. 3) No one read the post, for whatever reason. 4) No one understood the post, but won't ask for clarification, for whatever reason. 5) No one cares about the post, for whatever reason. -- Bryan C. Warnock, Warnock's Dilemma ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
David Kastrup wrote: I personally find it quite disturbing that the policies do not allow for fetching for example paper size from within Emacs. Nonsense. If they are implemented as a general feature that would, for example, consult LC_PAPER on Posix-compliant systems, there is nothing speaking about doing this. Are you suggesting that this can be done on w32? Can you then give me some pointers? Are you also saying that if it can not be done this way on w32 then we should not do it at all? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
David Kastrup wrote: The way to handle this is to create a working implementation of emacsclient. Feel free to go ahead. Sorry, I do not know network programming enough. Someone who could implement this must know this on both the unix style and winsock. The first thing is to hope for someone who can and want to do this. If this fail I think we at least should tell the truth about the state of Emacs in this respect. Where do we lie about it? I just looked again at all the files in CVS to see where gnuclient/server is mentioned. As far as I can see it is not mentioned anywhere that you should use gnuclient/server on w32. Beside this there is no pointer at all to the w32 version of gnuclient/server. Maybe all we can do at this stage is mention in Info how to get around the missing emacsclient/server on w32 and where to find gnuclient/server for w32? I think this is a minimum and I also think that this really should help new users on w32. Could this suggestion be accepted? I can of try writing this info. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
David Kastrup wrote: Lennart Borgman [EMAIL PROTECTED] writes: Yes, nobody has done it yet and I believe there is no one working on it actively at the moment. I raised the issue to see if someone could do it. I have suggested that there might be too few developers on the w32 side. In that sense it may actually be part of a strategy. Oh nonsense. How many developers are _assigned_ to ports of Emacs on free operating systems? How many are _assigned_ to ports on proprietary Unix-like systems? Sorry, I think you are misunderstanding me. Who do you think has the power to command all those resources? Why do you think we are taking years for the release to finish? Because the strategy does not involve assigning resources. The only way to work a strategy is to accept, encourage or refuse contributions. And with regard to proprietary systems, there is the policy that things like Windows-only features will not be accepted. That takes some of the fun out of working on Emacs for Windows, and so might account for a smaller number of developers. Frankly, I find it surprising that the Windows port runs as well as it seemingly does, given the minuscule amount of Windows-focused developers. You make the same guess as I do. What should be allowed and what should not be allowed must be handled with care otherwise it will not make sense. Not doing that is just exercising power without saying so. I personally find it quite disturbing that the policies do not allow for fetching for example paper size from within Emacs. You can work around that, but in the end you have done far less useful work than if it was allowed from withing Emacs. This and the small amount of developers I believe can cause trouble. But that does not change that things like porting emacsclient don't happen by either magic or decree. I do not believe in either magic or decree ;-) I would be glad to be proven wrong. Before you can be proven wrong, you need to come up with a coherent theory. General moping around that stuff gets not done all by itself on your platform is not something that is worth a proof. I try to share my thoughts on this. Others before me have preferred to leave. Since I believe GNU is a good thing I am staying. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Jason Rumney wrote: I have suggested that there might be too few developers on the w32 side. In that sense it may actually be part of a strategy. There is no conspiracy here. The number of developers reflects the number of volunteers. I am not at all talking about conspiracy. I am trying to tell what I suspect the current strategy leads to. (I e too few volunteers.) Sorry if my words where misleading, no insult was meant. However that was not the main purpose of my message. Please write about the problem I took up (no emacsclient/server on w32) and possible solutions. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Lennart Borgman [EMAIL PROTECTED] writes: Jason Rumney wrote: I have suggested that there might be too few developers on the w32 side. In that sense it may actually be part of a strategy. There is no conspiracy here. The number of developers reflects the number of volunteers. I am not at all talking about conspiracy. I am trying to tell what I suspect the current strategy leads to. (I e too few volunteers.) If we have an abundance of volunteers that refuse to improve Emacs except on proprietary platforms, we are worse off than we are now. However that was not the main purpose of my message. Please write about the problem I took up (no emacsclient/server on w32) and possible solutions. The solution is that somebody write a working emacsclient/server. Obviously, this someone is to be looked for among people actually using Windows. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Date: Fri, 15 Jul 2005 14:40:09 +0200 From: Lennart Borgman [EMAIL PROTECTED] Cc: Emacs Devel emacs-devel@gnu.org The first thing is to hope for someone who can and want to do this. If this fail I think we at least should tell the truth about the state of Emacs in this respect. Maybe that could be done by simply writing that special documentation for w32 that someone (Eli?) suggested. Yes, I think Windows-specific appendix in the manual is sorely needed, to at least describe all those w32-SOMETHING functions and variables, if nothing else. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Juanma Barranquero wrote: On 7/15/05, Jason Rumney [EMAIL PROTECTED] wrote: There is no conspiracy here. The number of developers reflects the number of volunteers. I absolutely agree with David and you on this issue. No problems. I do too. I am talking about consequences, not intentions. So my (possibly wrong) personal take on Lennart's words is that he's simply venting out a little bit of frustration. Yes, and I think when I now look at the answers that I was maybe more frustrated than I was aware of. Frustration wakes more frustration. BTW that was not my intention but it was a consequence of the way I wrote. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
Well that someone was me. The short version is that I completely dropped the ball on this and after volunteering to look at porting emacsclient to Windows never had the time to actually do it. I updated gnuclient at the time and then ran out of time when looking at all of the changes in the new emacsclient. Many moons ago when I looked at emacsclient it was a C client and a C server in a very similar pattern to gnuclient, now it's a lisp server wrapping core emacs functionality and a C client. Whilst I'm probably quite capable of dealing with the C code, I'm a complete neophyte when it comes to lisp and so part of my problem is not really having the time to learn enough lisp to add the support needed to get an acceptable working version. I feel pretty bad about this, but can't really kid myself that I'll suddenly get or make time. Guy David Kastrup wrote: Lennart Borgman [EMAIL PROTECTED] writes: I just want to tell that w32 still have no working emacsclient/server. Gnuserver/client is a workaround, but as far as I understand this can currently not be part of Emacs because of license problems. This sums up (in my opinion) that we can not distribute a fully working Emacs on w32. What should we do about this? Well, obviously port emacsclient. Somebody already took a look of it IIRC, but nothing has been heard of it since. And with any other stuff: if nobody does the work, it will not be done. As far as I remember, this is a simple nobody-did-it-yet case. It is not part of any strategy or something. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
David Kastrup wrote: I am not suggesting any such thing. I know nothing whatsoever about w32 and I consider life too short to change anything about that. Sorry, I thought you did. I have no idea what you are complaining about actually with regard to the paper size. It appears that you are currently in a bad mood and can't be bothered describing _any_ problem concretely enough so that it would even make sense talking about it. It is unclear what functionality is not implemented on what platforms and for what reasons, and why you think that somebody is sabotaging the implementation or whatever. It seems to have been a bad time mention this. The problem here is the different architectures between unix like OS:s and w32. If you are not interested in w32 then that is ok, but please do not assume that I write about intentions (like sabotage). I can for sure be more specific. Paper size on w32 must be fetched from the windows Registry because it is stored there. All major applications on w32 I know of does this. An implementation for accessing Registry on w32 was offered some years ago, but was not accepted. It is of course a w32 only solution, since the same things are accessed differently on unix like OS:es. But it actually in my opinion makes Emacs a bit less powerful on w32 that it can not access the registry. I do not expect you do comment on the details of this. I would however hope that you like to see the big picture. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Lennart Borgman [EMAIL PROTECTED] writes: David Kastrup wrote: I personally find it quite disturbing that the policies do not allow for fetching for example paper size from within Emacs. Nonsense. If they are implemented as a general feature that would, for example, consult LC_PAPER on Posix-compliant systems, there is nothing speaking about doing this. Are you suggesting that this can be done on w32? Can you then give me some pointers? I am not suggesting any such thing. I know nothing whatsoever about w32 and I consider life too short to change anything about that. What is your complaint? That some feature is not present at all, that it is present only on platforms other than w32, or that you would want it to be available only on w32? Are you also saying that if it can not be done this way on w32 then we should not do it at all? I am saying that _if_ it is done, it should not be done only on w32. As long as the feature is made available on the free platforms, it is no problem if the details of the implementation on w32 differ. But it is not a good idea to just implement stuff Windows-only. Emacs does not have as a goal to _force_ people to use proprietary systems if they hope to achieve something. If Microsoft offered a hundred programmers to work on improving Emacs, that would be an offer not lightly turned down. But they would not be permitted to improve Emacs just for the sake of Windows. I have no idea what you are complaining about actually with regard to the paper size. It appears that you are currently in a bad mood and can't be bothered describing _any_ problem concretely enough so that it would even make sense talking about it. It is unclear what functionality is not implemented on what platforms and for what reasons, and why you think that somebody is sabotaging the implementation or whatever. Please, stop this pointless unfocused bickering. It is taking time and attention from work that needs to be done, at the same time being so unspecific that it is completely unclear what this is even supposed to be about. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server
The solution is that somebody write a working emacsclient/server. Obviously, this someone is to be looked for among people actually using Windows. Actually, I don't think so. IIRC What we need for emacsclient/server to work on Windows is to make it work over TCP sockets rather than only over Unix sockets (because Windows supports TCL sockets but not Unix sockets). A good approach could be something like: in server.el, use a TCP server socket (on a non-specified port). Once opened, check to see which port was used. Write the port and hostname together with a secret random string into ~/.emacs_server. When a connection comes in, check that the first bytes sent are exactly the same as the random string (authentication). Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: w32 does not have emacsclient/server - getting paper size
Lennart Borgman [EMAIL PROTECTED] writes: An implementation for accessing Registry on w32 was offered some years ago, but was not accepted. I don't recall this. If it was anything like most such offers, someone submitted some code, the Emacs developers suggested some improvements, and we never heard from the author on that topic again. But anyway, reading specific settings from the registry does not require general registry editing functionality. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
