I'm trying to get ride of all padlines added during the Org-mode tangle for every kind of code block. So I write this on the top of my file :
#+PROPERTY: header-args :padline no
But the padlines stay there after the tangle.
Next I try this :
#+PROPERTY: header-args:sh :padline no
Guess what... it work only for sh code block.
If anyone can help me....
Thanks !
So, I finally found the solution. This was due to an out-of-date version of org-mode (I was using the version 8.2.10). In this version the padline header-args does not work (or not implemented I haven't check it). So, just update the org version (now I'm using 9.1.2) and all will be fine.
Related
I have Emacs on a Kubuntu 15.04 OS and I have a problem in showing the selected region; if I run emacs in the terminal windows with -nw option, I can set marks and I see the selected region highlighted; but if emacs starts in a window, the selected region is not highlighted, though it is still selected (ctrl+w cuts that part). Note that transient-mark-mode doesn't affect this behaviour, whether it is enabled or not.
Do you see this behavior when you start Emacs using emacs -Q (i.e., without an init file)? If not, then recursively bisect your init file until you locate the culprit code. You can do use command comment-region to comment out the region (with C-u it uncomments). Comment out 1/2, then 3/4, 7/8,... until you find the culprit.
If you see a problem using emacs -Q then give a step-by-step recipe to reproduce it.
If not, and if you narrow your init file to locate the problem but you still need more help at that point, report as much as you have found out, specifically. Again, step-by-step specifics help.
Ok, so thanks to Drew I finally managed to resolve this issue!
I had a file with path: /etc/X11/Xresources/x11-common
With the following content:
! $Id$
! load color-specific resources for clients that have them
#ifdef COLOR
*customization: -color
#endif
! make Xaw (Athena widget set) clients understand the delete key
! this causes problems with some non-Xaw apps, use with care
! *Text.translations: #override ~Shift ~Meta <Key>Delete: delete-next-character()
What I just did was moving that file away, running xrdb with an empty input, and everything went fine!
Now I just need to figure out what the content of that file was and what to do if I need to put it back where it was.
Thanks a lot for your precious help, Drew!
when I try to find help topic on a function C-h a , the content will not directly show up.
instead "Type "q" to delete this frame." will occur in the mini-buffer, then nothing show up. but if I type a second time, the content will show up
this is the case for the moment, not sure what configuration is wrong.
It's been a year and a half since you posed the question, and still no answer. Here's my (partial) answer.
As always with such a problem, state your Emacs version and a recipe to reproduce the problem, starting from emacs -Q (no init file). If you cannot repro the problem from emacs -Q then bisect your init file recursively until you find the culprit code.
If you can repro the problem from emacs -Q then people here will be able to help you understand whether it is the expected behavior or not. If not, M-x report-emacs-bug is in order. Even if you are not sure whether something is a bug, you can use M-x report-emacs-bug -- Emacs Dev will let you know. But again, a bug report should preferably include a recipe starting from emacs -Q.
I started using Emacs (ESS) as a default R editor (yes, #Dirk, as you've said, I want ESS), and I must admit it's by far the best R editor I've been using so far. However, I cannot manage to get an output of help() function up to web browser. It keeps displaying help page in a separate R buffer, even if options(help_type = "html", browser = "firefox") are set.
How can I get help back to browser, while using Emacs/ESS?
I can reproduce this under Linux: If I run R from the terminal, setting options(htmlhelp=TRUE) brings up help in a browser, but it fails from ESS. However,
help("plot",htmlhelp=getOption("htmlhelp"))
works -- help opens in Firefox for me. I think that's an anomalous behavior -- htmlhelp=getOption("htmlhelp") is a default argument for help (see ?help). Could it be a bug?.. A possible workaround is to invoke help via help("plot",htmlhelp=T) directly, or write a wrapper like myhelp <- function(x) help(x,htmlhelp=TRUE).
EDIT: A possible solution: put this into your .emacs
(setq inferior-ess-r-help-command "help(\"%s\", htmlhelp=TRUE)\n")
as per https://stat.ethz.ch/pipermail/ess-debian/2009-October/000093.html. This refers to ESS 5.5; the current one in Ubuntu repositories is 5.4, so I can't test the fix w/o upgrading ESS.
EDIT2: I upgraded to the latest R/ESS as per Dirk's suggestion, and did the following, after launching R/ESS: M-x customize-variable inferior-ess-r-help-command and replaced help_type=text with help_type=html. That fixed things (at least for version 2.10.1/ESS 5.8).
I'm having a problem with an Emacs lisp package that I pulled down from the ubuntu distribution. The package is JDEE, and it complains of Args out of range: "63", 0, 4 in the mini buffer and the *Messages* buffer whenever I open a file. This bug appears to have been reported last September but no action has been taken. I'm not an emacs newbie, having written some Elisp code myself, but I've never attempted to debug anything like this. I would like to stop the file load in a debugger when this error happens to at least get an idea of where the problem is coming from. I've read section 18.1.1 of the Elisp manual on "Entering the debugger on error" but trying to load the file after playing with various combinations of values for debug-on-error, debug-ignored-errors, and debug-on-signal appears to have no effect. Has anybody got any suggestions for my next step?
If debug-on-error isn't working, I'd start with the source itself. Find the keybinding/event that is causing the problem, and locate the function.
C-h k <keystrokes>
M-x find-function <function-name-from-above>
Now, once you are at the source
M-x edebug-defun
And the next time you hit the key, you should be able to step through the program. At that point, you can see which portion causes an error - and drill down that way.
You can also try setting the variable 'stack-trace-on-error to see if you can find the culprit (though 'debug-on-error usually works for me, not sure why it doesn't for you).
As a last resort (if edebug-defun doesn't work), you can redefine the routine with a call to (debug) in it, sort of does the same.
I suppose JDEE is somehow inhibiting debug-on-error. Perhaps grep through its files for the error message "Args out of range". While debugging, make sure to load the uncompiled .el files, not the byte-compiled .elc files (you will notice it in the debugger if you are running byte-compiled code) by entering commands like (load "foo.el") instead of (load "foo").
I got the same error when using find-grep after accidentally redefining (current-time-string) in one of my own scripts.
Using the M-x edebug-defun tip posted above I managed to find the issue when I stepped through the code giving the error seeing the call to (current-time-string).
Not sure how helpful this is in your case.
This is a bit difficult to explain, so please bear with me.
I am running emacs 23.0.60.2 (from CVS) in order to have truetype support. (in case anyone wonders why I'm running the bleeding edge). I'm experiencing some oddness in navigation within documents with this version that I want to have STOP.
When a window is narrow enough that a long line wraps, it used to be that navigating down one line in the text would move the cursor to the next literal line in the file at the same offset into the line. Now, however, the cursor is moved to the next logical line in the window -- which is the continuation of the current line -- at the same relative offset from the window edge. Basically, before it was emacs-like and now it's notepad-like. I don't want notepad-like behaviour.
Does anyone know how to turn this off? Bonus points if you know how to turn it off in .emacs in such a way as to have my .emacs continue to work with emacs 21-22 as well :)
Thanks!
Try to put
(setq line-move-visual nil)
in the .emacs file.
I can't answer the main question, but the bonus question is easy:
(if (>= emacs-major-version 23)
... )
Unfortunately, if you want to be more specific than that (e.g., you want exactly version 23.0.60.2) you'll have to parse emacs-version, which might look something like
"GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.14.3) of 2008-10-13 on rothera, modified by Debian"
Also, if you're running a Debian-based distro, look at the emacs-snapshot-gtk package—the edge might bleed a little less.