Emacs noob (sort of) here. I'm getting unexpected behavior from the goto-line command. The wording of the manual seems imprecise. I'm assuming the phrase "move to line LINE..." means "set point to line LINE". So my interpretation of the manual's entry on goto-line is that it is supposed to set mark at the current location of point and then move point to the line specified by the argument you enter. Is this correct? Because what is happening instead is that, yes, it does set mark at the current location successfully (which I don't care about since I can set mark myself very easily if I want to) but then it sets point at the beginning of the buffer instead of where I specified. Is this what goto-line is supposed to do? Am I misunderstanding either the manual or the purpose of this command?
The activity I'm engaged in is reading the Emacs Lisp manual and evaluating expressions in it. I have line numbers turned on in the left margin, and I would like to be able to simply do M-g g LINE-NUMBER, C-e, C-x C-e and see how the form evaluates. But instead, I have to do this klutzy routine of subtracting current point line number from target line number and then doing M-DIFFERENCE C-n. Or I just C-nnnnnnn...or C-pppppp... or even use the mouse, which is the type of slow and clumsy navigation I'm trying to get away from by using Emacs.
Unfortunately, goto-line in an Info buffer is working on the source rather than the rendered outcome.
(If you visit the elisp.info file, you'll see where the real line numbers are coming from.)
Unfortunately that doesn't help you (or anyone, I suspect), but it does explain why the feature doesn't work as expected.
You could M-x report-emacs-bug and propose that this be changed to work the way people would expect it to work.
If you're using Emacs 26 and its native display-line-numbers-mode then you can customize the display-line-numbers-widen option to prevent line numbers changing when buffers are narrowed, in which case you'll be able to use the number you can see with goto-line.
Related
In relationship to this thread, this is also what i am kind of trying to do but i have had a bit more leeway in this.
My problem is i am currently working on a defining program (for my ti-89 titanium) to write out the definitions of variables. However, considering i had indefinite amounts of variables to add, i thought using the define function over and over again would waste memory and processing power. So my thinking was Save the variable to another variable to be defined in a later portion of the program.
prompt x
lbl x_d_r
x_d_r->q:Goto def
lbl def
define expr(q)[1]=x
where x_d_r has no assigned value. So the program was supposed to use the defined string as a list value to be x. However the obvious error came about.
So i played around on the home screen and program screen for a bit and came across entry(1) and ans(1). See back on the ti-83 (or 84) i could basically go (If i remember correctly)
disp q*1
x->ans(1)
However ans(1) on a ti-89 titanium is based upon the last answer submitted to the homescreen. Even then, ans(1) or entry(1) gets replaced in the program by just that. Lucky me, i found a way to avoid this.
Prgm
expr(char(120)&char(22)&char(97)&char(110)&char(115)&char(40)&char(49)&char(41))
EndPrgm
For those that do not know, this is simply expressing x->ans(1) which is a way for the code to transmit ans(1) within a program without removing the code to say so.
But it still does not work as a value needs to be sent to the home screen in order for it to record properly. This is one of those advantages that the ti-84 or ti-83 i wish it still had on the titanium. So i have spent some time searching for ways how i can display values of q to the home screen from within a program.
So far i learned that functions when used straight from the home screen return the value of q to the same place. However i have no way of implementing this in an actual program as the function does not wish to transmit the value to the home screen, and its rather useless within the program.
Secondly i have found this website which details methods of such ways to return values to the homescreen. While method 1 seems to hold promise, i do not seem to have any way of accessing that folder/program. Most likely because it is one that he made and has not shared its location on the pdf. I do like the expr("q"&":stop"), but q is not evaluated out so maybe i would have to rework it somehow.
While this was happening, i thought some other ideas could be using the paste key within a program but i have no idea how to implement stuff found from getkey let alone how the second and grab buttons factor in.
Or i could somehow have the ans(1) look to someplace else other than the home screen. Preferably to the i/0 screen but maybe to some other list or data matrix.
Anybody have any ideas on how to relay a value to the homescreen be it through function, pasting or something, and have the program i defined earlier define it as a value?
UPDATE+1
Ok i am beginning to question if maybe i am making it more complex than it needs to be...
After all, i am only going for just x->x_d_r[1], which is already defined elsewhere. So does it beat x->q:Goto def
Lbl def
Define expr(q)=x
(Or something like that which calls to a history recording program to define values?)
in terms of processing speed and memory count?
Got it. See here for what i was really trying to do.
So as an explanation of what the main problem was again, i wanted to be able to post a string value of q to be defined by another value of x.
The expr( function is quite a powerful tool on the ti-89 and like the person in that other forum, underestimated it. See what the person was trying to do was
InputStr "Function:",f(x)
expr(f)→f(x)
And was later answered by reworking it as
InputStr "function", n
expr(n & "->f(x)")
The expression tool just simply expresses what is in the parentheses. So during break periods in school today, i reworked in my head thinking "What if i tried rewriting the parenthesis out so it reads Expr("x->"&String(q))?
Lo-and-behold it works. Tested it with the fuller version of define to get
td()
Prgm
Prompt X
x_d_r->q
expr("x->"&string(q)&"[1]")
Disp x_d_r[1]
Delvar x_d_r
EndPrgm
Tried, tested and true. Works all the way. See what i think is happening is that anything that is not within the quotes is evaluated immediately in an expression while the the quoted objects are simply expressed and added later in response to the "&" key. Furthermore it makes sense if i was to describe it more with english; "Express x to be stored into the string of q's respective table".
While for variables sake i would have to look into ways to make x_d_r local only to the program without compensating the fact that the x_d_r portion is not considered a store value when executing x_d_r->q. But knowing what i know now i could probably do
expr("q"+"x_d_r"&->a)
expr("x->"&string(a)-"q"&"[1]")
In order to bypass that problem.
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 using Fortran for my research and sometimes, for debugging purposes, someone will insert in the code something like this:
write(*,*) 'Variable x:', varx
The problem is that sometimes it happens that we forget to remove that statement from the code and it becomes difficult to find where it is being printed. I usually can get a good idea where it is by the name 'Variable x' but it sometimes happens that that information might no be present and I just see random numbers showing up.
One can imagine that doing a grep for write(*,*) is basically useless so I was wondering if there is an efficient way of finding my culprit, like forcing every call of write(*,*) to print a file and line number, or tracking stdout.
Thank you.
Intel's Fortran preprocessor defines a number of macros, such as __file__ and __line__ which will be replaced by, respectively, the file name (as a string) and line number (as an integer) when the pre-processor runs. For more details consult the documentation.
GFortran offers similar facilities, consult the documentation.
Perhaps your compiler offers similar capabilities.
As has been previously implied, there's no Fortran--although there may be a compiler approach---way to change the behaviour of the write statement as you want. However, as your problem is more to do with handling (unintentionally produced) bad code there are options.
If you can't easily find an unwanted write(*,*) in your code that suggests that you have many legitimate such statements. One solution is to reduce the count:
use an explicit format, rather than list-directed output (* as the format);
instead of * as the output unit, use output_unit from the intrinsic module iso_fortran_env.
[Having an explicit format for "proper" output is a good idea, anyway.]
If that fails, use your version control system to compare an old "good" version against the new "bad" version. Perhaps even have your version control system flag/block commits with new write(*,*)s.
And if all that still doesn't help, then the pre-processor macros previously mentioned could be a final resort.
(eolp) works only for "hard" line wraps, and I'd like to be able to check whether I'm at the end of screen line. I'd think that looking at the source code of end-of-visual-line would help, but it didn't: it uses a built-in function vertical-motion, and digging into C sources is not something I'd prefer to do. (Of course, I could save point position, go to end-of-visual-line, compare the point position with the saved one, but is there a better way?)
This would be quite useful, especially that I could hit C-t at the end of visual line and not be surprised;).
There may be a better way, but I think your idea to save point position and compare with point at the end of the visual line is reasonable. Lots of things that behave like pure functions in Emacs actually work by changing state like this and restoring it on exit. The save-excursion special form is designed for this kind of pattern:
(defun end-of-visual-line-p ()
(= (point)
(save-excursion
(end-of-visual-line)
(point))))
I am working on a code parser that is built on Rexx. It is a single file script with around 5000 lines of code or more. I've never worked on Rexx before. Adding to that, the readability issue is making my life even tougher. So,
Are there are any tools to debug and understand Rexx code?
Use the trace statement? The most simple mode of tracing is 'A'. This causes each instruction to be displayed before it is executed. Your instruction is displayed with a line number and the three characters - preceding it, so that you can identify it as a line in your script.
Wikipedia has a pretty good article on Rexx, which should help you understand Rexx syntax and program structure. And almost any Rexx book will apply to your environment, because Rexx is extremely cross-system (similar in that way to the younger Perl and Python languages). There aren't a lot of online books, because almost everything written about Rexx was written before the web existed, but the reference manual for the Regina implementation is, and it's a particularly good reference work.
The date on this question is old, but I'll share what I have found helpful for the next person who pulls this up.
Already mentioned is the TRACE option. I've found this can be overwhelming in a small set of code let alone 5,000 lines or more.Here are some options I've found useful:
Use an "if" to turn the trace on only in certain situations.if counter < 25 then trace "A" Be sure to turn the trace off with:else trace "OFF"
Use say followed by pull. What is said will stay on the screen until you hit enter.
Add a subroutine:
AskIt:
parse pull comment
say comment
say 'enter "X" to exit program'
pull continueif Continue \= "X" then returnexit
This is invoked with call AskIt "In routine that loops, counter=" counter and would display: In routine that loops counter='##enter "X" to exit programThe tester chooses to return to the code by hitting enter or exit the program with X to edit the source.Temporarily inserting return on the line following the routine label will allow you to run the code uninterrupted without removing all the calls.
I have written an edit macro for z/OS which inserts a say *routine name* after every routine label. It inserts the code with a /* comment */ containing a readily identified phrase to simplify cleanup.The audience for this would be small, so I'll not include the code here.
Hope this helps someone.