Open a new instance of webmacs instead of a new buffer in the running instance

[FoilKiter]

In a multiple workspaces environment, it is sometimes not ideal when webmacs is already running in another workspace to have a new page opening in a new buffer there rather than in a new window on the current workspace. I currently have to make use of Mx make-window in webmacs and then move back that window to the original workspace through the window manager commands. To be honest, that's what I miss most from conkeror's behavior, as it is a very frequent situation in my qtile setup. In relation, having to do Mx quit for the last remaining buffer is a little cumbersome, as just killing it as all the others would be more streamlined IMHO.

[parkouss]

For the first point, do you mean that you would like the webmacs command line to open in a new window?

So running webmacs --new-window https://github.com/parkouss/webmacs/issues/82 for example would open a new window and the buffer in there? Would that be sufficient, or are you thinking about something else?

[parkouss]

For the second point, I just added in master branch (from #83) a new variable that can do that, close-buffer-close-window. You can set it to either "all" or "all-but-last" for your use case. Run C-h v close-buffer-close-window to get the full description.

[parkouss]

Now back to new "instances of webmacs instead of a new buffer".

By new instance, do you mean that you don't want the buffers to be shared? (a totaly new webmacs process)

• If yes, then there already is a --instance flag on the command line that does that. Though I guess you don't want to name each and every instance (the flag requires an instance name) so I could add something like if the given instance name is an empty string, then create a new one with a unique name.
• if you prefer the buffers (and other things shared) between windows (make-window does a new window, not a new instance) then I could work on something like I proposed above. I am thinking about:
  • a new command line flag, say --open-method that could take the values "new-buffer" or "new-window" for example
  • a webmacs variable that would act as a fallback when nothing is given on the command line.

What do you think ? Please do not hesitate to ask me if something is unclear.

[FoilKiter]

Sorry for the delay in answering, I wasn't home this weekend. Well you analyzed thouroughly the question and the implication about sharing or not the buffers between different instances is really interesting In a work-flow where one has to keep things separated but open in parallel, in different workspaces, it makes more sense in my opinion not to mix the names of buffers from unrelated things. So my answer would clearly be yes, a completely different process (and furthermore maybe that would that would be more stable as well, a nice potential side-effect, even if in my experience webmacs is already pretty stable.) I'm gonna look into the command-line instance-name flag, because for me it may be feasible in relation with the actual name of the workspaces that I already have, as those are existing parameters in my qtile config file, which is a .py file. And if that can't be managed, then your idea of a randomly generated unique identifier (akin to a PID in a way) is great. Thanks a lot for your help !

Edit : and thanks too for the smart function to exit the program from the last buffer, I'm going to update my installaiton to benefit from it right away !

[FoilKiter]

Well that is quite exciting, very promising : in effect, thanks to the --instance flag, one gets much more control over how many and where the instances are. And then every instance only shows its own buffers, pretty neat to work in well defined and contained spaces. Perhaps one thing to make it even more customizable could be to implement a series of alternatives that might go as follow :

• is there a running webmacs instance (or more) ?
  • no -> create a new instance (named automatically or with user-defined name)
  • yes -> do you want to use an existing one ? - no -> create a new instance (same as before) - yes -> which one do you wanna use ? (give choice among list of instances found) -> open a new buffer in chosen instance Looking at the emacs browse customization group, we find several examples of analog choices for firefox (open in new tab or window) or conkeror (open in new buffer or window). For someone using http links in org-mode for instance, some sort of equivalent mechanism could exist in this idea. Being able to set everything through command-line options would allow for an efficient experience. Of course one could always define default behavior for each step.

Getting a little carried away, one could also imagine the need to be able to 'send' a buffer from an instance to another, as sometimes one gets carried away and opens a webpage where it shouldn't, while there is another browser window better suited. At the moment with 'make-window' it is already 'movable' but I'm not aware of a function to 'reattach' it to a running instance. But this of less importance of course, just to say.

[parkouss]

I like the ideas above, this sounds good to me. I hope the design of having instances (versus lightweight windows) is a good bet though, as that can be memory and resources hungry.

That being said, maybe we can add:

• --instance '' to create an instance with a uniquely generated name
• --new-window to open in a new window (in a running instance)
• --list-instances to list instances and exit

Would that cover all the above use cases?

Sending a buffer to another instance (and with its history I think) would be totally doable too.

[FoilKiter]

The way I understand it then the process above could go as follows where there is a new url to visit : --list-instances indicates if that either : a new instance is to be created (when no other instance is found), and that would use --instance '' one or more instances exist and then it returns a list of these (to choose from as a target where to open the new buffer) --new-window would open the url in a new window of the existing instance chosen by the user --instance 'name_of_target' would take care of opening the url in a new buffer of an existing instance So yes, in my view, all the above use cases would thus be covered. :+1:

Would it be possible that --new-instance '' defaults to a uniquely random generated name , but also gives the user the possibility to define one ? Doing so would make the list of instances more meaningful and human-readable. The issue #17 that you refered to touches indeed a very similar need : grouping buffers into windows / instances in a logical way for the user. The point of using instances would be to separate cleanly the buffers. As for the risk of higher memory and cpu footprint, when compared to Chromium or Firefox, I reckon it would still be lower.

[dmille]

Are there still plans for adding the --new-window flag?

[dmille]

I've made a draft #113 for this functionality

[parkouss]

Sorry for the late reply here! Sure it will be good to have --new-window. I have made a comment on the PR I'd like you to answer - but it looks like --new-window will be there soon. :)

[spiderbit]

@parkouss: Would be still great to have that, heck that is for me a blocker basically, it seems so easy to implement (I might be wrong) and there is a PR for it and according to this thread you seemed to like the idea?

So do you have no time or did you forget it? It seems the PR is somehow closed or so, without giving any explanation why?