Re: [dev] Suckless word processing solution?

Uriel wrote:
> 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
>
I know it's against your principles, but couldn't you just send your
mail through a filter? You might have that less aggravation in your
life. I have never even noticed an html email as my client turns them
into plain text for me. I'm a lot happier for it.
> 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 - 18:13:55 UTC