GNU Emacs 23.2.1
GCC 4.4.4
I am using gdb-many-windows to debug.
I am just wondering is there anything better?
At the moment I am debugging a linked-list. The list is not that big. However, it would be nice to see all the elements' values. Instead of having to 'print sorted_queue->next->seconds' all the time.
The watch command works ok, if a value changes. However, sometimes its nice to see all the values you want to watch in a separate buffer for easy review.
Everytime I what to see what a value is I have to issue the command print (p) and the name of the variable. Just a lot of typing. One thing Visual Studio is good for is debugging. It would be nice to see Emacs with some of those features.
Many thanks for any advice,
You might like the Data Display Debugger, a.k.a. DDD:
As far as dumping of the data structures is concerned, GDB Python extensions might interest you. Then you could make 'print list' output '5 10 2 4 50' or whatever presentation you like.
You can read introduction to GDB Python scripting here.
Related
I have a problem. I want to execute some commands in the Commandline of linux. I tested TProcess (So i am using Lazarus) but now when i am starting the programm, there is nothing, wich the Program do.
Here is my Code:
uses [...], unix, process;
[...]
var LE_Path: TLabeledEdit;
[...]
Pro1:=TProcess.Create(nil);
Pro1.CommandLine:=(('sudo open'+LE_Path.Text));
Pro1.Options := Pro1.Options; //Here i used Options before
Pro1.Execute;
With this Program, i want to open Files with sudo (The Programm is running on the User Interface)
->Sorry for my Bad English; Sorry for fails in the Question: I am using StackOverflow the first time.
I guess the solution was a missing space char?
Change
Pro1.CommandLine:=(('sudo open'+LE_Path.Text));
to
Pro1.CommandLine:=(('sudo open '+LE_Path.Text));
# ----------------------------^--- added this space char.
But if you're a beginner programmer, my other comments are still worth considering:
trying to use sudo in your first bit of code may be adding a whole extra set of problems. SO... Get something easier to work first, maybe
/bin/ls -l /path/to/some/dir/that/has/only/a/few/files.
find out how to print a statement that will be executed. This is the most basic form of debugging and any language should support that.
Your english communicated your problem well enough, and by including sample code and reasonable (not perfect) problem description "we" were able to help you. In general, a good question contains the fewest number of steps to re-create the problem. OR, if you're trying to manipulate data,
a. small sample input,
b. sample output from that same input
c. your "best" code you have tried
d. your current output
e. your thoughts about why it is not working
AND comments to indicate generally other things you have tried.
I'd like to use emacs in some kind of batch mode to just render a file with syntax highlighting and exit. Specifically, I want to dump the fontified buffer with ANSI escape codes so that it shows up reasonably syntax-highlighted on my terminal. Is there any way to do this?
The ansi-lpr.el library seems to be kind of along the lines of what I want, but the output isn't colorified. I can't figure out how to get over that final hurdle — there are a lot of modules to digest ANSI escape codes into Emacs text properties (e.g. ansi-color.el) but I haven't found anything that does the reverse. If anyone can point me to something that does, I think I can piece together the rest.
Alternatively, I've seen some hacky approaches like this answer (using script and capturing the output) but in my experiments that approach has seemed unlikely to be fruitful — you get tons of undesirable control sequences mixed in with the highlighted text.
The overarching motivation here is to use emacs in a $LESSOPEN pipe to get syntax highlighting when I page files. In case you're going to say it, I've tried and "just page files in Emacs" is not acceptable for me.
I'm glad to announce a new package, e2ansi, that (hopefully) does what you asked for.
The package provides a command-line tool e2ansi-cat that starts Emacs in batch mode, opens files, syntax highlight them (using font-lock), and creates ANSI-colored versions of the syntax highlighted files.
You can integrate this into less by setting the following variables to, for example:
export "LESSOPEN=|emacs --batch -Q -l ~/.emacs -l bin/e2ansi-cat %s"
export "LESS=-R"
export MORE=$LESS
The end result looks like the following:
You can vary the colors and attributes like bold, underline, and
italics by using a suitable Emacs theme.
The e2ansi package is located at https://github.com/Lindydancer/e2ansi
Personal note
I would like to thank you for posting this question, it directly inspired me to write e2ansi.
I am using emacs 23 on two computers.
On both, dpkg -s emacs outputs the following version number.
However one has window.el and the other not. This make some function such as split-window behave differently. The help page of this function on the computer that apparently has not window.el installed reads that it comes from C source code instead.
Where does this difference comes from?
I prefer the behaviour of the one that says that split-window comes from window.el: it allows to specify the SIDE when splitting window and provide additional function such as window-resize.
I suppose this is the most recent one but I do not know how to check it nor how to upgrade the other to this state.
Library window.el is as old as the hills. Perhaps you meant that one of your Emacs installlations has window.elc but not window.el?
More likely, you are referring only to function split-window. Yes, it used to be a built-in function (i.e., defined in C), and now it is defined in window.el (which file exists also for the older Emacs versions where that function is a built-in).
FYI, lots of window and buffer-display stuff was changed around the same time as split-window was rewritten in Lisp. Lots of behaviors changed, in minor or major ways.
What is not at all clear is what the problem is that you are reporting. You ask, "Where does this difference comes from? How to fix it?" I've explained a bit about the difference. As for how to fix it -- what is the "it" that needs fixing, and what would the fixed behavior be like?
IOW, your question is, so far, unanswerable. If you specify things more exactly, perhaps we can help more.
I'm not certain what's going on with your debian packages, but if memory serves the readable .el(.gz) files are not supplied in the basic package, but in a separate package. This is because all you strictly need is the byte-compiled .elc files, so they can reduce the base package filesize by omitting them (at the expense of enabling you to read the elisp code).
Is M-x load-library RET window RET successful?
Note that Emacs 24 is the current stable version. You might want to upgrade.
Edit:
M-x emacs-version tells you which version of Emacs you're running, which will always give you a definitive answer.
(And if the versions are identical, then run emacs -Q to eliminate and site- and user-specific config files from the picture, as those are always a likely culprit for differing behaviours.)
Python offers an interactive interpreter allowing the evaluation of little code snippets by submitting a couple of lines of code to the console. I was wondering if a tool with similar functionality (e.g. including a history accessible with the arrow keys) also exists for Perl?
There seem to be all kinds of solutions out there, but I can't seem to find any good recommendations. I.e. lots of tools are mentioned, but I'm interested in which tools people actually use and why. So, do you have any good recommendations, excluding the standard perl debugging (perl -d -e 1)?
Here are some interesting pages I've had a look at:
a question in the official Perl FAQ
another Stackoverflow question, where the answer mostly is the perl debugger and several links are broken
Perl Console
Perl Shell
perl -d -e 1
Is perfectly suitable, I've been using it for years and years. But if you just can't,
then you can check out Devel::REPL
If your problem with perl -d -e 1 is that it lacks command line history, then you should install Term::ReadLine::Perl which the debugger will use when installed.
Even though this question has plenty of answers, I'll add my two cents on the topic. My approach to the problem is easy if you are a ViM user, but I guess it can be done from other editors as well:
Open your ViM, and type your code. You don't need to save it on any file.
:w !perl for evaluation (:w !COMMAND pipes the buffer to the process obtained by running COMMAND. In this case the mighty perl interpreter!)
Take a look at the output
This approach is good for any interpreted language, not just for Perl.
In the case of Perl it is extremely convenient when you are writing your own modules, since in my experience the perl interpreter will refuse to reload a module (even when loading was attempted and failed). On the minus side, you will loose all your context every time, so if you are doing some heavy or slow operation, you need to save some intermediate results (whilst the perl console approach preserves the previously computed data).
If you just need the evaluation of an expression - which is the other use case for a perl console program - another good alternative is seeing the evaluation out of a perl -e command. It's fast to launch, but you have to deal with escaping (for this thing the $'...' syntax of Bash does the job pretty well.
Just use to get history and arrows:
rlwrap perl -de1
There's a small nuance that's been bugging me for a while, namely that I frequently type #inclued instead of #include. If it wasn't obvious, I program a lot of C and C++. That typo has wrecked countless builds and consumed time that would have been better spent drinking coffee or surfing stackoverflow. Surely emacs can be helpful and rectify my mistakes as I type (in cc-mode only, of course). But how?
Googling and searching stackoverflow didn't provide any answers.
You could use this in abbrev-mode: After you entered #inclued, do C-x a i g include RET, and from then on, every time you type #inclued, it will be changed to #include automatically. If you want that abbrev to be local to a mode, use C-x a i l instead of C-x a i g. Also, you can edit your abbrevs with M-x edit-abbrevs.
A nicier and more global solution than abbrevs (because you can't predict all the typos you'll make) is to use flymake (which comes with emacs distribution).
http://flymake.sourceforge.net/
Flymake checks your source code behind the scene while you're still typing your code into the buffer. It highlights what's wrong with your code (that is : what gcc tells is wrong).
Running gcc in the background does not use more CPU than your antivirus bloatware. Moreover, if you have 2 or more cores, gcc can take advantage of parallelization. It only checks the syntax, not compiling anything.
if you're interested in something a bit different, you could write all your little piece into snippets, using the YAsnippet package, then you could type something like #in, hit TAB, and it will expand into... whatever you want.
Sounds like flymake is exactly what your after. It runs a compiler in the background, and will hightlight errors, as you type.
I was going to suggest that this could be a slightly odd application for flyspell, but danlei's answer looks better.