Sure, please see the attached patch series. Thanks, -- Matt * lisp/server.el: (server-external-socket-initialised): New (server-name): Compute server name from `get-external-sockname'. (server-socket
Thanks for the cleanup patch Paul! Please see the attached patch that should address these points. May I suggest `internal--daemon-sockname'? Thanks, -- Matt * lisp/server.el: (server-name): Update :
Fixed on the release branch. Fixed on master branch. But it affects the next one. I added this, but I don't think it should replace what's in the manual: not all the uses of the server are in daemon
Chapter 38 ‘Using Emacs as a Server’ in ‘GNU Emacs Manual’ says [0] the following: You can run multiple Emacs servers on the same machine by giving each one a unique “server name”, using
the idea is to initialise the emacs daemon depending on it's server-name. Therefore doing it via emacs-startup-hook is somewhat counter-intuitive But you are right that works. Thanks. Ciao, -- Gregor
thanks. Requiring server prevents this error, but `server-name' is not set to the command line value, though: ~$ cat ~/.emacs (require 'server) (when (equal server-name "foo") (setq greeting "My name
Sorry, I don't think I follow: what has intuition got to do with this? And what do you mean by "initialise the emacs daemon"? -- that happens out of your control, in the internal Emacs code. So does
Whatever you do that you need server-name for, can't you do that in emacs-startup-hook? AFAIR, that gets called after the daemon already finished its initialization and provided its name to Emacs, s
When emacs is started with emacs --daemon=foo (or emacsclinet -a "" -s foo [...]) one does not use `server-start'. Have (when (equal server-name "foo") (message "My name is foo!")) in .emacs and star
Dear emacs developers, if emacs is started as a named daemon like this: `emacs --damon=foo' or like this: `emacsclient -a "" -s foo [...]' the variable `server-name' is initialized with the name "foo
Hello, first of all I not sure if this is a bug report or more likely it is a feature request. Recently Emacs got code to start daemon by means of systemd. For this one needs to create two files: `em
Package: emacs Version: 23.0.60 There are several ways to set it (with --daemon=myname, or --eval, or M-: (setq ...)), but you're right: the documentation states that it is settable with set-variable
Warning (initialization): An error occurred while loading ´/home/grfz/.config/emacs/init.el´: Symbol's value as variable is void: server-name You should (require 'server) before referring to server
Thanks. I'm not an expert on this stuff, so I have only minor comments: . Please update the :version tag of server-name, to reflect the fact that its default value changes . This needs a NEWS entry,
I could not reproduce this bug with the latest bzr checkout, nor with Emacs 24.1 and 24.2. I think it's been fixed in the meantime; could you check it it still fails with you?
This regressions seems to have been introduced by change 105655. In set_local_socket the value of socket_name is destroyed in case of failing to connect to the server. That value is needed for starti
Hi emacs developers, emacsclient -a "" starts a new server if there is none before and connects to it. I would expect that emacsclient -a "" -s my-server-name behaves the same but starts a server wit
Oops - I missed an additional `-' on the variable name. That sounds fine; I wasn't aware that internal variables shouldn't be documented in the Emacs List Reference Manual. This last patch looks good
Yes, that sounds good. Can you prepare a patch along those lines? Sure, please see the attached patch series. Thanks, but aren't there some more places where the variable needs to be renamed to inter
Yes, that sounds good. Can you prepare a patch along those lines? Sorry, I lost track of this bug report. It'd be nice if you could re-propose a self-contained set of patches that address all the iss
Matthew proposed a patch for this here: https://lists.gnu.org/r/emacs-devel/2017-12/msg00903.html which I am attaching in git form (see first attached patch). I also propose the second attached patch
Matthew, can you please look at: http://bugs.gnu.org/24218 and follow up as seems appropriate? You can reply to this email to add to the bug-report log. Thanks.
Noam above was wrong: what I got was nil (tried it on another emacs, sorry) btw: I have done also (setq server-name "pe") --8<--cut here--start-->8-- Debugger entered--Lisp error: (error "‘/tmp/ema
Using Safari on Macos on https://debbugs.gnu.org/cgi/search.cgi, when I enter "server-name AND set-variable" and look in the results for 23576, I find ... as a Package: emacs Severity: minor; Sent by
"Using Emacs as a Server" says ... You can run multiple Emacs servers on the same machine by giving each one a unique “server name”, using the variable ‘server-name’. For example, ‘M-x set-
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If
Launch emacs-27, start the server. Now launch emacs-26 and start the server with a different. The problem is that emacs-27 creates the file /tmp/emacs($PID) as a symlink, while emacs-26 doesn't like
The FAQ has a problem, yes. Why you looked there instead of the manual is another question ;-) The FAQ is wrong and should be fixed. server-socket-dir is a defvar, whereas server-name is a defcustom
Right, but then it still seems like the documentation has a problem. For starters, server-socket-dir is extensively documented in the FAQ, while server-name is not at all mentioned. Does that really
Ah, OK. I had the impression that server-name was needed for other functions to work correctly, but that is not the case. Updated patch follows. Now it's your choice if you want this patch now or lat
xref.el doesn't know anything about add-log, and AFAICT doesn't customize it in any way, shape, or form. So I think this should be fixed in add-log.el. Its regexp is too naïve, and should be beefed
If you have an *xref* buffer with absolute Windows filenames, like ~/.emacs.d/init.el 93: server-name (replace-regexp-in-string "\\\\+" "\\" serv t t) 1102: (let ((s (whe
Here's a patch that adds support for --daemon=SERVER_NAME Using --daemon=SERVER_NAME for scripts is much nicer than: --daemon --eval '(setq server-name "SERVER_NAME")' So IMVHO something like this co
Attached is a patch to do this. Note that I named the new argument "noframe" because that matches the existing code in server.el (see 'server-delete-client'). It's a bit of a misnomer though, and may
[sorry if this is not the correct bug format, I'm replying to a message on gnu.emacs.help] I noticed a couple of different failure modes but this problem seems to be related to pselect. I'm appending
Can you explain how you arrived at the conclusion that -s names the directory of the socket file? My reading of the code is that it's indeed the name of the socket file, either with or without the l
Hi, In emacs -Q, do this: (progn (require 'server) (let ((server-name (concat "server_" (format-time-string "%H:%M:%S")))) (server-start))) Then I try to connect to this server, but it fails: When I
Why not? The manual currently has many of such explanations, e.g., in that same info node "(emacs)emacsclient Options": `-s SERVER-NAME' `--socket-name=SERVER-NAME' Connect to the Emacs server named
It's vaguely relevant that I have this in my .emacs: (progn (unless (< emacs-major-version 22) ;; Support multiple, concurrent Emacs servers. (setq server-name (format "server%d" (emacs-pid))) ;; All
Yes. With my patch, those messages will still show in exactly the same cases. No regression. Yes. Nope, it won't prevent us from doing that. My patch affects only *uncaught* errors, and improves beha
Have some faith in Emacs: we already do that. From startup.el: (let ((dn (daemonp))) (when dn (when (stringp dn) (setq server-name dn)) (server-start) (if server-process (daemon-initialized) (if (st
[Please use Reply All to reply, to keep the bug tracker CC'ed.] Well, I'd encourage you to try this, because if it works, then there is a solution to this situation, and if it doesn't work, we need t
I'm not sure I understand why you cannot successfully use the daemon in the situation you described. Basically, what your scenario means is that XDG_RUNTIME_DIR cannot be trusted because it is ephem
Since commit c6029ed34ea83c7c0adbd723d63bd78ff0ec0796 I am unable to build Emacs: make[4]: Leaving directory '/home/german/repos/emacs/admin/grammars' ELC+ELN ../lisp/custom.elc ELC+ELN ../
The Lisp Language specifies how conditions are to be handled. The Lisp machine can only be a virtual machine on which that lisp code runs. If the behaviour of a piece of lisp code (however it is invo
You called those functions directly, from outside of the Lisp machine, so the condition-case machinery is not working. There are inherent difficulties that require this behavior, sorry. I suggest to
server-running-p tries to start a server, and if it fails with a file error, then the condition-case is expected to catch it and the function is supposed to return nil. If I modify this function (see
You could simply customize server-name to an absolute file name. server.el runs that through expand-file-name with server-socket-dir as the default directory, which will leave an absolute file name
You can override it just as easily as with any defvar: (require 'server) (setq server-socket-dir "/path/to/dir") (setq server-name "myserver") (server-start) $ emacsclient -c -s /path/to/dir/myserver
GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.22.30) of 2018-06-26 I have set the Xresource *reverseVideo to true, and as expected emacs reverses the colours when launched under X,
Let me refine the report a little bit. Here is the search: http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=server-name&submit=Search%21&idxname=bug-gnu-emacs&max=1000&result=normal&sort=score B
Can do. Here's the patch, which should be applied in addition to the DAEMON_RUNNING patch I posted earlier. When server-start errors during startup, the error is printed to the terminal without conte
To be clear, the patch I posted which checks DAEMON_RUNNING *does* solve that. $ ./src/emacs -Q --fg-daemon=/tmp/foo Starting Emacs daemon. ‘/tmp’ is not a safe directory because it is not owned
To be clear, right now any error anywhere in command-line causes "emacs --fg-daemon" and "emacs --bg-daemon" to hang indefinitely, without printing an error, with no way to ever interact with the Ema
I'd prefer to handle each specific problem specially, to make sure the error message is self-explanatory. Also, if the error happens after the server has been started, there's no reason to forcibly
Actually, on second thought, we could fail anywhere in startup.el, not just in server-start. So should we actually have a wrapper around all of normal-top-level which detects an error at startup in a
Actually, it seems that main() already does a fputs ("Error: server did not start correctly\n", stderr); if the server process exits non-zero. So we already get a nice: Starting Emacs daemon. Creatin
I think you need to modify the tests to ensure the server file is created in a temporary directory. And keep in mind that the variable which affects that is different depending on whether server-use
Still fails, and here's why: Client output: d:\gnu\git\emacs\trunk\lib-src\emacsclient.exe: unrecognized option '--socket-name' Try 'd:\gnu\git\emacs\trunk\lib-src\emacsclient.exe --help' for more i
I think you need to modify the tests to ensure the server file is created in a temporary directory. And keep in mind that the variable which affects that is different depending on whether server-use-
Philipp> This is unfortunately a bit hard to reproduce and probably depends on Philipp> details of the system. However, the following steps work for me: Philipp> 1. emacs -Q -l server -eval '(setq s
This is unfortunately a bit hard to reproduce and probably depends on details of the system. However, the following steps work for me: 1. emacs -Q -l server -eval '(setq server-name "/tmp/emacs.sock"
In my defense, I actually looked at both. :-) For now, maybe it's enough to just remove the details on server-socket-dir from the FAQ, and add a reference to the manual where users can find the docum
It seems like this was fixed in Emacs 26.1. I'm therefore closing this bug. If anyone is still seeing these problems on that version or later, please report back so we can reopen it. Best regards, St
The data you collected shows that your attempt to restart the server signals an error: See the call to report_file_errno in frame #5? Signaling an error while waiting for input is fatal in Emacs, so
Hello - I got tired of checking/remembering whether (nth 3 (syntax-ppss)) was a string or a comment, so I've created two simple functions that wrap that in a more descriptive name. I've noticed that
I believe said gdb magic requires you to have ptrace capabilities on the process in question, which is a stronger requirement than being able to send a signal (unless youʼre root, of course). A slig
Chould you check if it still occurs with an Emacs 26 pretest? I think there were some fixes around terminal deletion that *may* be relevant. Also, just to rule things things out, check if it happens
"Garbled"? What do you see there, exactly, and what browser did you use to do that? I see nothing garbled, everything is perfectly legible and clear. I wonder what did you do differently and what di
I tried the link above. It takes an unnatural amount of effort to find the bug between the garbled titles and summary lines. But aren't you alarmed it works so poorly? Sorry, I didn't see that. Where
No, the bugs in the documentation were fixed. It's just that they were fixed for the upcoming Emacs 26.1, and you are using 25.3. You are welcome to try the pretest of Emacs 26.1, which is available
My suggestion is to use the search engine of the bug tracker, at https://debbugs.gnu.org/cgi/search.cgi It is more sophisticated and does find the above bug report. The reasons why the mailman searc
lists.gnu.org is general GNU infrastructure not maintained by anyone here at Emacs. I'm not sure what the right contact address is; perhaps mailman at gnu.org.
To see an example, search bug-gnu-emacs for 'server-name', e.g., http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=server-name&submit=Search%21&idxname=bug-gnu-emacs&max=20&result=normal&sort=sco