Honestly, as an outsider, making that statement is somehow indicative that there’s a bigger problem beneath. Just throwing the most proven versioning system out of the window because it could break things as they are should rather make us look at how the things should be made to be, so that it wouldn’t break things.
Just my 2c - check out what Omni is doing: https://realm.io/news/altconf-wil-shipley-git-document-format/
You’re right wrt. supporting richly encoded documents (hence, rtf). I think that still, using Git API would get you the best of all worlds, as you could present the user with just changes, and merge trees like Git does anyway. Honestly, creating full copies of all files every time you create a snapshot, rather than just saving the changes, is kind of ?really? I think for editing, RTF is fine, but not for saving. When saving, basically, I’d opt for separating the content you format, and the format. So basically I’m advocating some Markdown where you can just as easily use plain text all the time - and then Scrivener would focus on what it is better than anything else I’ve seen, which is organizing ideas.
Are there really that many users out there that want to “mark a text in red” and print it that way? Or put a picture in, i.e., use Scrivener as something like Word? If now Scrivener would have a simple way of copying things, that would be great - Duplicate kind of sucks, and also, I’d like to have references (like, symlinks).
Keith has hinted at the next version of Scrivener (v3) having some method of merging projects that were forked (I guess with “Save As” or a new function?) to accommodate collaboration.
I don’t think GIT is the right solution for Scrivener project collaboration, and I doubt that will change. Scrivener not a programming IDE, in spite of its superficial similarities to one, and no matter how much you might want to force its projects to work like a source code tree, it’s not going to behave that way.
Why not?
What is the difference between writing code, writing LaTeX, and writing a novel?
Scrivener can very much be an IDE, and then the real question is simply, why on earth would we not provide, for the so-inclined, a simple option of having two things:
a) A preferences setting that will completely default to plain text mode - and also store files that way
b) A preference setting that will use file system directory tree structure rather than having all in one place
This alone can make it work completely with Git. It would be an option, and one that’s honestly easy to implement - actually I’m doing exactly that, only that, since I’ve no influence on what Scrivener does with its default to RTF, by design choice just go ahead and revert back to plain text - see http://github.com/mnott/texdown on the parsing, and http://www.mnott.de/unscrivening/ on some of my little attempts to run in an RTF scenario.
It’s entirely possible, and actually simple to implement, if you can live without rtf. And if you gave users a choice, it would let the decision whether or not to use Git in the hands of the users.
I think you answered your own question. RTF exists because most writers of novels do NOT want to have to deal with markup. Markup-based editors used to be the standard. They aren’t any more because users generally prefer a visual approach to formatting.
We get far more requests for additional visual formatting features than we do requests for improved Markdown or LaTeX support.
Katherine
See my second response in this thread.
Well, “we” aren’t programming Scrivener: Keith is. He doesn’t want to go to the considerable effort of doing that, and I wager it’s a LOT more complicated and very problematic from a support perspective than you’re making it out to be. Also, if it were so simple to use plain text, then why isn’t there a competing product out there that only uses plain text?
I get wanting to argue a point in hopes of making a good tool even better, but these arguments have been hashed out many times, and the bottom line seems to be that you won’t get plain text, and you won’t get unique names/paths for each entry in the binder (which would make GIT a viable way to merge concurrent collaborative project forks). Maybe something’s coming in V3 that will solve one of these problems, but I wouldn’t count on it.
Katherine,
thanks a lot. That’s why I was asking. I only see my little world here, and of course I don’t have sufficient data points that I could say, whatever it is that I’m wanting is really relevant. I’m working enough in startup business to know how wrong you can go with that. That’s why I was asking.
I can imagine that many people want to essentially do more visual stuff. I’m of course biased the other direction. That doesn’t mean that what I do counts in any way.
What I like with Scrivener is that you keep the file structure open, i.e., readable and comprehensible XML, and same for the file organization. This is really good, as it allows for people like me to somehow hack into it and make it work for them. This is good, and I hope it’ll stay that way.
I’ve the related discussion in this same thread on Git etc. Like honestly, there’s no point why not to, optionally, support plain text as default - either on a general level, like program wide preference, or even only on a per branch level in the binder. It logically is easy to implement. Actually fundamentally easy - just allow for a preference setting, and when done so, just use txt. Everything is already in scrivener to do that, and scrivener does do just that for its Synopsis.
Likewise, it is an easy option to allow for file based directory hierarchy. Let’s face it, everything in there is manageable, even conflicting file names, by just adding the unique ID to the whole file name. Even if you think about that text files can have children, you can see everything as a file, and everything as a folder, and you can make it work on file system level by adding, should you have a folder that has content and children, a default file, which is the metadata on folder level.
All of that is completely simple to implement, and not doing it is of course a logical choice when most people want a table editor, or adding all sorts of visual stuff.
As long as you keep your document structure open, it’s fine.
So there, I’ve a simple suggestion which might help everyone. Why do you not allow users to register a callback that every time gets called when you do a file operation? This essentially amounts to extension points, where I could register an event handler (e.g., a script being called or something), whenever a file save or open is called - and conversely, a function I can call whenever I want scrivener to update some of its cache if I changed something on the files.
With that, you could completely forget about people asking you many times about like git support, collaboration support, and so on. You could just establish those extension points, which you provide for, and whatever the heck people want to do on those events is entirely up to then. Plus, you allow a whole ecosystem to grow around your program, where people create extensions.
I’ve done similar things several times in my company - we just cannot do everything all people want, already because quite often it is even conflicting. But we can let others do stuff. The extension points approach was very successful over here, and has helped us gain a lot more user base in the areas I worked on it, while at the same time actually reducing the amount of support work because of people just hacking stuff, etc., and then complaining when we changed our anyways not public interfaces.
Just a suggestion - also it is a way of sharing economy, in a way. It engages your users, like me, to actually do productive stuff.
Having said that, I’m just going to do the hacking approach for the file system export myself, and likewise for the text files. As I said, it is possible, so I’m going to do it anyway, and share it - because of your open document format, that’s a very good thing to do.
So, as you can see, I’ve not used Scrivener for years after buying it, but the moment I need it, I am investing lots of time into it to make it work for what I do. People in my area now, like academic research, are totally impressed by what is possible with Scrivener - plus a little bit of very simple scripting that I hack together in like one night, to remove some barriers. It changes the way people I work with organize their idea management - it changes the way they actually organize their work.
There, Scrivener can have a great impact, and even if it is just a small user base, these people are desperately needing something that Scrivener can definitely deliver on - making snippets of ideas manageable.
Thanks again,
M
Except you just created two different, incompatible, project formats. What happens when an RTF-based project is opened on a plain text system (or vice versa)? What about the non-text files that a Scrivener project can also contain?
And keep in mind that the Scrivener text engine is built on top of the mac OS text tools, which use RTF as their native format. Do we now need two parallel versions of the main editor?
Katherine
Clearly not requests from people who have pitched the same project to different publishers each with their own mandated and contradictory formats for submissions.
Genuine question, what is it that’s missing from the Compilation dialogue that means you can’t add the differing formatting there (or in your word processor afterwards)?
Publisher wanting Heads and Headings, Titles and Subtitles in specific fonts at weights and italic angles; there is no style system in Scrivener at the moment. While some the requirements can be inferred from RTF in the general case they cannot. Carrying over elements into the text which can then be Compiled into whatever various publishers demand becomes trivial.
I’ve got this sorted using a macro in NWP which makes it a matter of opening a standard compile output, then 2 clicks of a mouse or a keyboard shortcut and a click of a mouse. I’m sure you could do the same with Word or Libre/Open/NeoOffice … it might be more cumbersome in Mellel and as far as I’m concerned, Pages is a non-starter.
Mark
Given that I’ve ditched all use of word processors from my workflow this method, while feasible, would add an utterly unwanted step into to. I’d rather the simpler scheme of being able to style sheets in Scrivener. But I guess I’m too old to ask Santa for that in Scrivener version 3 or probably even version 30.
I believe Keith has said that Scrivener 3 will include an upgraded style system. Until then, the best workaround appears to be using the “Find by Formatting” command in the word processor of your choice.
If you want specific title and subtitle formatting – as opposed to having text labeled as a title or subtitle – for different publishers, that’s why the Compile function works as it does, and can absolutely be achieved in Scrivener as it now exists.
Lots of people request true styles in Scrivener. Not many request improved LaTeX or Markdown support as a route to achieving them.
Katherine
When you say specific font weights / italic angles, do you mean a specific combination which is downloadable and then available in the Font Book. Eg. ‘Avenir Book Demi Bold Italic’? Or do you mean that you’re using Latex (or some other tool) to impose a different slant on the italic from the inbuilt angle?
The reason I’m asking is that it’s not strictly true to say that Scrivener doesn’t have a style system: it does. Or rather it has a measure of semantic formatting attached to document titles: each level of folder, document group and binder can have its title and text formatted individually (each with a different font if needed), so that it’s possible to have differently formatted Titles, subtitles, heading, subheadings, sections, subsections and so on. This is all done at Compilation time, so you can have different settings to suit different publisher’s requirements.
Apologies if you already know this – I wasn’t sure from your description.
Of course, there will be documents which are so complicated in structure that it is difficult (perhaps impossible to achieve), but I thought that some people reading the thread might come away with the impression that it’s not possible to override headings and so on for different publishers, and of course, in general that’s not true.
I’m into those “complicated” documents so the simplistic stuff of Binder’s Folders isn’t good enough. For example, I’d want to mark up inline quotes, block quotes, scientific name, foreign phrase, emphasised phrase (those last three or semantically different and need to be visualised differently), publication title, publication year, publisher, etc etc etc etc. And for fiction I want to be able to markup dialogue and then have either the British or American conventions for speech marks appear or the Spanish, French, German. or Swahili specific versions show up. So yes a full on generalised markup of text that is independent of some particular realisation on a specific presentation device—be that screen, e-book, paper, or whatever. And no I do not want to have to continue with the procedural markup of Markdown or the quasi-generaic-but-still-procedural markup of LaTeX; I want to generically mark the text up once and then have Compile generate the appropriate final forms.
Okay. But if neither Latex nor Markdown meets your requirements, does a tool exist which does?
It has to be outside of Scrivener sadly but yes, OASIS’ DocBook in either SGML+DSSSL or XML+XSLT forms.
I had an enjoyable half hour reading about DocBook – thanks! I remembered it vaguely from a few years ago.
You’re right that it’s obviously too niche for Scrivener to be rewritten to accommodate it as a XML editor, particularly when you can get most of the features you want through the current version, except for the inline formatting (you can get the specific language conversion of quotation marks through the replacement pane).
If you need / want the organisational capabilities of Scrivener, then I suppose the only route is the cycle of planning in Scrivener, syncing an external folder for writing and editing (Emacs in a suitable xml mode?), before compilation to plain text for processing.
Thanks for the insight.
I don’t know who the question was directed to, but let me share my view.
First of all, the compilation dialogue, is, well, a dialogue. When I am producing the compilation of my content, I want a way to predefine multiple selections (choices of assets) that I can then, when I’ve no time to lose (because, deadline), just run directly into LaTeX.
Secondly, I need, as I just said, not one selection, but a set of (sets of assets).
Third, my selection of assets is typically taking stuff from different tree branches. In other words, the “header”/“footer” parts of the compilation dialogue is very much insufficient if you want to reuse assets. I have my LaTeX/Article branch, for example, which I just include in my compile prescript, and then every publication that I am doing is going to pull in from there as front- or back matter, and in the middle put whatever is really relevant for content. Yes you can do that with the compilation option, probably also going presets, but then finally…
Finally, did you see how /slow/ the compilation really is? I mean, honestly, with a very small set of assets, it already takes several seconds to run. The little script I’m working on does this in a fraction of a second, while at the same time parsing what I need to parse.
I am talking near real time compilation from Scrivener to PDF through pdflatex. There’s no way that for every single export I’ll wait like 20 seconds for the export to happen and also even before click my way through the nth time through the same dialogs.
Oh yes, and then particularly on LaTeX, already if you just use Scrivener the way it is, it will alert you that the export file is already there (if it is). And if it is, and you say, overwrite (or you don’t, that does’t matter), Scrivener will crash and take your last work with it. That doesn’t appear to happen on other export formats, but is is very annoying having to remember moving away the previous export file every single time.
So in general, here’s my verdict on Scrivener:
But then again, Scrivener is not headed as an integrated development environment (IDE) - though it clearly should be. It could be the Eclipse of authors. It is clearly able to do it if just some things were put on new feet.
And don’t forget, it does it’s job probably excellently for the vast majority of (novel) writers.
And finally, Scrivener has basically open sourced their document file format, by keeping it plain text. This we should not underestimate, as it really allows people like myself to make it work the way they want.
If that wasn’t there, I’d not use it. When I picked up on it, searching for a good option to compile my stuff for my PhD research, I came across it, not having used it since I bought it, for many years. And again it immediately looked like, no way, that’s just too restrictive. But there’s really no better option out there on the conceptual phase, so managing your thoughts. DevonThink, which I know quite well, really is very bad at that, and their idea of a database of your assets sucks even more. And I’ve had hundreds of thousands of files in DevonThink, but finally decided it is not up to the task.
Compared to Scrivener, which has an open file format, and hence lets you work the way you want (if you accept scripting a bit, should you need it), is the right choice.
What I’ve also noticed on the forum here (being a newbie) is that there is an apparent resistance of some people to alternative ideas. Statements like “X is never going to happen.” That’s a bit worrisome, since it essentially shuts down a discussion in the first place.
I don’t care, I will keep sharing what I do, and I’m going to use Scrivener for the next half decade or so that my PhD takes, contributing some significant time to the automation part
But, those are just my 2c,
M