Re: Emacs's popularity

[Richard Riley]

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>> The reason I don't use the client/server setup is that I absolutely
>>> do not want C/Perl code buffers appearing or being offered to me
>>> while I'm doing stuff in GNUS, and I absolutely do not want newsgroup/
>>> SCORE buffers appearing or being offered to me when I'm doing stuff
>>> with coding. Is there any way to keep these two sessions independent
>>> and still use the client/server setup?
>>
>> I think the variable `server-window' could be useful. Or did you try
>> it already and didn't suit your needs?
>
> I've never tried it, and, looking at the documentation, I can't
> work out how to use it.
> """
> Documentation:
> Specification of the window to use for selecting Emacs server buffers.
> If nil, use the selected window.
> If it is a function, it should take one argument (a buffer) and
> display and select it.  A common value is `pop-to-buffer'.
> If it is a window, use that.
> If it is a frame, use the frame's selected window.
> """
>
> So I just created a new frame, and dragged it to my coding desktop,
> how do I find out how to identify that frame? Going there and 
> C-h v frame TAB gives:
> """
> Possible completions are:
> frame-background-mode              frame-creation-function
> frame-initial-frame                frame-initial-frame-alist
> frame-initial-geometry-arguments   frame-name-history
> frame-notice-user-settings         frame-title-format
> """
> Which looks useless.
>
> Maybe there's a function which will tell me how to identify the
> frame I'm in. C-h a frame doesn't really list much that seems useful.
> Maybe there's something that's not listed. M-x frame TAB does list
> a few more functions (why aren't they in the apropos?) - in particular
> frame-list. Something which looked like it appears to be identifiers
> for frames appears in the message bar, but annoyingly isn't selectable
> by the mouse (why isn't the text there selectable?). So I go to 
> the *Messages* buffer:
> """
> (#<frame *scratch* 0x85e1500> #<frame *followup to Juanma Barranquero on 
> gnu.emacs.help* 0x85d5fd0>)
> """
>
> So, let's try to use the former as an identifier for M-x set-variable 
> server-window
> """
> if: Invalid read syntax: "#"
> byte-code: Beginning of buffer
> """
>
> So the function that "Return[s] a list of all frames." apparently doesn't
> return anthing that can be directly used as an identifier for frames. 
>
> So how should I set server-window to be on my new frame?
> And how should it be done automatically?
>
> And here's one extra thing that's a bit puzzling - why is it a 
> server-*window*? Windows come and go, get split, resized and what-
> have-you. When I started the new frame, it had the windows, 
> according to M-x window-list, 
> (#<window 454 on *scratch*> #<window 464 on *scratch*>).
> But a few C-x 2, C-x o, and C-x 0 later, it's now 
> (#<window 490 on *scratch*> #<window 491 on *scratch*>).
> What good would it have done if I had succeded in setting the 
> server-window to one of the two original windows? Wouldn't a 
> server-frame be far more useful?
>
>
> Assuming "Emacs server buffers" means the buffers that were opened
> via the server, then that's only going to be a subset of the buffers
> that I'll want to be sandboxed together. M-x ff-f, and I'll have my 
> header files in there too; M-x compile or M-x ediff, and I could 
> have arbitrary other files and non-file buffers. So "being opened 
> via the server or not" is not a good way to separate the code buffers 
> from the GNUS buffers.
>
> And this is why I run 2 emacses, one for news, and one for coding.
>
> Phil

I was looking at server-window myself recently (this morning) hoping it
might address some issues with calling emacslient to connect to a
running emac without needing to specify a file name or "-c" for new
frame. It confused me a tad too.

I see your reasoning for two emacs - running the server with emacs, erc
etc running and numerous code buffer leads to all sorts of hassles when
doing someting like reading mail in gnus especially when you have an
article buffer open in another frame on another workspace in XMonad or
something :-;


-- 
 important and urgent problems of the technology of today are no longer the 
satisfactions of the primary needs or of archetypal wishes, but the reparation 
of the evils and damages by the technology of yesterday.  ~Dennis Gabor, 
Innovations:  Scientific, Technological and Social, 1970