help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dan.Espen
Subject: Re: I'm looking for a project management system for Emacs
Date: Sun, 30 Mar 2014 16:30:42 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Marcin Borkowski <address@hidden> writes:

> Dnia 2014-03-30, o godz. 10:18:40
> address@hidden (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.

> 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.

>> 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'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.

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.

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

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

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.

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

-- 
Dan Espen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]