How to make arbitrary code blocks foldable in spyder - spyder

I want to group arbitrary blocks of code, say parts of a script. And then I want to be able to collapse them, just like I can collapse classes, function definitions and loops.

This can be done in Spyder 4 or later by defining a code block with a comment like so:
# %% lines below here can be collapsed

Related

Getting different statement coverage for the same piece of code using gcov and gcovr

I am new to using gcov and gcovr and I wanted to get the statement coverage of a given function. It is coded in C, compiled with minGW and called from Matlab (which I use to later process the coverage information given by gcov).
I am executing the code in two different ways: for the first one I am using Simulink, in which the function inputs are given by the outputs of other functions that encompass the dynamic process I modelled on Simulink. For the second one, I am using the editor on Matlab and defining directly the inputs to the function.
Because the Simulink - executed code depends on secondary functions whose output I cannot control (contrary to the second way), I expected the statement coverage of the first execution to be worse than the second but to have the same number of statement lines (since it is exactly the same code). However, I found that:
For some function callers inside the function, the second method counts the few lines of the caller (like the first line and the following lines when the input and output variables are too long to fit in a single line), adding up statements that in reality don't exist.
The first method doesn't take into account some variable definitions at the beginning of the code, not counting them as line statements (for instance, setting input variables to 0).
Has anybody also encountered this discrepancy when getting the statement coverage of the same function? Do you know why this may be?
Thank you very much in advance!

LaTeX - Define a list of words to use a certain font

Problem
I'm writing an essay/documentation about an application. Within this doc there are a lot of code-words which I want to be highlighted using a different font. Currently I work with:
{\fontfamily{cmtt}\selectfont SOME-KEY-WORD}
Which is a bit of work to use every time.
Question
I'm looking for a way to declare a list of words to use a specific font within the text.
I know that I can use the listings package and define morekeywords which will be highlighted within the listings-environment but I need it in the text.
I thought of something like this:
\defineList{\fontfamily{cmtt}}{
SOME-KEY-WORD-1,
SOME-Key-word-2,
...
}
EDIT
I forgot to mention that I already tried something like:
\def\somekeyword{\fontfamily{cmtt}\selectfont some\_key\_word\normalfont}
which is a little bit better then the first attempt but I still need to use \somekeyword in the text.
EDIT 2
I came upon a workaround:
\newcommand{\cmtt}[1]{{\fontfamily{cmtt}\selectfont #1\normalfont}}
It's a little better then EDIT but still not the perfect solution.
Substitution every time a word occurs, without providing any clues to TeX, might be difficult and is beyond my skills (though I'd be interested to see someone come up with a solution).
But why not simply create a macro for each of those words?
\newcommand\somekeyword{\fontfamily{cmtt}\selectfont SOME-KEY-WORD}
Use like this:
Hello, \somekeyword{} is the magic word!
The trailing {} are unfortunately necessary to prevent eating the subsequent whitespace; even the built-in \LaTeX command requires them.
If you have very many of these words and are worried about maintainability, you can even create a macro to create the macros:
\newcommand\declareword[2][]{%
\expandafter\newcommand%
\csname\if\relax#1\relax#2\else#1\fi\endcsname%
{{\fontfamily{cmtt}\selectfont #2}}%
}
\declareword{oneword} % defines \oneword
\declareword{otherword} % defines \otherword
\declareword[urlspy]{urls.py} % defines \urlspy
...
The optional argument indicates the name of the command, in case the word itself contains characters like . which cannot be used in the name of a command.

Is there a solution for transpiling Lua labels to ECMAScript3?

I'm re-building a Lua to ES3 transpiler (a tool for converting Lua to cross-browser JavaScript). Before I start to spend my ideas on this transpiler, I want to ask if it's possible to convert Lua labels to ECMAScript 3. For example:
goto label;
:: label ::
print "skipped";
My first idea was to separate each body of statements in parts, e.g, when there's a label, its next statements must be stored as a entire next part:
some body
label (& statements)
other label (& statements)
and so on. Every statement that has a body (or the program chunk) gets a list of parts like this. Each part of a label should have its name stored in somewhere (e.g, in its own part object, inside a property).
Each part would be a function or would store a function on itself to be executed sequentially in relation to the others.
A goto statement would lookup its specific label to run its statement and invoke a ES return statement to stop the current statements execution.
The limitations of separating the body statements in this way is to access the variables and functions defined in different parts... So, is there a idea or answer for this? Is it impossible to have stable labels if converting them to ECMAScript?
I can't quite follow your idea, but it seems someone already solved the problem: JavaScript allows labelled continues, which, combined with dummy while loops, permit emulating goto within a function. (And unless I forgot something, that should be all you need for Lua.)
Compare pages 72-74 of the ECMAScript spec ed. #3 of 2000-03-24 to see that it should work in ES3, or just look at e.g. this answer to a question about goto in JS. As usual on the 'net, the URLs referenced there are dead but you can get summerofgoto.com [archived] at the awesome Internet Archive. (Outgoing GitHub link is also dead, but the scripts are also archived: parseScripts.js, goto.min.js or goto.js.)
I hope that's enough to get things running, good luck!

How can I keep track of code folding in the code editor?

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.

Collapsing If-Then-Else statements in code editor (Delphi 2007)

Every once in a while I'm editing some long pair of if-then-else statements (or worse, nested if-then-else statements) , like, say, this:
if A < B then
begin
DoSomething;
DoSomethingElse;
{...and more statements going on and on and on...}
FinallyWrapUpThisBit;
end
else
begin
DoThis;
DoThat;
{...and more statements going on and on and on...}
FinallyWrapUpThisBit;
end;
...and I find myself wanting to "collapse" the first begin-end pair, to bring up the lower "else" part (usually because I'm referring to something above the if-then statemnent. Maybe so it would just say "begin..." and have [+} sign to the left of it to expand it out again.
I've explored the "fold" functions in the IDE, but none of the commands seem to do this. It seems like my CodeRush for my old D6 did this, but I could be imagining things. (I have a very active imagination...).
Do any of the IDE plug-ins like Castalia (or some other one) do this?
With plain Delphi out of the box, you would have to surround your begin...end with
{$region 'begin...end'}
....
{$endregion}
which can be done through a code template...
I remember Castalia for the nice colored visualization of code blocks (begin..end) but I don't remember if it was foldable.
Use the refactoring tools to move the conditional branches' code into separate functions. Then you won't need to fold anything. You might also find that you can merge code that's common to the two branches, such as that call to FinallyWrapUpThisBit.
Another big helper here would be CNPack. It is a wizard which installs into Delphi and will colorize your begin/end pairs, making it MUCH easier to follow the code. It doesn't exactly do code folding, for that you need to use the {$REGION} {$ENDREGION} tags.

Resources