I have seen .gnu, .plt, and .gplot as file extensions for gnuplot scripts.
I know Linux doesn't care about file extensions, but what extension most universally declares to human beings "I am a gnuplot script!"?
As Romain, Dr. Person and neillb all point out and this wikibooks article confirms, there is no official standard extension for gnuplot files.
These three file extensions do seem popular:
.gpi
.plt
.gp
Of these .gp is shortest and seems like it would have the fewest collisions with other programs. But the other two extensions aren't in heavy use either. It appears that .plt was used by HPGL plotters and therefore some old Autocad files may have this extension. And files with a .gpi extension are used by Garmin GPS devices. Fwiw, googling for "gnuplot file extension gp" returns a few more results than similar searches for .gpi and .plt
While .gnuplot is a fair choice, it is seven characters long. Long file extensions can potentially detract from readability in the terminal because they open up the possibility of file names that are shorter than the file extension and because longer extensions are more likely to cause lines to wrap.
vim recognises .gpi, for more see Gnuplot Wikibook.
Gnuplot uses .gnu for the demos on their website, so I take that to be the standard.
what extension most universally
declares to human beings "I am a
gnuplot script!"?
For that, ".gnuplot" is hard to beat!
It's not common (probably because it's a bit long) but it unambiguously tells a human being what's inside the tin.
In contrast, wikipedia lists six other file formats with the extension .plt.
I don't think that ".gnuplot" should have been accepted as THE answer. There really isn't an answer. I've seen and used ".gp" before which is nice.
Wikipedia seems to suggest .plt would be standard-ish. That being said, GnuPlot itself doesn't define any standard and makes it freeform, so there isn't really an extension that tells "this is a gnuplot script".
Worth noting. Visual Studio Code has an extension for gnuplot syntax highlighting. It defines 5 extensions for gnuplot files:
.gp
.gnuplot
.gnu
.plot
.plt
Related
I apologize if this this is an extremely amateur question. But before yesterday I had never even heard to tex, latex, mactex, all this stuff.
Basically I have cloned a git repo in which the UML documents appear to be in a .tex file. Following google, this has led me to install MacTex, try to open these files. Click 'typeset' which I presume is how it produces the document, but it gives an error about 'uml2' being invalid syntax.
What program, or what anything, am I supposed to use to open a .tex file which has stuff like this in it:
\tikzstyle{uml2} = [
fill=rupBody,
draw=rupBorder,
font={\ttfamily},
]
Is this even something your supposed to open in a program and view visually? I suppose this file named uml.tex will show a UML diagram once opened. Or do I have completely the wrong idea? Sorry if this is extremely amateur, like I said I've never heard of this since before yesterday, and google isn't turning up lots of information on this. Any direction would be much appreciated.
You need to install pgf from http://ctan.org/pkg/pgf The easiest is to use TexLive. Once you got all packages installed you can typeset the TeX file. I'm using TexShop which is a nice app for the Mac.
Since you indicate you never heard of TeX before: TeX is a program written by Donald Knuth many, many years ago when computers were engined with steam. But it's the best you can find for typesetting. It's mature, crude and more than 99,99% error free. Donald Knuth has a bounty for each error you find in the code and he did not have to pay since many years. What you do is to create those TeX files (there are different macro packages were LaTeX is the most famous) and send them to the TeX processor. That will create the output (now its PDF and formerly it was some DIV (device independent viewer IIRC)).
Edit I downloaded tikz-uml from here: http://perso.ensta-paristech.fr/~kielbasi/tikzuml/index.php and moved the tikz-uml.sty to folder where the main .tex source is placed. After including
\usepackage{tikz-uml}
in the header I was able to compile the source.
Note: there is a global location for .sty files but that depends in the app you use. Use Google to find this place. But putting .sty near your .tex is fine anyway. A \usepackage directive first looks in the source folder before looking into the global ones.
Where do I write a manual entry when creating a deb package? Is there any formatting rule/best practice to respect?
I'm very new to deb package creation. Following some tutorials, I just created a package that installs/executes nicely, so now I'd like to write some documentation so that man myFancyPackage returns something instead of no manual entry for myFancyPackage.
Unfortunately none of the tutorials I found speak about manual creation.
There are lots of methods to build a Debian package, but the current "best practice" is to use the tools provided by Debhelper. In the case of man pages, there is a tool named dh_installman (read its manpage) that is called automatically by dh. If you used dh_make or similar to create a template for your package, then a dh invocation will be in your debian/rules file.
dh_installman works by reading the file debian/manpages, or debian/nameofyourpackage.manpages. This file has a list of paths pointing to the man pages of your package. The paths are relative to the root of your package. Here you have an example of a real package. Then, this program will properly install your man pages in the right directory.
So, to sum up, you only have to create the debian/package.manpages and fill it with the paths to your man pages. These paths have to be relative to the root of your package. If you, the packager, are writing the man pages, then they have to be placed in the Debian/ directory.
Man pages were traditionally composed in a typesetting language called roff using a macro package called an (so the command line was roff -man, sic) but few people write raw roff anymore.
There are various SGML and XML documentation formats which have the capability to generate man page sources, though in this day and age, Markdown is probably gaining ground as the de facto standard for new documentation. The top Google hit for me is https://github.com/remarkjs/remark-man though I would definitely also suggest you look at pandoc.
# NAME
Markdown - popular text markup language
# SYNOPSIS
man markdown
# DESCRIPTION
This is a popular lightweight syntax
to generate styled text from an
editor-friendly text source.
It is used on [Stack Overflow][1],
[Github][2], and increasingly on
blogging and authoring platforms.
[1]: https://stackoverflow.com/
[2]: https://github.com/
I'll also mention POD format, which has a long history in the Perl community, and many features in common with popular, more recent lightweight formats. Unless you have other reasons to like it, I would not choose it for new documentation, but it used to be moderately popular even far outside the Perl world back when it was one of the only options with a simple human-readable source format, obvious semantics, and a versatile and well-maintained toolchain and support ecosystem. Some would probably say it still is.
=head1 NAME
Pod::Example - Example POD document
=head1 SYNOPSIS
pod2man thisdoc.pod >thisdoc.1
=head1 DESCRIPTION
Lightweight syntax for subheads,
hyperlinks, indented lists,
and not much else.
Natively supported in Perl source files
to facilitate a crude form of
literate programming.
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.
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.
I'm using the LaTeX-Beamer class for making presentations. Every once in a while I need to include screenshots. Those graphics are pixel-based, of course. I use includegraphics like this:
\begin{figure}
\includegraphics[width= \paperwidth]{img/analyzer.png}
\end{figure}
or usually something like this:
\begin{figure}
\includegraphics[width= 0.8\linewidth]{img/analyzer.png}
\end{figure}
This leads to pretty bad readibility of the contained text, so I'm asking for your best practices: How would you include screenshots containing text considering, that I will do the output PDF with pdflatex?
EDIT: I suppose I'm looking for something like an 1:1 presetation of the image within beamer. However, [scale = 1.0] doesn't achieve what I'm looking for.
Your best bet is to scale the image outside of Latex for inclusion, and include it in 1:1 ratio. The scaling done by graphics packages in Latex isn't going to be anywhere near as good as possible from other tools. Latex (Tex) has limited floating-point arithmetic capabilities, whereas an external tool can use sophisticated algorithms to get the scaling better.
Another option is to use only a part of the screenshot, the one you want to concentrate on.
Edit: If you can change the font size before taking the screenshot, that's another option—just increase the font size for the screenshots.
Of course, you can combine the two methods.
I have done exactly what you do and e.g defined
\newcommand{\screenshot}[1]{\centerline{%
\includegraphics[height=7.8cm,transparent]{#1}}} % 7.8in
which worked with whatever style I was using at the time. The files included with this macro were all PNGs created with one the usual Linux screen capture tools.
Edit: You may have to play with the size (height and width) of your input files. It came out rather nice for me (and this was from a presentation in 2006).
How about scaling it as follows:
\includegraphics[scale=0.5]{images/myimage.jpg}
This works for me.
Have you tried to convert the image to .eps or .pdf file and use this file in LaTeX?
Maybe try also latex, dvips and ps2pdf.
Problem might be in used viewer, in Linux I use Document viewer or ePDFViewer and output is much worse than in Adobe Reader or Acrobat, which I use in Windows...