315 karma · joined May 16, 2011
zstyle ':completion:::(vim|nvim)::files' ignored-patterns '*.(aux|dvi|log|thm|idx|pdf|rel|out|tuo|tui|tuc|tmp|mpo|mpb|mpd|1|keep|pgf|fls|gz|fdb_latexmk)'
(yes, tex generates so many temp files!) I couldn't figure out how to do something similar in fish
What?
https://en.wikipedia.org/wiki/Indian_chess
It will be interesting to compare how Alpha Zero learns with the Indian chess rules.
- Email notifications just work. I get a bell on my terminal when a new email comes and my desktop environment (i3m) shows a highlighted xterm and a highlighted workspace so that I know that I have a new message.
- Excellent multi-account support. I have 4 email accounts and I can seamlessly move messages between them.
- It had a single maintainer who disappeared, someone else took over who disappeared, and now there is a new maintainer.
- The keybindings are relatively simple (n for next and p for previous) but the arrow keys and mouse also work.
- You can view html emails using w3m or lynx or whatever.
It supports standard features such as choosing your own editor to compose emails (default is nano, which is a successor of pico, which was the editor used by pine), filtering a message to a program (for example, to git apply patch), filter a message before sending, multiple ways to display threading, and so on. It has working support for signing and encrypting messages, decent support of reply templates. It has really really good documentation available in a context sensitive manner.
I sometimes feel that alpine/pine doesn't get as much love as other TUI email clients.
Let me give a few examples of how I use ConTeXt (not necessary with ConTeXt Lua Documents)
1. Create a simple key-value driven interface for "complex" layouts https://adityam.github.io/context-blog/post/exam-coverpage/ This is still a "string-macro-framework", but ConTeXt has enough (and well named!) macros that it almost appears to be a "normal" template language. The code in ERB or other template languages would not be too different.
2. Generate Lab assignments for an undergraduate linear control systems course where the students learn how to interface MATLAB with real-time hardware. We create the lab in Matlab (`.m` file) and convert it to Matlab live script (which is Matlab's version of jupyter notebooks) which the students have to fill in. But, the live script notebooks are not convenient for browsing (say, for students who want to view the lab on their phone). Matlab offers a PDF as well as LaTeX export, which look ugly IMHO. So, we convert the `.m` to XML (Matlab does an XML export), and then use context to convert XML to PDF. The code is written using "stringy-macro-framework" but again the interface is nice enough that it would have looked similar in any other XSLT framework in any high-level language.
3. As an academic, I need to generate various versions of my CV (full publication record, pubs in the last `n` years for various values of `n`, etc.). I store my pubs in an XML file, use the XML parsing lib in ConTeXt to convert the data to Lua tables, and then use ConTeXt Lua Document syntax to generate different versions of my CV (depending on the command line flags to the `context` compiler. Once the data is converted to a Lua table, it is trivial to do things like group pubs by year, group pubs by research areas, etc.
1. No need to run `pdflatex; bibtex; pdflatex; pdflatex` multiple times. The wrapper script `context` takes care of that.
2. Easy to add graphic elements to the page and layout in a consistent and _fast_ manner.
3. Export to XML/XHTML/ePub.
4. Can compile XML.
5. Programatically generate documents using a Lua interface (this is different from LuaTeX; ConTeXt has a nice Lua interface called ConTeXt Lua Documents, so it seems that you are writing Lua code rather than a wrapper script).
6 Consistent of interface. See https://tex.stackexchange.com/questions/4987/why-should-i-be...
https://adityam.github.io/context-blog/post/markdown-with-gp...
With a graphical tool, one is limited to the automation which the developers are willing to build into the tool and sentenced to handling manually everything else, every time that there's a change, e.g., if you have a keyword block on your opening article pages aligned against the outside gutter and the layout program can't place it automatically and contextually, then every time the article changes from opening to a left to a right or vice-versa one has to make that change manually.
I wrote up a longer comparison once upon a time --- Scribus isn't that much different from InDesign and Quark, so the criticism holds:
While I'm no TeX wizard, I prefer it because it allows one to off-load some of the tedium and repetitiveness to the computer, as opposed to repeatedly solving variations of the same problems by hand time after time after time.
So,
* using Quark is like being chained to a an oar which is covered w/ splinters and mostly broken at the other end and which will randomly break due to being poorly carved (Quark has crashed on me 183 times this year) leaving one adrift or run aground, or sometimes returning the vessel to its starting point (a few of those crashes have resulted in unrecoverable document corruption --- my autobackup folder may contain 2 or 3 GBs of files for a given iteration of a particular project each month) --- the oar can be smoothed somewhat and reinforced (by purchasing or finding XTensions, using XTags &c.) and periodically one is required to purchase a new oar (sometimes just after the previous one has been customized adequately). For some tasks, one can impress any graphic designer as a galley slave to ease the effort for others, but while charts are available, there are no automagic navigation options and every journey must be manually piloted.
* using InDesign is pretty much the same except the oar is smoother and stronger (it's crashed 29 times on me thus far this year), there aren't as many customization options and it's not quite as easy to find a candidate for impressment (though soon it'll be as easy as for Quark). Charts are available, but again, piloting is strictly manual.
* using Plain TeX one has to craft the vessel's oar oneself (as well as the rest of the vessel unless one is typesetting a clone of The TeXbook), but it's as sturdy and as nice a one as one's skills allow and can even be an engine which moves the vessel in and of itself --- it can be difficult or impossible to find people suitable to help w/ either carving the oar or using it though, but once a given journey is worked out, the oar becomes magical and rows for itself except for when one runs into an unplanned for obstacle (the navigation charts are old ones and not often up-dated, with a lot of “terra incognita”), allowing one an auto-pilot option for certain journeys, dependent upon one's skill. using ePlain, an oar is provided, can be customized, and can be enchanted and the charts are okay, but have a lot of “terra incognita” on them.
* using LaTeX, an oar is provided and there're lots of nifty customizations and improvements already available, and one can impress additional oars from CTAN, however on a semi-random basis, adding one oar will break other oars, sometimes leaving one adrift or run aground. One can enchant a set of oars to accomplish a given journey, easing the piloting requirement, and the navigation charts are decent and obstacles are fairly well-known.
* using ConTeXt, a very nice oar is provided, which has lots of customization options, but the navigational charts aren't easily read by a traditionally trained navigator at first, although they are fairly compleat and most journey can be carefully worked out, but once one is, it is quite automatic and there's a good auto-pilot option.
Where does the year and a half come from? Green card processing delay? That can be 10+ years for approximately 50% of the world population (Indians + Chinese)