On Mon, Jan 23, 2017 at 4:36 AM, Eli Zaretskii <
address@hidden> wrote:
> That's fine with me, but if you read bug#17693, you will see that the
> original report there explicitly describes a situation where GUI
> frames were created by restoring desktop in a -nw session.
It wasn't the intention. OTOH, as a -nw session on GNU/Linux can have both GUI and tty frames, I'm not sure it is a bug, just we're entering unspecified territory. I mean, what if the user creates a GUI frame from a -nw session, and then exits and reenters Emacs in -nw mode. Shouldn't the GUI frame be restored too? We haven't decided (likely because the issue didn't present itself earlier than that bug report) how to deal when running mixed frames' instances.
Thinking about these issues, I suddenly realized that, if we were to treat -nw and GUI sessions as different (frameset-wise, I mean), we could just save the GUI frameset and the -nw frameset as distinct entities in the desktop file, and just restore the one appropriate. No mixing.
Currently, if you have an emacs GUI instance with frames A, B, and C. exit it, then enter a -nw session, frameset-restore tries to create frames A', B' and C' which share as many characteristics from A, B and C as possible. Obviously not size or position, but windows, buffers shown in them, etc. Then you return to GUI and get back A, B and C (assuming the -nw session didn't change or delete them). Well, it's not what happens *now*, but it is how the code was designed to perform.
But, is that what the user expects? Wouldn't it be easier to keep these kinds of sessions apart?
Additionally, frameset.el is designed to allow manipulation of framesets as objects, meaning that nothing precludes saving several of them (either in the desktop save file, or another file) with some kind of user identifier (a name or whatever) and then restoring on demand the desired frameset. It's just that desktop.el takes the easiest route, which is to save and restore a single frameset. But perhaps this isn't how we should be doing it.
All of this (bugs aside) is easy to implement, but before changing one line of code we should know what we want.
> Because the original code had worse problems, and we didn't know how
> to fix it better than that.
Wouldn't want anyone to believe that I was complaining or belittling you or anyone who had to deal with these bugs, I'm deeply sorry. Not my intention at all. It's me who wrote the code and went MIA. My fault entirely.