I find it a bit amusing that the programmers write the following
about the last version upgrade:
""This version has a tonne of new features""
Creating a simple, get out of your way wordprocessor that cant do
a few things very well seems at odds with feature bloat when you cram
more and more features into each release.
I dunno, to me being bloat free isn't the same as having few features - it's more about how tight those features are, how thinly they are implemented, and how much it avoids creeping into additional things once it has reached high feature density in the initial narrow focus. E.g. I wouldn't consider curl bloated. It supports damn near every transfer protocol a lunch table of engineers could think to name, has a boatload of options and knobs to do what you want with all of those, and is hundreds of thousands of lines of code... but at the same time is ultimately a couple of MB, sticks to the narrow job of "transferring data with URLs", and keeps a simple interface without feeling the need expand to be the place to go for every related task too like e.g. a bloated browser would.
And this is the problem with calling software bloated. Everyone has a different idea of what features are useful and what features just increase the size and complexity of the software without adding value.
After having tried several approaches to minimalist text authoring, such as FocusWriter and pure text editors, WordGrinder is now my preferred tool for the job. Running in an xterm it's fast, distraction free and easy to use.
I'm trying to think of the use case where Markdown in VIM is not enough, but LibreOffice is too much. For what it's worth Bash is my file manager and I practically live in the CLI. I do write some technical documentation to go with my code, in Markdown. I recently wrote a long report in LibreOffice for a medical malpractice suite - I made extensive use of headings, paragraphs, quotes, tables, and bold text. My work templates have page headers and footers with page numbering, sparse embedded graphics, tables, a table of contents, and sometimes code snippets with syntax highlighting.
Additionally, all my document types use RTL text, which WordGrinder does not support. So I am more interested in the general feasibility of such an app, than in actually trying to replace LibreOffice with WordGrinder (at least until RTL support is added).
I find myself more and more into the CLI and recently got introduced to Neovim. Decided to start learning Neovim by simply writing markdown documentation and I'd say it's even intuitive.
That works pretty good with markdown files hosted on github pages as I don't have to move out of the CLI when pushing them online.
However, the use case that this workflow doesn't cover is when I write something that I'd like to send for a proofread to a friend of mine, who's an editor. He really loves his Word files.
As I'm a noob, I asked then ChatGPT to help me with a bash script that converts that .md file into a .doc file using pandoc. That worked pretty well.
My thought was if it couldn't be possible to use something like pandoc for converting an .md file into a templated doc with headers, footers, page numbering, even toc?
That wouldn't solve 100% of the use cases, but still could be pretty good.
LibreOffice can handle a lot (I don't know if it can do the more fancy font features LaTeX can yet) so the case here would be to stay on the command line.
And Markdown, well, its great in that it is simple, but I tend to hit its limitations very quickly for more complex setups - plain markdown won't do anything but the most simple tables, and of course, there is no way to define styles.
I would suggest that your use case is probably better suited for something like LaTeX (or Tex, for more direct control), og ngroff/troff if you want speed. Maybe Typist for a more modern take?
I did all my college papers with a CP/M roff program that I ported to MSDOS Turbo C from a port that someone else did to some other MSDOS compiler. That plus a text editor (Emacs subset) was all I needed. It is still around, 23KB of C code:
I do not understand and never have the general meme:
>"This great new word processor is lightweight and
that is awesome, you get a blank screen and only that "
Would seem like:
"I have written an amazing lightweight fast new code editor
that wont slow you down.
You get a blank screen and is that, no confusing keyboard shortcuts,
no syntax sugar, no weird coloring of your code, no in program terminal
etc
"
Or rather I have recreated Microsoft Windows Notepad, with even fewer features.
No, I do want my code editor to have quite a lot of features that I can
use -if- I need them.
I do a lot of writing so this goes for my word processor as well.
It is trivial to configure Microsoft Word to show you nothing but a blank
screen and you can start typing. If that is your thing.
If you need more its available.
(No it can't do everything LaTex can,
Yes you may be able to type faster in vi)
Different tools for different tastes. Some programmers prefer Emacs, some vim, some Visual Studio Code. Some authors still use mechanical typewriters, others prefer Word. Others like word processors but feel bogged down by Word's many features for layout, graphics, collaboration and Office integration.
I would say that both Emacs and Visual Code have a million features.
And of course, both have a vast set of plugins that add even more
features.
I am not as familiar with Vim, but from people I know using it, it appears
to have a decent set of features, I see it has at least 20.000 plugins
which is quite a lot
A valid comparison for wanting a code editor that gets out of your way,
Wuold in my opinion cd something close to Windows notepad or even a
typewriter for that super retro feel.
Far into the past, I handwrote code, with pen and paper for my exams in computer science. I have no wish to do so again.
In particular it's worth people knowing that Word has an "immersive reader" mode for reading and a "focus mode" for writing if blank screen plus cursor is your jam. Method of turning it on varies by word version. If you're on a mac it's view -> focus mode or some four-finger keyboard salute. If you're on windows it's on your ribbon on the view tab and you have the extra option of "line focus" (ie you only see the line you're on) or various sizes of window around the line you're on (under "Learning focus" I think).
This is useful even if you have other preferred tools because you may well find yourself in a work situation where some word usage is forced on you (eg having to review contract redlines or vendor sow drafts or whatever).
That said, I'm all for people having other options, so salute this project.
You would not want Word to do that all the time. And it still would not function the same way WordGrinder does.
I like the way I can start typing words at the center of the black screen and it auto-scrolls, then if it's worth anything that I might want to format, I can throw it into OpenOffice or whatever
Wordgrinder is kinda nice, it's one of the few console editors that can do word-wrapping well (similar to a textbox in a GUI). What I want is to see each paragraph wrapped on the screen, but saved with only a newline for each paragraph, not for each line. A GUI textbox does exactly this but on the console most editors save line breaks when they word-wrap.
I like it but I wish it was easier to work with plain text files. You always have to use the export function instead of just saving.
wordstar sort of did this but saved the soft line breaks and hyphens with the high bit set. that way, the distinction between paragraph breaks and formatting wraps was preserved, but it didn't have to redo all that text wrapping work when you opened the file—important on a 4-megahertz z80, which is what i was running it on
testing with http://canonical.org/~kragen/sw/dev3/propfont.c i need about 110 instructions per byte to naïvely word-wrap text and render it to a pixel buffer in a proportional font. this suggests that the z80 could probably have wrapped about 5000 characters per second (in a proportional font), while a 48-megahertz cortex-m0 running 40 million instructions per second could wrap about 400 kilobytes per second, so while there's a strong human-factors reason to cache this kind of presentation information between screen frames, it doesn't really need to be cached between file opens
(the problem gets easier if you don't have to render the text to pixels, or in a fixed-pitch font, both of which applied in wordstar's case)
Add catdoc, docx2txt, odt2txt, wv, and so on. These tools will convert propietary word processor formats
to plain text. Or, in the case of wv, to several more open formats.
It's useful to get the content and edit them later under Wordgrinder or any text editor.
WordGrinder: Terminal-based distraction free word processor - https://news.ycombinator.com/item?id=35530372 - April 2023 (68 comments)
(Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)