Open nikclayton opened 5 years ago
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:
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))))
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.
I think your PROPERTY suggestion is a decent trade-off.
I'll try and find some time to work on that this weekend.
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.
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!
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!
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?