don't automatically change content of headlines

Assume I have an org-file that looks like the following:

* headline A
- item 1
- item 2

* headline B
some text

If I load this file into orgzly, add another headline, and subsequently save it, the file is changed so it looks like:

* headline A

- item 1
- item 2

* headline B

some text

* headline C

Please have orgzly leave the line-spacing alone, and not insert blank lines if I haven't explicitly added them!

Have you tried options under "Org file format" in Settings (the first two)?

Orgzly doesn't try to be too smart there, it will either add an empty line or not, depending on the options. Is this behaviour applied to all notes OK for you?

I suppose it's better than only having the line-inserting behavior, but I would really prefer to be able to have it not be smart at all -- to leave things the way it finds them. Maybe add a third option in addition to the line and no-line options: the 'leave as-is' option?

Maybe add a third option in addition to the line and no-line options: the 'leave as-is' option?

The problem with that (and why it hasn't been done from the start as the only option) is that you would either:

• Have empty line(s) at the beginning of the note's content in Orgzly, which: looks ugly, makes editing harder, exposes properties of org file generation etc.

• Have to keep track of number of lines that separate title from the content in database, for each note. That just felt like an overkill. Also, if one has a reason why he'd sometimes separate the content and sometimes not, that might change while editing the note. Perhaps you had a list at the beginning which you usually glue to the title, but now you inserted some test before it and want to separate it. Which means the user would want to be able to edit that number of lines per note. Which couldn't be right there in the note as it's org-specific, but would have to be at least in the overflow menu. I think it would be just be one big mess.

I guess an option not to strip whitespace from the content could be added. So if you use it, you know what to expect - empty lines at the beginning of content. And you'd have to remember they matter and why.

I understand the points you raised about it. The use case I have is to use emacs most of the time for editing some file, and periodically to use orgzly to view and modify it. This file is revision controlled, and it's important to be able to see what the real changes to the file are, and not ones that are cosmetic changes made by orgzly.

In the same vein as the added or removed empty-lines, it seems that orgzly also changes the location of tags within a headline. What seems ideal to support the above use-case is for orgzly never to change anything formatting-wise unless it's explicitly modified by the orgzly user. This is also important when you're working with files that are regularly exported to other formats where whitespace or empty lines makes a difference in the exported result. Does that make sense?

This file is revision controlled, and it's important to be able to see what the real changes to the file are, and not ones that are cosmetic changes made by orgzly.

This should be a one-time thing though - the first time changes from app are synced.

In the same vein as the added or removed empty-lines, it seems that orgzly also changes the location of tags within a headline.

Yes, this will also be configurable (#167).

What seems ideal to support the above use-case is for orgzly never to change anything formatting-wise unless it's explicitly modified by the orgzly user.

I agree. Those two things you mentioned should be the only ones (I mentioned then long time ago under "Generated Org files" on http://www.orgzly.com/help).

This is also important when you're working with files that are regularly exported to other formats where whitespace or empty lines makes a difference in the exported result. Does that make sense?

Yeah, it was just more work to keep all that info per-note, then to make it configurable and then be consistent across all notes.

I'd also like to add that tag spacing (the number of spaces between the headline on the left and the tags on the right) is changed by orgzly, too and I would very much prefer the way I formatted them in Emacs, also because I use git to manage my org files.

This is the prime reason (together with #591) why I use orgzly only for viewing at the moment and prefer to make modifications in Emacs (via termux, if I have to).

I would like this too. My use scenario is similar to the OP one: I have the org files under version control, and I want to keep the diffs small and simple. Moreover, sometimes I want to look org file with a simple editor, with just syntax highlighting, and manual placed spaces between headers are helpful.

About the two solution pointed out by @nevenz , I actually found both viable:

• I have no problem with seeing the whitespaces in the contents. Maybe, could this just be enabled with a setting that make explicit that the format of the content could be awkward?
• I do not think that adding an hidden integer to the note is an overkill. Optionally, it may be more general too: store for each note a number of character to hide at begin of the content. The whole content will be used during the generation, while only the not-hidden one will be presented in the GUI. The setting about the empty lines between header will stay, affecting the new notes only.

I think the doubts about the latter are actually a false problem. When Orgzly HAVE to modify an item, it can use the format it prefer. What it should NOT do is to modify the formatting of an item that it is not touching at all. So, if the user have a list attached to the title, and it is modifying something else, that list should be kept attached. If it is adding something between the header and the list, Orgzly can use any format it think is better.

NOTE: Generally I think that also for the tags should be done something similar. But this turns out to not be an issue FOR ME because I already store my tags in the same way as Orgzly :)

Hi, I'm the next person to seek out this problem.

@nevenz said: I guess an option not to strip whitespace from the content could be added. So if you use it, you know what to expect - empty lines at the beginning of content. And you'd have to remember they matter and why.

That'd be perfect! For these users that are concerned with the permanence of re-formatted files, a visual quirk does not feel like a price to pay at all.