I have downloaded a verilog/systemverilog indent file which looks really comprehensive. However, there is a problem: it doesn't work. I'm looking at the vimscript code and want to both fix it (I'm on vim 8.2, maybe there's a version mismatch) as well as enhance it. However, I'm running into issues debugging. Specifically, indentexpr scripts have a variable v:lnum which is set when indentkey is pressed and the indentexpr is evaluated.
BUT, I don't know of a way to enter debug mode on just the indentexpr call. I tried manually calling the function inside the vimscript but that leaves v:lnum as some garbage number (well, the last line to invoke indentexpr). Is there a way to enter debug mode when I actually hit a key that invokes indentexpr?
The best way for v:lnum to be used is as an argument to the function. Here's an example: vim-ruby's indentexpr setting used to look like this:
setlocal indentexpr=GetRubyIndent()
Inside the function, the variable v:lnum was used to get the line number that it was called on. This, as you've discovered, is pretty inconvenient. So, the better way is:
setlocal indentexpr=GetRubyIndent(v:lnum)
So, find the place in the script where the indentexpr is set and change it to take the magic v:lnum variable as an argument. You could then rewrite the function itself to take a single argument:
function! GetRubyIndent(lnum)
Now, in that function, the a:lnum variable will be the line number, and you can call the function with that argument. Search-and-replace v:lnum with a:lnum everywhere in the function. The indent script should now work as it did before, and you'll be able to call the function manually with a line number.
Here's the specific commit that does this in the vim-ruby repository, as an example
Additionally, echomsg "foo" will print a message that you can read afterwards by running the :messages command. And I can recommend the Decho plugin for easy-to-read debug messages.
Related
I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.
In writing a function for fish shell I want to know if a lone wildcard (not part of a bigger expression) was used in the command arguments. Fish does the wildcard expansion before passing arguments to my function, so there is no easy way that I can see to do that, aside from check whether the arguments are the same as the output of ls. The inefficiency of that method makes me sad, though. Is there a better way to do this, without going into fish's source code?
EDIT:
Thanks for the input. Specifically, I am looking to add some functionality like zshell has for warning if there is a * in the arguments of rm. I know that there was an issue opened on GitHub specifically about this but I couldn't find the link again. I have typod, for example, rm * .o instead of rm *.o, and accidentally deleted all my code (... which I brought back from git, but still).
EDIT 2:
Here is the issue on GitHub: https://github.com/fish-shell/fish-shell/issues/1511
No, there's no way for a function to tell where its arguments came from. Maybe if you give more details about what you're really trying to accomplish, we can give another suggestion.
I was wondering if it is possible inside liteIDE to run only one function, using some parameters, and see what a variable contains after executing one specific code line.
Thanks.
Indeed, I could (and should !) write a test for it.
And for seeing what a variable contains at some step in the execution, either:
debug-print it inside the function, then run the test
Use a debugger (for go it's called delve) and step through either the test or the real program
If I do C-u M-x recompile inside a buffer that's not the *compilation* buffer, (i.e. the source file for instance), I get this error - "Wrong type argument: consp, nil" after it prompts for the compilation command. Why is this? I want to run recompile interactively as comint works, sometimes outside the compilation buffer. How do I do this?
Try using emacs -Q, just to be sure (yes, I know you said you commented out all of your init file, but just to be sure -- and it's a lot easier to do than comment-out everything).
Next, set debug-on-error to t -- You can do M-x toggle-debug-on-error to do that, if you prefer.
Next, provoke the error and look at the debugger *Backtrace*. It will show you not only which function raised the error because it expected a cons and got nil instead, but also what function called it, passing the bad argument. And so on down the stack.
If necessary, you can click mouse-2 on functions on the stack (at the left, to see their source code. Or put the cursor on them and use C-h f to see their doc -- in particular, what arguments they expect and what their return values should be.
In this way it's pretty easy to find the code that is the culprit. (Most likely, in spite of what you said, it is some non-vanilla Emacs Lisp code you loaded somehow.)
Also, state your emacs version : M-x emacs-version. If you are using a development snapshot then the problem could come from vanilla code (i.e., emacs -Q); otherwise, that's not so likely.
Also, you say you get the error after it prompts you. Immediately after it prompts, before you type anything? After you type a command name and hit RET? Try to be more specific.
Update after your comment:
Load library compile.el (not .elc). Then do M-x debug-on-entry recompile, then step through the debugger using d when function recompile is entered. What you are interested in is when compilation-start is called (applied to its args).
It seems that the value of compilation-arguments that is passed to it is no good. The command name you enter at the prompt becomes the first of the list of compilation-arguments. The others are taken from when you last invoked compile: recompile just reuses the same arguments (except the command name): (mode name-function highlight-regexp)mode name-function highlight-regexp).
However, be aware that compilation-arguments is buffer-local. So if you changed to a different buffer then its value is likely not what you need. You need the value from your last compile, so you should do the recompile in the same buffer where you did compile.
(FWIW, I don't use (re)compile myself, as I don't develop software anymore. I just took a look at the source code.)
Such kind of errors usually depicts a problem with your configuration. Try to investigate messages buffer output. There can be some clues there.
And of course, it is normal to call a recompile command from a buffer with your code. It is a convention to bind it to C-c C-c.
I'm currently in a Python interactive interpreter session. I have a function that I know is doing something funky, so I want to step through it in a debugger session. I know the file name and line number of the function.
Is there any way for me to now set a breakpoint in the start of that function, then run it and step through it? Without having to open an editor, locate the file, locate the function, manually insert import pdb; pdb.set_trace(), saving the file, then go back to the interpreter, reload the module the function came from and running it? Not to mention that if I forgot to remove the pdb trace that'd spell trouble later.
Summarizing the question: If I'm in a normal Python interpreter session (or iPython), is it possible to set a breakpoint somewhere and start debugging, without having to actually edit in the code pdb.set_trace() somewhere?
I can't believe I missed this, but I just glanced over the pdb documentation a second time and realized that all the run* functions do pretty much exactly what I want. They don't let me set a specific line as a breakpoint, but I can pass the function and the arguments I want to use, and it will break on the first line of the function:
import pdb
pdb.runcall(my_wonky_function, "arg1", "arg2", *myargs)
Well actually it broke at a mystical location called "EOF":
(Pdb) list
[EOF]
and I had to step twice before I got to the first line of the function, but that's hardly a problem.