I'm a college student majoring in CS, and that means I spend a lot of time poking around in vim. I'm still a complete noob, but I love editing text in the terminal--it's more fun than writing documents has any right to be.
However, I'm curious if there's a basic, low-frills document format I can use (from within vim) to typeset my homework assignments. I'm familiar enough with LaTeX, and if it were possible I'd use it for everything, but it has two main disadvantages:
It takes a long time to write an entire LaTeX document, and
LaTeX doesn't handle code very well.
With that in mind, I'd like to know if some format exists which addresses both these needs and is still easy to hash out quickly from a terminal-based text editor. I use vim for literally everything else I write, so the need to keep LibreOffice Writer around just for homeworks seems a bit overbearing to me.
Thanks!
I would tend towards something light like Markdown, but the needed capabilities depend on what requirements you have for the output (formatting and styling).
I find the AsciiDoc project quite interesting. From their website:
AsciiDoc is a text document format for writing notes, documentation,
articles, books, ebooks, slideshows, web pages, blogs and UNIX man
pages. AsciiDoc files can be translated to many formats including
HTML, PDF, EPUB, man page. AsciiDoc is highly configurable: both the
AsciiDoc source file syntax and the backend output markups (which can
be almost any type of SGML/XML markup) can be customized and extended
by the user.
It even comes with a Vim syntax.
Related
There are some files like GEDCOM and ADIF that are plain text files, but many people tend to work with them through GUIs. Say I wanted to do data entry on these files directly without any GUI.There are a number of things that make this a little dangerous. Things like misspellings of necessary file-grammar, missing a necessary key, incorrect types for values, etc. There is also something to be said for the additional difficulty of having to type additional characters relative to a GUI.
From what I can tell by thinking about this for 15mins ;) is that having the following would make the job of plain text entry much easier.
A formatter. I think of something like Python's Black which is a CLI that can be run on a file. It can let users know of bad formatting and can provide fixes.
A linter. I think of flake8 to ensure the styling matches the standard.
Autocomplete. The file type examples I showed above have a dictionary of key words. To save on typing it would be nice to have autocomplete.
Syntax Highlighting. Having a way to know if my data entry is good or bad in real-time would be helpful.
It seems like requirements 1-2 could be solved by making a file specific CLIs that combs through plain text files.
Requirement 4 seems IDE specific. vim and vscode allow users to make syntax highlighting plugins. The problem is that this is normally solved by connecting to a language server. When you are not looking for a language server, but for key words and proper values in a plain text file how does let their IDE know that to look for? Is this just a regex soup solution or is there a better way?
Requirement 3 may also be IDE specific, but the same question applies as for requirement 4. When there is not a language server how can I let an IDE know what/how to autocomplete?
Any examples of plain text data entry made easier would be appreciated.
Thanks!
Say I use markdown to write a memo, and convert it with pandoc to a DOCX, which my non-technically-inclined collaborator uses, and say the collaborator changes a few things while tracking changes.
Now I want to accept some changes and reject some others, then get the new version back into markdown to work on the next draft. But converting docx -> markdown with pandoc tends to be lossy--viewed as functions, the functions are not inverses; ToMarkdown(ToWord(md_file)) != md_file.
With this limitation, the pandoc/markdown workflow is basically a dead-end after draft 1. It's great to use vim and plaintext instead of Word for the first draft, but if there are a significant number of changes, then it's often just as much work to recover and verify them and correct unintentional losses in v2 of a markdown file from the collaborator's DOCX as it is just to put up with MS Word from the get-go.
Does anyone have a workaround for this situation that gets them to "v2" or higher using markdown / plaintext with minimal manual work in Word?
There is a long discussion at pandoc-discuss about the issue. The short answer is no, there is no support for to docx and back to md without losses.
That said, #mb21 mentions the --track-changes flag, which allows for a little bit more control, however you would have to incorporate changes manually.
The solution for your problem is either:
Convince collaborators to use md instead of Word, or;
Start using Authorea which uses pandoc in the background to generate the documents. You can even make it sinc with github, while your collaborator uses the webversion.
I have been experimenting with option 2, but it is super hard to convince most of the collaborators to move to an online interface.
I was using notepad++ to create a report and its taking a quite a while for me to type and do so.
Well i had tried a software called typing assistant it was really good(except for the money part :D).
TO the Point :
is there any way tat i can link a dict(text file of words) and use notepad ++ as typing assistant please tell me if so i
can speed my report.
Cause i am a programmer too so i really like the keyword completion and stuff .But is there a way to use it for text ?
already tried Phrase Express -.-:
Takes long and its kinda for macro text and text completion don't work tat fast for me to tab and complete
if there's a question in the form like mine link me to tat :
i searched it and i didn't get it
Yes, you can set up your own custom auto-complete dictionaries in notepad++. You need to create an xml file with your language name and put it under the plugins/APIs directory in notepad++. Of course this assumes you know how to write xml. There's a formal description of how to implement this here.
I've never tried to create an auto-complete dictionary for plain text files, so I'm not sure if it's possible, but I have successfully created them for user-defined languages, which you could also do if you can't get it to work with text files.
I'm not sure if this question is really a duplicate, but here is a very similar one, which may help you in your research.
I use ctags+Vim for a lot of my projects and I really like the ability to easily browse through large chunks of code quickly.
I am also using Stata, a statistical package, which has a script language. Even though you can have routines in the code, its code tends to be series of commands that perform data and statistics operations. And the code files can be very long. So I always find myself in need of a way to browse it efficiently.
Since I use Vim, I can use marks. But I was wondering if I could use ctags to do this. That is, I want to create a tag marker which (1) won't cause a problem when I run the script (2) easy to introduce to ctags.
Because it is supposed to not break the script, it needs to be a comment. In Stata, comment lines start with * and flow comments can be made by /* ..... */.
It would be great, for example, have sections in the code, marked by comments:
* Section: Data
And ctags picks up "Data Manipulation" as the tag. So I can see a list of sections and jump to them easily without the needs for creating marks.
Is there anyway to do this? I'd appreciate any comments.
You need a way to generate a tags database for your Stata files. The format is simple, see :help tags-file-format. The default tags program, Exuberant Ctags can be extended with regular expressions (--langmap, --regex); that probably only yields an approximate parsing for complex languages, but it should suffice for custom section marks; maybe you could even directly extract interesting language keywords.
Background:
It seems that some text editors and IDEs are starting to get more "browser-like" in their features. Specifically, one such feature is the ability to treat ordinary text in an open text buffer as a hyperlink to another file, resource, or even a runnable command.
Programming this as an editor plugin or macro
Since this seems like a good idea, I have started programming some scripts and editor addons to do this very kind of thing, so that the user of a text editor can open or operate on links of the following style:
href="c:/files/foobar.txt" (click to open file)
href="c:/files/foobar.txt" jumpto="34" (jump to a line number)
href="c:/files/foobar.txt" find="Lorem" (jump to 1st line containing word)
href="find_in_files://c:/files" find="Lorem" (show all matching lines)
[[find_in_files://find=Lorem;exten=*.htm*]] (alternate syntax option)
href="redir://c:/files/feebar.txt" (replace current edit buffer)
href="run://c:/files/foobar.jpg" (open in default image editor)
[[run://c:/files/foobar.jpg;runwith=foo.exe]] (alternate syntax option)
Questions:
Is there any kind of emerging convention for forming text-based hyperlinks?
If there is a convention for this kind of thing, is there a published specification?
Is there an implementation of this idea in your favorite editor/IDE?
Is there an alternate pre-existing approach for this idea that does not use hyperlinks?
How is this feature handled in the "grand-daddy" editors? (Vim, Emacs)
Update:
It looks like the question could have been clarified, but it turns out that Emacs Org mode is one specific example of what I was looking for that answers all of my questions.
Emacs' Org-Mode has support for all kinds of Hyperlinks.
There are several script for Vim that add hyperlinks and markup. One of the most popular is Viki.
URLs, such as http://example.com/ (notice SO automatically links that), and sometimes a "www." prefix, just because it's so common. Email addresses are another example commonly recognized.
But not this quasi-xml-attribute stuff you have.
Of course not; once you try and make plain text follow some convention, you no longer have plain text.
Yes, see #5.
Yes, see #5.
It's extremely common for editors, especially programmers' editors, to have scripts, macros, tools, or whatever-they-want-to-call-it. Usually these are not controlled directly by the text in the file, but may use the file, filename, selection, cursor position, directory of the current file, etc. I expect many good programmers use such features without thinking about them anymore.
Mostly it sounds like you're trying to solve a problem that doesn't exist.
Surely the jumpto="34" and find="Lorem" could be replaced with web-browser-style # and ? marks.
So your second and third example would look like so:
href="c:/files/foobar.txt#34" (jump to a line number)
href="c:/files/foobar.txt?Lorem" (jump to 1st line containing word)
Although, as Roger Pate says above, it does sound like you're solving a problem that doesn't exist.
Emacs also has "find-file-at-point", which you can invoke with M-x ffap
See also LinkD. Nothing fancy like Org. Simple, small.