Ideas for wconfig and frameset restoration improvements

[rswgnu]

Hi Adam:

In your burly.el commentary you explain that URL formatting is used to serialize window and frame configuration information to strings and that Emacs bookmarks are used to save and retrieve these strings. But you don't say anything about why URL conventions are used; that would be helpful. If it is future anticipated usage, talk a bit about what you envision.

[alphapapa]

Hi Rob,

My initial idea was that buffers ought to be addressable by a value so that a buffer's contents and position could be restored even if the buffer doesn't exist. It seems much like addressing a resource in a browser with a URL, so a URL seemed like an obvious candidate for encoding the value. Emacs has built-in URL libraries that make it pretty simple as well.

Then I realized that the bookmarks system already provides a way to access many buffers' content. It's simple to encode a bookmark record into a URL as well.

When using the burly-bookmark-windows command, the URLs are never shown to the user, so it's not necessarily required to store the buffers as URLs (we could store the bookmark records directly in Lisp instead). However, as documented, bookmarks may not necessarily be satisfactory for some buffers, so a way to override that is provided (already implemented for Org buffers). In that case, a buffer's "location" is encoded as a URL. I suppose we could encode it as an alist, similarly to a bookmark record, and abandon the use of URLs altogether.

However, URLs do seem like a natural candidate. As well, they may be useful for accessing in other ways, like in Org links (although I suppose they're flexible enough that a Lisp list could be written directly into the link rather than encoding it into a URL).

I think the bottom line is that this is a very early version. I'm still exploring and experimenting. I might conclude that URLs aren't necessary, and we could just use Lisp lists instead. Or URLs might be useful enough to keep using them. I'm open to feedback on this, of course.

Thanks.

[a13]

I suppose we could encode it as an alist, similarly to a bookmark record, and abandon the use of URLs altogether.

Thanks, I got here to ask why don't we use a/p-lists for this :)

However, URLs do seem like a natural candidate.

as links - sure, but I still think to store them internally structured lists look like a more natural way to

[rswgnu]

The latest version of burly works for me on Emacs 27.1 without a problem.

I understand your URL rationale now, notably that there was a library function that made URLs easy for you to parse rather than there being any connection to the web. I think in that case moving away from URLs makes sense and instead using sexps which solve your parsing problem also makes sense. In fact, there is an older library called revive+.el (package = revive-plus, but you have to manually download it) that persists both window configs and framesets and uses sexps to store but does not have the bookmark interface. Despite its age, it also worked out of the box for me.

Check it out: revive-plus

I hope you will utilize that since it is built atop the revive.el you already use and it would extend burly to frameset handling as well as escreen session saving and thereby fulfill issue #8 . I would suggest you include in with burly since it is not on elpa or melpa.

[rswgnu]

My interest in burly is mainly to provide a simple library with few dependencies to save and restore window configs and framesets via Hyperbole buttons. Since Hyperbole implicit buttons can already invoke Elisp functions, a simple:

<burly-open-bookmark "Burly: my-wconfig">

in any text can restore a burly bookmark. it would be easy to simplify this syntax to something like:

<burly: my-wconfig>

or anything else desired as well.

[alphapapa]

@a13

as links - sure, but I still think to store them internally structured lists look like a more natural way to

For use purely within Emacs, yes. However, URLs may prove useful for use from outside of Emacs to access files or buffers within Emacs. Of course, this is yet to be implemented, and it would need careful consideration with regard to security. Anyway, the current code encodes and decodes alists to/from URLs without any problems that I'm aware of, so I'll probably leave that as-is unless and until I decide to abandon URLs completely.

Rob:

The latest version of burly works for me on Emacs 27.1 without a problem.

Great, thanks.

I understand your URL rationale now, notably that there was a library function that made URLs easy for you to parse rather than there being any connection to the web. I think in that case moving away from URLs makes sense and instead using sexps which solve your parsing problem also makes sense.

I'm not sure what parsing problem you mean. AFAIK they are working well.

In fact, there is an older library called revive+.el (package = revive-plus, but you have to manually download it) that persists both window configs and framesets and uses sexps to store but does not have the bookmark interface. Despite its age, it also worked out of the box for me.

Check it out: revive-plus

I hope you will utilize that since it is built atop the revive.el you already use and it would extend burly to frameset handling as well as escreen session saving and thereby fulfill issue #8 . I would suggest you include in with burly since it is not on elpa or melpa.

Actually, until yesterday, Burly used code borrowed from revive.el. I copied only the functions from it that were needed and renamed the symbols, putting them in the file burly-revive.el. However, 1. the code was BSD-licensed, and I'd prefer to keep all code in the project under one license, and 2. it had a bug that caused buffers to be restored to the wrong window sometimes.

So, thanks to Clemens' pointing me to some other Emacs functions, I replaced all of the code from revive.el with a few lines of code that does the same thing using newer Emacs functions (and since that old code was under a different license, I squashed the old commits and force-pushed to master to remove the BSD-licensed code from the repo). See #3

For restoring multiple frames, I think it shouldn't be difficult to use similar frame-related functions to do so. I don't think that code from revive-plus will be necessary. That idea's being tracked in #8.

I'm not sure about escreen session saving (I don't even know what escreen is, though it sounds familiar).

Regarding your Hyperbole syntax, I don't think you need a special burly link type, because Burly bookmarks are standard Emacs bookmarks that can be opened with standard bookmark commands. But you could make one that allows omitting the burly-bookmark-prefix if you wanted.

[rswgnu]

On Oct 27, 2020, at 8:59 AM, alphapapa ***@***.***> wrote:  as links - sure, but I still think to store them internally structured lists look like a more natural way to For use purely within Emacs, yes. However, URLs may prove useful for use from outside of Emacs to access files or buffers within Emacs. Of course, this is yet to be implemented, and it would need careful consideration with regard to security. Anyway, the current code encodes and decodes alists to/from URLs without any problems that I'm aware of, so I'll probably leave that as-is unless and until I decide to abandon URLs completely. Rob: The latest version of burly works for me on Emacs 27.1 without a problem. Great, thanks. I understand your URL rationale now, notably that there was a library function that made URLs easy for you to parse rather than there being any connection to the web. I think in that case moving away from URLs makes sense and instead using sexps which solve your parsing problem also makes sense. I'm not sure what parsing problem you mean. AFAIK they are working well.

Ok, I see.

In fact, there is an older library called revive+.el (package = revive-plus, but you have to manually download it) that persists both window configs and framesets and uses sexps to store but does not have the bookmark interface. Despite its age, it also worked out of the box for me. Check it out: revive-plus I hope you will utilize that since it is built atop the revive.el you already use and it would extend burly to frameset handling as well as escreen session saving and thereby fulfill issue #8 . I would suggest you include in with burly since it is not on elpa or melpa. Actually, until yesterday, Burly used code borrowed from revive.el. I copied only the functions from it that were needed and renamed the symbols, putting them in the file burly-revive.el. However, 1. the code was BSD-licensed, and I'd prefer to keep all code in the project under one license, and 2. it had a bug that caused buffers to be restored to the wrong window sometimes. So, thanks to Clemens' pointing me to some other Emacs functions, I replaced all of the code from revive.el with a few lines of code that does the same thing using newer Emacs functions (and since that old code was under a different license, I squashed the old commits and force-pushed to master to remove the BSD-licensed code from the repo). See #3

This is great news. I was actually going to ask you to consider doing so since I try to minimize dependencies when interfacing any package to Hyperbole.

For restoring multiple frames, I think it shouldn't be difficult to use similar frame-related functions to do so. I don't think that code from revive-plus will be necessary. That idea's being tracked in #8.

Ok.

I'm not sure about escreen session saving (I don't even know what escreen is, though it sounds familiar).

This lets you keep multiple remote terminal sessions going in the background that you can reattach to, I believe, so revive+ would save and restore sessions. I certainly don’t need that.

Regarding your Hyperbole syntax, I don't think you need a special burly link type, because Burly bookmarks are standard Emacs bookmarks that can be opened with standard bookmark commands. But you could make one that allows omitting the burly-bookmark-prefix if you wanted.

Right. The button type I showed is built in to Hyperbole. Impressed that your writing a burly manual as well. This could come out winderfully.

[alphapapa]

This lets you keep multiple remote terminal sessions going in the background that you can reattach to, I believe, so revive+ would save and restore sessions. I certainly don’t need that.

Yeah, I'd prefer not to support that directly. If someone needs that, maybe we could implement some hooks that would allow extensibility. Or maybe the existing burly-mode-map could be used to do that.

Impressed that your writing a burly manual as well.

The Info manual is just an export of the README.org file, similar to how Magit and Org themselves export their manuals from Org files. I do the same for org-ql and org-super-agenda. So I wouldn't say that I'm "writing" a manual. ;) But if you think of anything that should be added to the readme/manual, please let me know.

[minad]

@alphapapa I understand now the use case of urls and I agree that storing urls in org-files is a reasonable use-case. However I wonder if there could be a more principled solution.

1. burly does not use urls for bookmarks, simple stores plain old lisp objects
2. (in some other package?) implement mechanism to load/store bookmarks from/to an org document
3. (in some other package?) add some additional url-handling code to org-mode, such that org-mode can link to bookmarks, and bookmarks and org become somehow more integrated. In principle I wonder if it would make sense to offer a general url-action mechanism, where some arbitrary lisp-data+handler can be encoded as url such that actions can be triggered from inside a document. This obviously needs some white-listing regarding the handlers. Maybe something like this exists already. I am not yet very familiar with org.

As an alternative one could consider having url-support in burly only for storing/loading from urls inside documents. This means there would be two different load/store mechanism - via bookmarks and via urls.