Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single file / multiple posts in single file support #14

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

nikclayton
Copy link
Contributor

Hi,

This is a work in progress, but I wanted to give you the chance to take a look before it's finished.

It enables a new way of working for writefreely, allowing the user to have multiple posts in a single Org file.

Each post should be its own first-level heading in the file, and each post can be posted, updated, or deleted individually. Per-post metadata is maintained as properties on the headings, instead of as Emacs file-local variables.

Things to probably fix before this is ready to merge:

  • I'm not sold on the idea of the customisation variable being called writefreely-multiple-mode (unless this actually made sense to be implemented as a derived minor mode...)

  • I haven't updated the docstrings or documentation.

  • Some of the functions should be renamed (e.g., writefreely--remove-org-buffer-locals -> writefreely--remove-post-metadata)

Thoughts?

Flycheck notes spaces after punctuation and missing punctuation.
Enabled by setting 'writefreely-multiple-mode' to t.

If enabled:

- Each first-level heading in the file can be published as its own post.

- Post metadata (id, token) is maintained as Org properties on the
  headline instead of Emacs file-local variables.
@dangom
Copy link
Owner

dangom commented Feb 17, 2019

This is really cool. Thanks for opening the PR.

I'm not sold on the idea of the customisation variable being called writefreely-multiple-mode

What do you think of writefreely-allow-multiple-posts-per-file, as in the brief documentation you wrote?

Alternatively, I think the coolest would be to have a sort of writefreely-multiple-mode-dwim kind of behaviour.

Upon publish or update we check:

  1. Does the current file contain writefreely buffer locals? If yes, update single mode. If not,
  2. Does the current heading contain writefreely properties?
    a. If yes, update multiple mode.
    b. If not, does any other heading contain writefreely properties? If yes, publish multiple mode. If not
  3. Query the user before publishing whether he would like to publish the whole file or just a heading.

Something in the lines of:

(let ((multiple-posts-per-file
       (cond ((boundp 'writefreely-post-id) nil)
             ((org-entry-get (point) "POST-ID" t) t)
             ((writefreely--any-other-heading-has-post-id) t)
             ((writefreely--query-user-multiple-posts-per-file))
             nil))))

- Separate the code that deals with properties in to separate functions.
- Write wrapper *-post-metadata functions that dispatch to the correct implementation.
@nikclayton
Copy link
Contributor Author

That strikes me as being a bit overkill. Step 2b will also potentially cause the amount of work to be done to post each entry to grow with every post.

How about either a single defcustom variable, or a property set in the file at the top level.

If a variable, call it writefreely-post-mode, where the allowed values are (at the moment) either 'single or 'multiple. Default value, for consistency with the current code, is 'single. I would expect that most users would customise this once and forget about it.

If a property, call it writefreely-post-mode and allow it to be set on a per-heading or per-file basis -- i.e., by writing #+PROPERTY: writefreely-post-mode multiple at the top of the file.

If the property doesn't exist then attempting to post will use the value from the variable and set the property at the top of the file to match the current value of the variable.

@dangom
Copy link
Owner

dangom commented Feb 22, 2019

I think your PROPERTY suggestion is a decent trade-off.

@nikclayton
Copy link
Contributor Author

I'll try and find some time to work on that this weekend.

@nikclayton
Copy link
Contributor Author

I'm not convinced it's possible to reliably write a #+PROPERTY line towards the top of the file. None of the Org property APIs seem to support this.

If you don't have a #+PROPERTY line for a property then org-entry-put throws a Before first headline error. And it throws the same error even if you do have one. I've asked on the mailing list in case I'm missing another "correct" way to do it.

This doesn't make sense as a per-heading property (what should the code do if one entry says multiple while another entry says single.

So for the time being I've got a customisation variable that the use can set. If they need it set to different things on a per-file basis then they can always use file-local variables to customise it. I gave it the suffix -posting-type, since ending it with -mode still feels weird.

@stormwatch
Copy link

Hello. Thank you both. I am going to try writefreely.el soon. I just wanted to ask if this would allow me to have several files, each one with multiple posts. If so, in which order would they appear when published?

Thanks again!

@dangom
Copy link
Owner

dangom commented Jul 21, 2019

Each post should be its own first-level heading in the file, and each post can be posted, updated, or deleted individually. Per-post metadata is maintained as properties on the headings, instead of as Emacs file-local variables.

They'll appear in the order that you post them.
And yes, you should be able to have multiple files with multiple posts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants