Is there a code similar to <$W> that will insert the current document “Title”(or even enclosing folder title) into the text on export?
I wish to have my chapter titles have output like:
Chapter: ONE
Title
location, time
I put this all in the text of the folder currently, and use a <$W> to get the chapter name. I can partially get the effect I want by renaming the folders themselves to be like “Chapter $: Title” and then exporting titles. But this is really ugly as they show up in the binder with the extra formatting information (i.e. the Chapter <$W>:) and it is not possible to put the components on different lines. A simple <$xx> meta code that inserted the title would solve the problem. I hate to type my titles redundantly into each of the folder text as then if i change one i would have to change it in 2 places.
Any suggestions? I don’t mind technical (I’m a programmer as well as an author). I assume this is probably doable with MMD, which I have resisted delving into as the scars developed writing countless papers as a grad student 20 years ago with LaTex have still not healed. I shudder at the memory of badness 10,000.
There’s not really a good way around this at the moment, but 2.0 will feature the ability to define title prefixes and suffixes at the Compile stage. So you can prefix folder titles with “Chapter <$n>…” or whatever, so that putting the title text in the folder text isn’t necessary any longer.
All the best,
Keith
One flexible way to do this (in 2.0) would be to have a checkbox for folders like “treat body as title for export” that does just that, treats the entire body text of the folder as the title for export. Then add a <$title> or similar markup object that converts to the actual title. That way you could put prefixes, suffixes whatever in the body, and just use the tag to indicate the location of the title. Creating a whole collection of tags that expanded to meta data could be very useful and would probably be pretty easy to implement. <$synopsis> , <$author> <$documenttitle> etc etc. These could ideally be used in the header/footers too, so it would be easy to stick the chapter title, book title etc. in the headers.
This kind of expansion, not so different than what is done in many markup languages or processors of such (like FBML for example) can be really simple to do, but very powerful.
Oh and one more question. Can MMD get access to meta data like the document title etc so I would be able to do it there? I.e. is it worth it for me to learn it?
As I say, prefixes and suffixes are coming, but there are no plans for your other suggestions for 2.0, which is pretty much locked down right now. Having variables to <$synopsis> and <$title> etc could be problematic - imagine the user puts the <$title> tag in the synopsis field and the <$synopsis> tag in the title, for instance. Anyway, as I say, you’ll be able to do exactly what you wanted in your original post using the new Compile options.
I can understand locking down features. One of our favorite quotes at Beta time as we shipped our big games (100+ person projects) was “this is the time when one great idea can kill the whole thing.”
That being said, recursive problems like the title/synopsis one have several really easy solutions. The simplest is to just keep a stack depth variable and stop expanding after a small finite depth. Formal cycle detection is pretty easy too, but the former is like 3 lines of code.
“Stack depth variable”…“Formal cycle detection…” Help! I’m self-taught! Seriously, though, I had to go through the “to do” list recently and move lots of stuff down into 2.1 and 2.2 folders, as I realised I was never going to ship 2.0 if I didn’t - and 2.0 still has months of work left in it… I want a 100-man team! I’ll certainly be willing to revisit the extra variables thing for 2.1, though, when my head can cope with new ideas again.
By stack depth I mean this: Just have a variable to your expansion loop function that is the depth, start it at 0, increment it in the function (and pass it down recursively). If the depth is greater than the threshold (say 2-5) then don’t expand. That way expansion won’t get into an infinite loop.
Formal cycle detection would be to actually detect if you had a loop in the DAG (directed acyclic graph) so you could kill the expansion only in the case of an actual loop. This is overkill.
I too was once a self taught programmer (80-92). But then I went to get my PHD at MIT and got to read such thrillers as:
But you should certainly throw in a simple <$title> (whatever you want to name it) variable that expands to the title. That would be very simple to implement, but allow a lot of flexibility to lay stuff out in the folder body.
I just went through and did it manually, but I had to type in all my titles so they are duplicated in the title and text.
Actually, I had already added a <$title> variable you can place in documents - I"ve just added <$status> and <$label>, too, as I think these could be useful. More will have to wait, though, although I am pondering on a variable-based compile system - the only trouble with that, though, is that it may appear too geeky to the average user.
All the best,
Keith
One way (that you already know) to make this kind of programmer thing easier for the novice is by putting them in the insert menu. I would imagine the novices just wouldn’t use them however, so it wouldn’t be much of a problem.
If it were me – and I’m a highly systems oriented programmer – I would have the document be some form of object (I’m sure it us) and have a generic route by which string dispatch can collect “authorized” fields out of it in the expansion process. That way new <$xxx> commands would get added automatically for all fields (you might want to tag those that did and didn’t allow it).
Conceptually you could think of that as <$xxx> = insert here the conceptual result of document->xxx
In a fully OO language like ruby (which I love), where all field accesses are methods, and can be dispatched by string, this could be complete automated.
Click on the “NEWTOPIC” button at the top of whichever forum you are in (e.g. the list of posts in the Technical Support forum). (To answer your question: not yet, but coming in 2.0.)
Best,
Keith
Hi. I’m still struggling to find the NEW-TOPIC button you refer to. Is it always at the top of the screen?Sometimes I can find it and sometimes I can’t.
The rule of thumb is: you need to be on a page that has a list of topics (threads), to make a new one. If you are in a search result (like new posts), or in a top-level section, or within a thread itself, you cannot make a new topic within these areas of the site. So think contextually, if you want to add a topic to a section, you need to be viewing that section (like Technical Support), first.
Seriously, though, I had to go through the “to do” list recently and move lots of stuff down into 2.1 and 2.2 folders, as I realised I was never going to ship 2.0 if I didn’t - and 2.0