Re: I'm looking for a project management system for Emacs

[Marcin Borkowski <mbork@wmi.amu.edu.pl>]

Dnia 2014-03-30, o godz. 16:30:42
despen@verizon.net (Dan.Espen) napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> > Dnia 2014-03-30, o godz. 10:18:40
> > despen@verizon.net (Dan.Espen) napisał(a):
> >
> >> >> Nope, big Gnumake fan here.
> >> >> Any directory/project I do work in is going to have Makefile(s).
> >> >
> >> > Well, then I deduce that you are not a heavy LaTeX user.  (Am I
> >> > right, dear Watson? ;) )  The problem is that the make model
> >> > (using timestamps) is a bit too simplistic for LaTeX: due to the
> >> > way references (& friends) work, the .aux file basically depends
> >> > on itself, but only if it contains a line saying
> >> 
> >> Right.  Latex is for printing isn't it?
> >
> > Rather typesetting, usually to a pdf file (at least nowadays).  Of
> > course, most of the time this means that something will eventually
> > find its way to a dead tree.  (OTOH, there /are/ TeX-based engines
> > which can output HTML/XML, too.)
> >
> >> I do a lot of documentation writing.
> >> But HTML/CSS (and Makefiles) are my weapon of choice.
> >
> > This is a very good choice, /if/ you do not aim for high
> > typographical quality and/or atypical applications (typesetting of
> > chemical formulae, musical notation, dictionaries etc.).
> 
> Yep, I can care less about paper, but the display quality is to
> some extent a function of the browser.

True.  And (as I hinted) not only display quality, but also display
/possibilities/.  Are there any browsers capable of displaying musical
scores or chemical formulae, to use abovementioned examples?  Or, for
that matter, rendering trees (like in a school-level probability
textbook), given their structure?  It's possible, but unlikely, since
these are rather niche use cases.  (You could probably do it with
JavaScript and SVG or something similar, of course.)

> > Out of curiosity: are there /any/ HTML/CSS rendering solutions
> > (browsers, ebook readers etc.) which handle breaking paragraphs into
> > lines in an aesthetically satisfactory way (i.e., employ the
> > Knuth-Plass algorithm, for instance)?
> 
> Well, browsers do re-flow when you change window size.
> 
> Hmm, Google says there are some Javascript
> implementations of Knuth-Plass.

Interesting - I'll look at it in some spare time.

> >> I have rules for content generation (like a TOC), uploading,
> >> thumbnail creation, packaging...
> >
> > Do you aim for online browsing only, or for a printed version,
> > too?  If the latter, how do you handle the problem of (potentially)
> > unstable forward page references?
> 
> When you identify your CSS there is a "media" option.
> I do most of my work for browsing, but for the few people that
> print, I do have a "print" CSS.
> 
> As for forward references, I just do "See X below".  If you print,
> you've got to search.  If you are browsing, "See below" is a link.

I see.  That means - basically - that you escape the problem;).  A
user of a printed version has no idea whether they should skip forward
two pages or two hundred pages...

> I've adopted a convention so that headings point back to the next
> higher level heading.  So, H2 points to the enclosing H1,
> H3 points to it's parent H2, and so on.
> 
> It makes navigating, even big documents a breeze.

Smart idea!  Though I prefer Emacs Info's `u' key for that;).

> Each TOC only goes one level deep.
> So the main TOC references the H1 headings.
> If there are a few H2 headings, there is a nested TOC.

Of course, this does make a lot of sense in an online document and not
too much in a printed book...

> At the same time, I use DIVs to indent heading levels a little more.
> This makes up for not having numbered sections.

Again - numbered sections in an online environment are a good idea.
Much worse in printed material.

> I especially like the "Change History" section offering links to
> the changes.  Someone that's just looking for new stuff gets there
> pretty quickly.

Of course.

> A really neat HTML feature is a Javascript package I found that
> makes <table>s sortable.  It's so neat to put a table into
> a document and know the user can sort it on any of the columns.

Nice!

> I've been advocating for dumping Word and PDFs but people are
> slow to change, so I lead by example.

Dumping Word is indeed a good idea;).  For PDFs - I can't agree.
HTML/CSS addresses a different problem than PDF.  Using PDFs for
browsing on a computer may be suboptimal (depending on circumstances).
For actual printing, it is much better, since it gives the author (or
the designer) complete control over the document.  With HTML/CSS, a
lot is dependent on the browser, user's settings, available fonts etc.
This is (usually) what you /do/ want on a web page and exactly what
you /don't/ want in a book (even if it were actually possible;)).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University