I try to create a snippet which needs a little elisp code (about 15 lines). I don't want to put all the code there to make the snippet looks very ugly. A function call is the best choice. But I am not sure where should I put the code for that function.
For example: (Ugly)
${1: $(supper long elisp code here)}
I expect something like:
${1: $(my-function arg)}
Then where should I put my-function code?
You can place the code in your initialization file. The function just needs to be defined before call yas-expand.
(Edited to include followup from comments.)
You can also create a .yas-snippet.el file in the same directory as the snippet with your function (example).
Related
I want to publish my assignment with matlab.
At the start of the program, I want to print the code of my scripts to show the teacher what my functions do.
How can I do this?
So far the best way I do this is by making a dummy call at the start without ending the function call with ";"
However I'd really like to just print the code at the start.
You can use the type command:
type fileName.m
This will print the code, similarly to creating a variable and not using a semicolon to see the value of that variable.
There are tools in MATLAB for publishing code. You could conceivably even write a report in MATLAB code and publish that! Take a look at publishing MATLAB code and the documentation of the function publish
If you are interested to print particular lines from a .m file, look into dbtype.
Illustration from Mathworks site linked above. This:
becomes this:
I'm having troubles with my code in Matlab. I want to get the mean value of all the elements in the second column in a file, but for some reason the code does not include the last line.
My file looks like this:
And my code looks like this:
As you might already understand, my code gets the mean value of all numbers except the last one for Italy.
Any suggestions on how to proceed would be highly appreciated.
It's actually suggested by Mathworks to not use feof with fgetl loops, but to instead check whether the output is with ischar. Simply replace ~feof(fid) with ischar(line).
A side note: line is also a MATLAB function, by using it as a variable name you are shadowing the function. While it is not critical here, you should try to avoid doing this. If you try to use line the function or another function which calls line while you have a variable line in the workspace, you'll likely get an error. This is why you'll see the examples in the help use things like tline as variable names instead.
You should put
line=fgetl(fid)
to the top in the while loop.
I have some C++ code that contains 5 or so lines of code that I want to refactor into a function. When I right-click->refactor->extract function, the refactor generates the function correctly, but it insists also on reformatting a large chunk of code that has nothing to do with the code I'm refactoring. Furthermore, neither the reformatted code nor the generated function fits my current style (K&R modified by me) as near as I can tell.
Why does it do this?
Is there a way to get it to follow my code style?
Is there a way to turn it off?
I wrote a Lisp function earlier that had an error. The first challenge was to figure out how to view the function again. That challenge is solved. Now that I see WHAT I have done wrong, I want to modify the contents of the defined function without rewriting the whole thing?
Seems like as intelligent as Lisp is, there HAS to be a way to do this, I just don't know what it is because I am fairly new to the language. Can this be done?
Judging from the question, I think that you have a strange setup. It seems to indicate that you are writing your functions directly at the REPL. Don't do that.
The usual setup is to have an IDE (for example, Emacs with Slime) where you edit a source file, and then "send" top-level forms (like function definitions) to the REPL.
Every useful REPL has a history functionality. It allows you to move in the history of your input backwards and forwards.
When I write code in the REPL simple keystrokes like m-p gets back earlier code. Some IDEs might even be able to locate source code in a Lisp listener with m-. .
In most REPLS you can also search incrementally backwards.
If you want a log of your input use the function DRIBBLE..
There are some more options, like retrieving the code from the function - when a Lisp IDE supports that.
There is the advice functionality in many Lisps, which lets you run additional code before or after or around an existing function. But the comment is right, why wouldn't you rewrite a function if you're still learning and trying things out? Do they charge you by the compile cycle?
I try to make a useful macro for logging. But I find that NSLog and all other sort of macros that carry textual information with them simply distract a lot from the code.
Is there any way to "hack" Xcode in a way that it will interpret something like
/*** do this because of that ***/
as a macro call, which results in calling NSLog, for example? I want those logs to "feel" like comments. Anything else that looks like critical code is just distracting and reduces productivity at the end, and then there's no real benefit from logging what's going on.
Is it possible to define a macro that looks almost like a comment?
Why do you want to make your code less readable?
The answer is no, and that's a good thing.
Is there any way to "hack" Xcode in a way that it will interpret something like
/*** do this because of that ***/
as a macro call…
Probably, but that's useless. All that would do is make the syntax coloring incorrect (coloring this comment as if it were a function call). The compiler (either GCC or Clang) would still see this as the comment that it is.
Making the compiler think it's a function call or macro invocation is what would actually achieve log output at run time, but even if you could do that, it's still a bad idea because you would have a function call or macro invocation disguised as a comment.
If you want your program to log messages, write logging code:
NSLog(#"Do %# because of %#.", foo, bar);
This code is explicitly code that does something at runtime. No mystery. No surprises. That's why it's better.
You can enclose one or more lines of NSLog in curly braces and then use Xcode's folding option to hide them.
Example:
{
NSLog(#"<#label#>");
NSLog(#"<#label#>");
}
when folded look like:
{...}
The braces will also indent the statements when unfolded making them more visually distinct.
I think you should reconsider your use of log statements. If you have as many logs statements as lines of code something is wrong. You should be using the debugger to print most values and messages. If you have that many log statements you reach a point where mistakes in the log statements produce more bugs than the code. You also have a big problem cleaning up the code for release.
Not that I know of (though I may be wrong!)
I think that if you want it to look different, a macro is probably the best that you can hope for - at least it will be highlighted a different color :)