As I'm writing Latex more and more on Sublime Text (3), I decide to totally move on to ST from TexnicCenter. However there's one thing I miss from TexnicCenter, that's the ability to show the project in outline view (e.g chapter/subchapter name,...)
For example, writing a long file with one master main.tex file, and each chapter is written in a separate file, TXC gives me this view on the outline panel:
Can I achieve such thing in ST3? (I know about Ctrl + R but it does not help in this case where the chapters are written separately.)
LaTeXing also offers a SHIFT+ Ctrl + R ("Goto Symbol in Project").
LaTeXing actually seems to consider all structure markers such as \chapter{test), irrespective of whether they are \input{} somewhere, so it's not the real logical structure of the document ...
Here's a screen shot:
It's still not just in the command palette, and not a real sidebar of the logical structure and there are some confusing duplications ... but still.
Maybe the folks over at atom latex will get on it at some point; atom might be more suited for this kind of flexible UI.
Related
I know that sounds vague. Basically I just want Sublime to highlight custom syntax (color the text), just like it does with native syntax.
I am using Sublime to write LaTeX code. For those that don't know, LaTeX equations are typically enclosed by \[ \], e.g.
\[ E = m c^2 \]
Sublime understands that syntax and colors the enclosing code appropriately.
However, I use my custom defined command, \eq{ ... }, which wraps the \[ \] functionality (so I can globally change some settings by just redefining the \eq definition). e.g.
\eq{ E = m c^2 }
I don't know anything about Sublime under the hood beyond basic key bindings. I want to expand Sublime's understanding of syntax to incorporate my custom command without wasting a ton of time digging through tutorials and such.
Since you are mainly interested in the result and not in the reasoning, I will try to be as straight forward as I can.
The LaTeX syntax of Sublime Text will change in release 3119 and I would recommend to use that, if you want to change something.
Just download it from https://github.com/sublimehq/Packages and put the LaTeX folder into the folder, which opens when you select Preferences >> Browse Packages... in the Sublime Text menu.
Afterwards open the file LaTeX.sublime-syntax and search for ensuremath (LaTeX.sublime-syntax#L498). Duplicate that part (everything with a higher indent) and change the command to the command you wish, e.g. in your example this would be - match: '((\\)eq)(\{)'.
Aside the new syntax removes the highlighting of math environments as strings, because this has lead to several problems.
I made a small entry in the LaTeXTools wiki to explain, how you restore the highlight.
I am writing a plugin that marks specific lines, and will be trying to paint a highlight marker for specific lines over the code editor. To do this, I need to calculate the position onscreen of specific lines of code, ie rows in the buffer.
The Delphi code editor has some access to which lines are visible onscreen via IOTAEditView's BottomRow and TopRow properties. However, in newer IDE versions code regions and methods can be folded - that is, several lines are collapsed into one. The first step to line highlight painting is to know which lines are visible and where they are located, and to do this I may need to keep track of which parts of the editor are folded and which are not. There seem to be OTAPI methods to invoke code folding (elision) but not to know when it occurs.
However, some plugins, such as Castalia, do manage this. How can it be done?
An IDE editor control has a method, IsLineElided. Elision[*] is the IDE's internal term for a line being hidden when it is part of a collapsed region, method, or other structure. In the UI, this is called "folding", as in "code folding", but it's quite common for the internal term for something to be different to the UI term presented to the user.
This method is not publicly accessible; it's a method of the internal TEditControl class. To use it, you need to call an IDE method. Unlike a lot of IDE hacks you don't need to hook it, since you don't need to change its behaviour - just call it.
Mangled name: #Editorcontrol#TCustomEditControl#LineIsElided$qqri
with method prototype: TLineIsElidedProc = function(Self: TObject; LineNum: Integer): Boolean;
located in the coreide*.bpl file.
For example,
PFLineIsElided := GetProcAddress(CoreIDEHandle, StrIDELineIsElidedName);
You can get the core IDE BPL handle by reading loaded modules. The first parameter should be the editor window - not the ToolsAPI edit view, but the internal editor. This article shows the relationship between the editor control and IOTAEditView.
You can now ask if a line is elided (that is, is it hidden?) from your plugin like so:
if PFLineIsElided(FCodeEditor, 123) then ...
However, putting that together to see which areas are folded - or rather, since the top line of any folded region is still drawn, finding the line after which one or more lines are elided - require slightly more logic. The best way is to iterate through the lines onscreen in a view, IOTAEditView.TopRow and BottomRow. If the line after the one you're looking at is folded, but the one you're looking at isn't, then the one you're looking at is the representative line for the folded area (the line that has the +/- symbol in the gutter.)
Note that if you are painting on the code editor the difference between logical line numbers (line numbers as printed in the code gutter) and nominal line numbers (lines visible onscreen in the view) will be important for you, and code elision is what controls this. When code is folded, logical and nominal line numbers won't match: an edit view always draws nominal line numbers in order, but if there is a folded region in the middle, the logical line numbers will have gaps.
Further reading: A large article about integrating with the code editor, one section of which discusses code folding and handling line numbers. It's one of two on the topic of Delphi plugins / wizards integrating with the code editor on the Parnassus blog. Although it covers much more than folded code, if you're writing an IDE plugin that needs to handle this kind of stuff, there's a lot of useful material there. (Disclaimer: my blog.)
[*] As an aside, elision is an auto-antonym: a word that has two meanings that are opposites (the common example is 'cleave'.) One meaning of elision is omission or removal, and another meaning is joining or merging.
IEEE conference publications in two-column format require authors to manually equalize the lengths of the columns on the last page of the final submission. I have typically done this by inserting a \newpage where necessary -- which usually ends up being somewhere amidst my (manually entered) references.
However, I have recently begun using BibTeX to manage references, and have now run into a problem: my last page contains only a few (generated) references, and I can't figure out how to manually equalize the columns.
The last page is the tail end of what is generated by:
\bibliographystyle{IEEEtran}
\bibliography{IEEEabrv,library}
Any ideas on how I can equalize the columns while continuing to use BibTeX?
I have submitted to both ACM and IEEE conferences and the easiest thing for me has been using:
\usepackage{flushend}
I've heard it doesn't always work well, but it's been great for me
http://www.ctan.org/pkg/flushend
I went back to RTFM again, and it turns out this is addressed right in "How to Use the IEEEtran LaTeX Class" by Michael Shell (maintainer). Section XIV notes that IEEEtran helpfully provides the \IEEEtriggeratref{} command for just this purpose. By default, it fires a \newline at the given BibTeX reference number. You can even change the command to fire with \IEEEtriggercmd{}.
It can also be done by using the balance package. You simply include the balance package in the preamble (\usepackage{balance}) and insert \balance some place on the last page of your document (for instance right in front of the references). However, I'm not sure if it's working if the last page (both columns) is completely full of references...
IEEE requires authors to equalize the lengths of the columns on the last page.
ACM makes us do this too. I just wind up inserting \vfill\break by hand either in the main text or somewhere in the .bbl file, wherever it makes the columns balance. By the time camera-ready copy goes to ACM, they want the .bbl file inlined by hand anyway, so tinkering by hand does not present an additional hardship.
The reference-number trick might be nice except I never use numbered references :-)
The multicols environment works only if you're luck and your last page comes out exactly as bibliography.
It would be extremely good (and not so difficult) if some enterprising hacker would build the "balance the two columns in the last page" functionality straight into LateX's \output routine. The flexibility is there in the underlying engine, and it would make a lot of people happy.
Not sure if multicol conflicts with bibtex at all, and I don't have time to check, sorry. But try this:
use the multicol package:
\usepackage{multicol} in your preamble, then:
\begin{multicols}{2}
\bibliographystyle{IEEEtran}
\bibliography{IEEEabrv,library}
\end{multicols}
Multicol automatically balances columns. I would recomend using it through out your document, instead of using the .cls or .sty's twocolumn option.
I'm currently using the LaTeX listings package to display a block of code, and a diff of the file against a previous version.
Both blocks are coloured by listings as if they are code (which they are) but I would like to colour the diff similarly to emacs diff-mode - red for lines matching ^-, green for ^\+ etc.
Does anyone know if there is a package to achieve this, whether listings can do it, or whether it is possible to write a LaTeX command to do it? (or rather - where a good source of information on the latter can be found?)
Thanks,
Hud
If you just want unadorned diffs, Pygments supports them, so texments (a latex front-end for pygments) does what you want.
But I guess that what you want is to have diff's coloured, while having the syntax of the underlying code highlighted appropriately. This you can't do properly the usual way, in general, because syntax highlighting may depend on the state from the previous line, and with udiffs the previous line may be missing, or an inserted line might follow a deleted line, &c.
To do the right thing, you'd need to syntax highlight the old and new versions, and then scramble the highlighted versions together to get the right output. Quite a bit of work, and I've not heard of anyone who's done that.
You could also try simply modifying the usual syntax highlighter for a language, removing highlighting rules that involve multiline state, and inserting rules to colour lines with udiff markup. Cf. Pygments' Write your own lexer; what you want from diff is trickier, since you want what is coloured to be highlighted, so you can't just make the lines into GenericTokens; I don't know what the right way to do this is.
Use a scripting tool such as sed, awk, Python [lang of choice]to produce the Latex source code.
I am currently writing a long one-column document that contains a lot of floats (figures and tables). I know the usual b/h/p/t options for placing floats in latex. However, I was wondering if there exists a package or macro that would let me do the following automatically: place a float automatically right after it was first reference. So if the reference appears on the top of page x, then the float would most likely appear at the bottom of page x, or maybe at (the top of) page x+1. In any case it should not occur before the reference.
I know that this may be hard to achieve but then I am not a latex guru either...
(Note that this question is different from this one.)
The LaTeX Companion says that the flafter package can be used to ensure that floats are never placed before their references. To use this, add the following to your document's preamble:
\usepackage{flafter}
Note that, according to this thread, what flafter does is ensure that the float never appears before its position in the LaTeX source code.
This may work well if your document only has a few floats. For documents with lots of floats, placement becomes much more difficult, and you may find that all your floats appear together at the end of the document or chapter, or you may receive a "Too many unprocessed floats” error. I suggest reading this page and this page in the UK TeX FAQ for more suggestions.