From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.help Subject: Re: I'm looking for a project management system for Emacs Date: Sun, 30 Mar 2014 23:02:51 +0200 Organization: WMI UAM Message-ID: <20140330230251.1de66926@aga-netbook> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1396213413 30468 80.91.229.3 (30 Mar 2014 21:03:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2014 21:03:33 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Mar 30 23:03:28 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WUMt5-0000ia-1K for geh-help-gnu-emacs@m.gmane.org; Sun, 30 Mar 2014 23:03:27 +0200 Original-Received: from localhost ([::1]:45827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUMt4-0007cO-IV for geh-help-gnu-emacs@m.gmane.org; Sun, 30 Mar 2014 17:03:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUMsf-0007RA-AH for help-gnu-emacs@gnu.org; Sun, 30 Mar 2014 17:03:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WUMsZ-0005Om-Jh for help-gnu-emacs@gnu.org; Sun, 30 Mar 2014 17:03:01 -0400 Original-Received: from msg.wmi.amu.edu.pl ([2001:808:114:2::50]:41996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUMsZ-0005OS-8q for help-gnu-emacs@gnu.org; Sun, 30 Mar 2014 17:02:55 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by msg.wmi.amu.edu.pl (Postfix) with ESMTP id 8EE5441D6A for ; Sun, 30 Mar 2014 23:02:53 +0200 (CEST) Original-Received: from msg.wmi.amu.edu.pl ([127.0.0.1]) by localhost (msg.wmi.amu.edu.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEFNaC4tRo8u for ; Sun, 30 Mar 2014 23:02:53 +0200 (CEST) Original-Received: from aga-netbook (99-234.echostar.pl [213.156.99.234]) by msg.wmi.amu.edu.pl (Postfix) with ESMTPSA id 5289A42072 for ; Sun, 30 Mar 2014 23:02:53 +0200 (CEST) In-Reply-To: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.20; i686-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:808:114:2::50 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:96872 Archived-At: Dnia 2014-03-30, o godz. 16:30:42 despen@verizon.net (Dan.Espen) napisa=C5=82(a): > Marcin Borkowski writes: >=20 > > Dnia 2014-03-30, o godz. 10:18:40 > > despen@verizon.net (Dan.Espen) napisa=C5=82(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 > >>=20 > >> 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.). >=20 > 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)? >=20 > Well, browsers do re-flow when you change window size. >=20 > 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? >=20 > 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. >=20 > 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. >=20 > 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 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, --=20 Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University