Re: [dev] Suckless word processing solution?

Can we setup a filter for dev_AT_suckless.org that sends any html email
to /dev/null, and autoreplies with "Fuck off moron." to the author of
any such email?

Thanks

uriel

On Tue, Sep 22, 2009 at 5:06 PM, Anselm R Garbe <anselm_AT_garbe.us> wrote:
> Hi Илья,
>
> 2009/9/22 Илья Илембитов <ilembitov_AT_yandex.ru>:
>> I am looking for a lightweight solution to create rich formatted content in
>> any MS Word-editable format - I think RTF is more likely to happen, since it
>> is an open format.
>
> I'm looking for such thing as well. On IRC in the #suckless channel
> someone posted a link to Word 5.5 just now, I think that might be an
> option for the interim. I think Word 5.5 is the most usable MS Word
> release ever created, it definately sucks less than any FOSS
> alternative. But I'm uneasy on relying it in the long term.
>
>> Basically, what I am looking for is a lightweight, distractionless
>> (preferably no menus or toolbars) word processor with support for all common
>> formatting option. Basically, I don't need the word processor to be capable
>> of doing things I wouldn't be able to do with a real piece of paper - which
>> means that I just need common beautifiers, font styling, paragraph styling
>> and footnotes/TOC support, tables and images, since I often need to write
>> academic papers following a certain style. However, I don't need any math
>> support.
>
> Your requirements sound acceptable.
>
>> I was looking for something that would suit my needs for quite some time.
>> AbiWord is bloated, slow and buggy and has numerous GNOME and other
>> dependencies. Ted got updated recently, which means that it finally got
>> UTF-8, gtk interface and proper font rendering, but at the moment is still
>> buggy and it is uncertain, in which way will it improve. Other than that, it
>> is a really nice word processor. WordGrinder has a nice interface concept,
>> but CLI interface can show many style features of the text, which is why WG
>> supports only a limited number of formatting capabilities. Besides, it can
>> only export to troff and html. Finally, it wasn't updated since late 2008.
>
> Well all these alternatives aren't any.
>
>> Then I looked in the area of humane markup languages. txt2tags is nice (the
>> syntax is really clean and easy), but doesn't support RTF and footnotes (not
>> to mention the proper paragraph formatting). I tried MarkDown extensions,
>> such as pandoc (which involves having a Haskell infrastructure installed)
>> and multimarkdown. Both support RTF export, but still look more like an
>> easier way to get HTML output than a word processing solution. The same is
>> true with the other lightweight markup languages: they are either tools to
>> get HTML source, or an easier way to produce man pages.
>
> RTF sucks.
>
>> Finally, i started looking at the full-blown typesetting systems. I admire
>> LaTeX, but it's just too big for my needs. Besides, latex2rtf utility wasn't
>> updated for quite some time and still doesn't work properly. Then I tried
>> lout. Lout is nice, because it's small and has a pretty straightforward
>> manual, but it only supports PS and PDF(?) output. Besides, I had some
>> issues with producing texts in Russian (since it is my native language).
>> Then I tried Groff. Groff look uber-geeky and traditional to me, it is
>> smaller than LaTeX (bigger than lout, though), but there are still a lot of
>> problems here. First, there is a huge lack of documentation - basically,
>> there is only a Unix Text Processing textbook back from the late 80s (and
>> it's not clear as to whether one could use it as a guide to contemporary
>> troff). Second, groff devteam seems to be more focused on the needs of man
>> writers (which is understandable). Which is why many issues specific for
>> common word processing and desktop publishing are ignored or are being
>> solved really slowly. Specifically, I couldn't solve the localization
>> problem. Furthermore, troffcvt utility (a troff converter, supports RTF) is
>> also deprecated and is of inferior quality - basically, it just ignores many
>> formatting options. I also checked other implementations: Heirloom project
>> might be nice (at least, it is said to support UTF-8 and modern fonts), but
>> again it is unclear as to which documentation should I use. Besides, the
>> project wasn't updated since April 2008. There is also a new C
>> implementation called mdocml (designed by BSD people to replace groff), but
>> it only supports man macros (although it is pretty active and should run on
>> Linux too). Furthermore, there should be another flavour in MirOS BSD source
>> tree (which is said to be an original AT&T version), but it is actually
>> broken. Finally, I couldn't find any mention of Plan 9 version of troff
>> being used outside of Plan 9 itself (but I suppose it should definitely
>> support UTF-8).
>
> It might be an option to write a troff front-end, though for real
> stuff it requires lot's of PS so that I think this isn't a real option
> either (having PS as output is fine though). But there has to be some
> decent intermediate format.
>
>> Currently, I am really desperate. IMHO, there were always two main problems
>> for those, who wanted to build a lightweight Linux/BSD environment: there
>> were no lightweight graphical web browsers and no lightweight word
>> processors. The situation with web browsers gets improved by surf and uzbl
>> developers. But what about word processing? Do you have any suggestions on
>> the original problem?
>
> Well usbl or surf aren't really lightweight, they only appear to be.
> (The binaries for themselves are lightweight, but that doesn't tell
> you on which mountain of complexity they rely on). I think writing a
> decent less sucking word processor is much more achievable than
> writing a lightweight browser. So this sounds like a good idea.
>
>> P.S.: Sorry for this post being so enormous, but I wanted to sum up my
>> efforts for somebody who would like to solve the same problem.
>
> Thanks, next time in plain text please...
>
> Kind regards,
> Anselm
>
>
Received on Tue Sep 22 2009 - 15:10:51 UTC