[PATCH] org-eldoc: Fix compatibility with eldoc 1.11 and Emacs 27
* contrib/lisp/org-eldoc.el (org-eldoc-documentation-function): Check before invoking elisp eldoc functions from Emacs 28. The previous check assumed that the presence of eldoc 1.11 bindings implied elisp-mode bindings that come with Emacs>=28, but eldoc 1.11 is available on GNU Elpa so the assumption doesn't always hold. TINYCHANGE --- contrib/lisp/org-eldoc.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/contrib/lisp/org-eldoc.el b/contrib/lisp/org-eldoc.el index 7a6885160..550f857be 100644 --- a/contrib/lisp/org-eldoc.el +++ b/contrib/lisp/org-eldoc.el @@ -144,7 +144,9 @@ (cond ((or (string= lang "emacs-lisp") (string= lang "elisp")) - (cond ((boundp 'eldoc-documentation-functions) ; Emacs>=28 + (cond ((and (boundp 'eldoc-documentation-functions) ; Emacs>=28 + (fboundp 'elisp-eldoc-var-docstring) + (fboundp 'elisp-eldoc-funcall)) (let ((eldoc-documentation-functions '(elisp-eldoc-var-docstring elisp-eldoc-funcall))) (eldoc-print-current-symbol-info))) -- 2.31.1.295.g9ea45b61b8-goog
[O] Why does the clocking format in the mode line string look like this?
Hey, list! When I clock into a task, I get a nice notification in my mode line. Except there's always been this one thing that confuses me. With an effort property on the task, the mode line looks like this: [0:00/0:30] (the task headline) But with no effort property set, the mode line looks like this: [0:00 (the task headline)] Note that the headline is outside the square brackets in the first case, and inside in the second case. Does that look inconsistent to anybody else? I would have expected the no-effort-property case to look like this: [0:00] (the task headline) The next email contains a patch I've been using to make the two consistent, in case this makes sense to you all. FYI, I signed the FSF copyright paperwork a long time ago. Cheers! Trevor
[O] [PATCH] Place `org-clock-heading' outside clock time.
* org-clock.el (org-clock-get-clock-string): When `org-clock-effort' is nil, arrange the format string components separately, similar to how they are arranged when o-c-e is not-nil. --- lisp/org-clock.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index c72bed4..a7c2a0a 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -682,7 +682,7 @@ If not, show simply the clocked time like 01:50." 'face 'org-mode-line-clock))) (format clockstr work-done-str)) (org-propertize (concat "[" (org-minutes-to-clocksum-string clocked-time) - (format " (%s)" org-clock-heading) "]") + "]" (format " (%s)" org-clock-heading)) 'face 'org-mode-line-clock (defun org-clock-get-last-clock-out-time () -- 2.8.2
[O] How do you use `pre-scheduled' deadline skipping with repeaters?
I really like to use `pre-scheduled' as the value of `org-agenda-skip-deadline-prewarning-if-scheduled'. Quoting the manual, this can be used in a workflow where the first showing of the deadline will trigger you to schedule it, and then you don't want to be reminded of it because you will take care of it on the day when scheduled. I started applying this to tasks with repeating deadlines. So, for instance, I have the following in my agenda right now: ** REPEAT oil change :drive: SCHEDULED: 2014-12-23 Tue 09:00 DEADLINE: 2014-12-31 Wed .+6m When I mark this done, the deadline repeater updates as I expect. But the scheduling information stays there and I have to manually unschedule the task to get it out of my agenda. I started looking into writing a function to unschedule after a repeat, but I'm having difficulty figuring out where to hook into `org-todo'. Or do I want to hook into `org-auto-repeat-maybe'? So, yeah. Do others use this `pre-scheduled' workflow for repeating deadlines? If so, is there an obvious solution to this little nuisance that I'm not seeing? -- Trevor Murphy, ASA, MAAA GnuPG Key: 0x83881C0A
[O] What is the deal with `org-agenda-skip-deadline-prewarning-if-scheduled', 'pre-scheduled, and specific deadline lead times?
Hi, list! tl;dr given the setting alluded to in the subject line, I'm dissatisfied with the behavior of the following example (scheduling and deadline timestrings use today as pseudocode): * TODO check deadline skipping with specific lead time and 'pre-scheduled DEADLINE: today+2d -3d SCHEDULED: today+1d I would like to hack the code to change the behavior, but I'm concerned about breaking a zillion other things at the same time. Comments and suggestions welcome. Still with me? Longer description below: The documentation says (http://orgmode.org/manual/Deadlines-and-scheduling.html): You can specify a different lead time for warnings for specific deadlines using the following syntax. Here is an example with a warning period of 5 days =DEADLINE: 2004-02-29 Sun -5d=. This warning is deactivated if the task gets scheduled and you set =org-agenda-skip-deadline-prewarning-if-scheduled= to =t=. I have o-a-s-d-p-i-s set to 'pre-scheduled. Suppose today is Wednesday, 2014-10-08, and I create an agenda file example.org with the following contents: * TODO check deadline skipping with specific lead time DEADLINE: 2014-10-10 Fri SCHEDULED: 2014-10-09 Thu Then the deadline warning does not appear in today's agenda. This is what I want, and I think this is what I should expect with the 'pre-scheduled setting. However, if I use the following contents instead (note the specified warning period): * TODO check deadline skipping with specific lead time DEADLINE: 2014-10-10 Fri -3d SCHEDULED: 2014-10-09 Thu The deadline warning *reappears* in today's agenda. I think this is a bug. I think I've ruled out the personal-configuration sources of the behavior, and instead traced it to the following code in `org-agenda-get-deadlines': (setq wdays (if suppress-prewarning (let ((org-deadline-warning-days suppress-prewarning)) (org-get-wdays s)) (org-get-wdays s)) ...) In `org-agenda-get-deadlines', with o-a-s-d-p-i-s set to 'pre-scheduled, the code stores the gap between scheduling and deadline information in the local variable `suppress-prewarning'. As you can see in the citation above, o-a-g-d then let-binds the user option `org-deadline-warning-days' to match and calls `org-get-wdays' to figure out the appropriate amount of warning-day lead time. But! Check out what `org-get-wdays' does with specific warning periods in the deadline timestring: (cond ... ((string-match -\\([0-9]+\\)\\([hdwmy]\\)\\(\\'\\|\\| \\) ts) ;; lead time is specified. (floor (* (string-to-number (match-string 1 ts)) (cdr (assoc (match-string 2 ts) '((d . 1)(w . 7) (m . 30.4) (y . 365.25) (h . 0.041667))) `org-get-wdays' never checks `org-deadline-warning-days' in this branch, and so never gets a chance to see the `suppress-prewarning' information passed in from `org-agenda-get-deadlines'. At this point I'm stuck. I'd like to hack into `org-get-wdays' some code that says Yes, there's a specific warning period. However, there's also some prewarning suppression going on, so we should take that into consideration. But I'd like to avoid changing the existing behavior for when there is no prewarning suppression and the specific warning period just happens to be longer than the user option `org-deadline-warning-days'. If you're still reading, thanks. Please let me know if you have any suggestions, questions, or comments about what I'm trying to do. -- Trevor Murphy GnuPG Key: 0x83881C0A
Re: [O] TODO keyword highlighting for headings with properties broken
Bruno Bigras bigras.br...@gmail.com writes: It would be nice if the ELPA package could be updated faster than that in cases like this. I guess a couple of people must now have a broken org-mode unless they switched to git like I did. Chiming in with an alternative that I was pleased to discover - https://elpa.gnu.org/packages/org.html. For those who want an easy way to roll back to the 8/25 snapshot. -- Trevor Murphy GnuPG Key: 0x83881C0A
[O] [PATCH] New user option for org-agenda-show-and-scroll-up
Hi, all. The current behavior of `org-agenda-show-and-scroll-up' (SPC from the Agenda) reveals drawers and logbooks unless the user passes a prefix argument. This doesn't work for my flow - I prefer the drawers stay hidden all the time, unless I prefix the command. My workflow may be unique to me. Thus far I've been patching the code locally. For fun I'm sharing my patch with the list, in case somebody else finds it worthwhile. I've added a defcustom `org-agenda-show-and-scroll-up-show-drawers'. It defaults to t, and this gives the current behavior. Customizing it to nil gives the alternate behavior I prefer. My not-so-secret hope is that this patch is suitable for applying to master. Please let me know if that's the case, or if there are some changes I can make that would get it there. I'm fine signing copyright assignment papers. Thanks for taking a look! -- Trevor Murphy GnuPG Key: 0x83881C0A
[O] [PATCH] org-agenda: Customize agenda-show's drawer hide/show behavior.
* lisp/org-agenda.el (org-agenda-show-and-scroll-up-show-drawers): New user option. Controls whether `org-agenda-show-and-scroll-up' hides or shows drawers without a prefix arg. Pre-patch behavior corresponds to setting this to t (the default). * lisp/org-agenda.el (org-agenda-show-and-scroll-up): Compute hide/show behavior based on user option and prefix arg. --- lisp/org-agenda.el | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index f24e1f6..e556a4a 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -135,6 +135,14 @@ addresses the separator between the current and the previous block. (character) (string))) +(defcustom org-agenda-show-and-scroll-up-show-drawers t + Non-nil means show drawers by default when displaying the item at point. +Set this to nil to reverse the behavior of +`org-agenda-show-and-scroll-up' with respect to a +\\[universal-argument] prefix. + :group 'org-agenda + :type 'boolean) + (defgroup org-agenda-export nil Options concerning exporting agenda views in Org-mode. :tag Org Agenda Export @@ -8603,16 +8611,20 @@ if it was hidden in the outline. When called repeatedly, scroll the window that is displaying the buffer. With a \\[universal-argument] prefix, use `org-show-entry' instead of `show-subtree' to display the item, so that drawers and logbooks stay -folded. +folded. Reverse this behavior with user option +`org-agenda-show-and-scroll-up-show-drawers'. (interactive P) - (let ((win (selected-window))) + (let ((win (selected-window)) +(fold (if org-agenda-show-and-scroll-up-show-drawers + arg +(not arg (if (and (window-live-p org-agenda-show-window) (eq this-command last-command)) (progn (select-window org-agenda-show-window) (ignore-errors (scroll-up))) (org-agenda-goto t) - (if arg (org-show-entry) (show-subtree)) + (if fold (org-show-entry) (show-subtree)) (setq org-agenda-show-window (selected-window))) (select-window win))) -- 2.0.1
[O] Bug: Commit cece23 'fix'-ed call to 'type' breaks my agenda sorting [8.2.7 (8.2.7-elpa @ /home/trevor/.emacs.d/elpa/org-20140613/)]
Hi, all! The commit named in the subject line is causing me grief. Specifically, the commit made three changes to the `org-cmp-ts' function: 1. Change the function signature to require the `type' argument. Doesn't cause me any issues. 2 3. Make two changes from (get-text-property 1 'type FOO) to (get-text-property 1 type FOO). These cause problems for me. Near as I can tell, get-text-property really is supposed to look up the `type' property of FOO (returning scheduled or deadline or w/e) so the function can check that against the restriction passed in through the argument. This commit has the function checking the `scheduled', `deadline', or other property of FOO based on the passed-in argument. In this case get-text-property always returns nil and the function never returns anything useful. Steps to reproduce: (setq org-agenda-sorting-strategy '((agenda deadline-up))) [pull up an agenda view with some deadline entries and some other stuff] (setq org-agenda-sorting-strategy '((agenda deadline-down))) [refresh the same agenda view] What I expect to see: Deadline entries flipping from top to bottom of the agenda view. What I actually see: No changes ... org-agenda-sorting-strategy doesn't appear to do anything. Is this affecting anybody else? Emacs : GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.10.7) of 2014-01-28 on var-lib-archbuild-extra-i686-juergen Package: Org-mode version 8.2.7 (8.2.7-elpa @ /home/trevor/.emacs.d/elpa/org-20140613/) -- Trevor Murphy GnuPG Key: 0x83881C0A
Re: [O] Get a list of tasks completed today
Loris Bennett loris.benn...@fu-berlin.de writes: #+begin_src emacs-lisp (add-to-list 'org-agenda-custom-commands '(. Completed today ((todo ((org-agenda-skip-function '(org-agenda-skip-entry-if 'notregexp (format-time-string CLOSED: \\[%Y-%m-%d) (org-agenda-sorting-strategy '(priority-down)) t) #+end_src However, more useful to me would be last week, so what approach should I take for that? I get pretty decent mileage out of this command (note that it's a tags search, not a todo keyword search.) (add-to-list 'org-agenda-custom-commands '(. Closed this week. tags CLOSED\-1w\ ((org-agenda-sorting-strategy '(priority-down) Though now I've got a related question. One thing I'd like to do is run a function over every item that was closed this past week. For sake of example, let's say I've added a property :mood: 5 to several closed items and I'd like to delete it (but only from the closed items; I'm not necessarily deleting the property globally.) To do this I tried pulling all the closed items, visiting them in turn, and calling (org-delete-property mood). But I got stuck pulling all the closed items, because `org-tags-view' and friends all build an agenda as a side effect. Is my best bet simply re-implementing the parts of `org-tags-view' that I need? Or is there a more common way to use the org machinery to work with items in lisp code? Thanks! -- Trevor Murphy GnuPG Key: 0x83881C0A
Re: [O] Get a list of tasks completed today
Boo, reflowed text or some nonsense. Let's see if this works better: (add-to-list 'org-agenda-custom-commands '(. Closed this week. tags CLOSED\-1w\ ((org-agenda-sorting-strategy '(priority-down) -- Trevor Murphy GnuPG Key: 0x83881C0A
[O] Can I ask Which day is it? when filtering org-agenda views?
As preface, I'm aware that I may have gone too far down the rabbit hole. I'm inserting many time grid lines (one per half hour) into my agenda views so I have a visual sense of my free / busy time. But I want time grid lines that have already passed to disappear, freeing up screen real estate for later lines. This was pretty easy. I customized `org-agenda-time-grid' to give me a line at every half-hour interval. Then I set `org-agenda-before-sorting-filter-function' to return nil for time grid lines where the time-of-day text property is in the past. In case that description isn't clear, I'm using (apologies for Gmail formatting): (defun my:org-agenda-before-sorting-filter-function (org-agenda-item) (unless (and (string= (nth 1 org-agenda-time-grid) (get-text-property 0 'txt org-agenda-item)) ( (get-text-property 0 'time-of-day org-agenda-item) (string-to-number (format-time-string %H%M org-agenda-item)) As an unanticipated side effect, my function also throws out time grid lines when I view tomorrow (and other days) in the agenda view. Is there an additional check I can throw into my function to only filter if the day of the time grid line is today? I tried the obvious (get-text-property 0 'day org-agenda-item) but it seems that the day text property isn't put into the item until /after/ the filter-function gets a chance to process it. Alternatively, if my attempted solution is brain-damaged please let me know a better way to manage the time grid lines. -- Trevor Murphy GnuPG Key: 0xCB06EAAF
Re: [O] Can I ask Which day is it? when filtering org-agenda views?
Nick Dokos ndo...@gmail.com writes: If I read the code correctly, the date of the item should be available to the function as the value of the dynamically bound variable date, in (month day year) form. So you should be able to compare that to today's date, obtained with (calendar-gregorian-from-absolute (org-today)) for example. Bah! That's what I get for training myself to ignore dynamic variables. Thank you, this is precisely the suggestion I was looking for. -- Trevor Murphy GnuPG Key: 0xCB06EAAF
Re: [O] [PATCH] Timestamps: Handle sub-10-min ranges when updating timestamps
Wow, thanks for parsing that, Nicolas. I didn't realize until just now that my git skills were so poor - I neglected the --cover-letter option, hence the utter lack of explanatory material. To answer your points: Nicolas Goaziou n.goaz...@gmail.com writes: Thanks for your patch. Would you mind providing a test-case for it? I'm not sure about the use of `org-get-compact-tod'. Schedule an event for today with a five-minute duration. E.g: * TODO test out bug in `org-schedule' SCHEDULED: 2013-08-07 Wed 17:00-17:05 Then hit C-c C-s (or however you have `org-schedule' bound). With the default setup, you'd expect to see the following prompt in the minibuffer: Date+time [2013-08-07]: 17:00+0:05 however what you'll get instead is: Date+time [2013-08-07]: 17:00+0:5 The latter is not a valid time spec. If you simply accept it, then at least on my install org reschedules the event to: SCHEDULED: 2013-08-07 Wed-17:00 Which is not what I intended. I'll add that you can get the same buggy behavior from any command that calls `org-time-stamp' on an already-timestamped event with 10 minute duration. -(if ( dm 0) (setq dm (+ dm 60) dh (1- dh))) +(when ( dm 0) (setq dm (+ dm 60) dh (1- dh))) Although I agree with this change, this is not strictly necessary here. Agree. I just couldn't resist. Since I'll likely be rewriting this patch anyways, I'll revert this back. (concat t1 + (number-to-string dh) -(if (/= 0 dm) (concat : (number-to-string dm +(when (/= 0 dm) (concat : +(if ( dm 10) +(concat 0 (number-to-string dm)) + (number-to-string dm) It would be better to use a 0-padded format string, e.g., (and (/= 0 dm) (format :%02d dm)) I tested that and it felt noticeably slower when I called `org-reschedule'. The extra `if' and `concat' did not feel slower. I didn't do explicit timings because of the subjective feel (also because I'm not really sure how to do those tests yet). That being said, I agree with you. If you prefer, I'll resubmit the patch without the if = when and using the format string. Let me know if you'd prefer I do some timing tests on format vs if/concat. -- Trevor Murphy GnuPG Key: 0xCB06EAAF
[O] [PATCH v2] Timestamps: Handle sub-10-min ranges when updating timestamps
* lisp/org.el (org-get-compact-tod): Always pad minutes to two places. TINYCHANGE --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index b1a2fa8..e13c2b8 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16077,7 +16077,7 @@ with the current time without prompting the user. (setq dh (- h2 h1) dm (- m2 m1)) (if ( dm 0) (setq dm (+ dm 60) dh (1- dh))) (concat t1 + (number-to-string dh) - (if (/= 0 dm) (concat : (number-to-string dm + (and (/= 0 dm) (format :%02d dm))) (defun org-time-stamp-inactive (optional arg) Insert an inactive time stamp. -- 1.8.3.4
[O] [PATCH] Timestamps: Handle sub-10-min ranges when updating timestamps
* lisp/org.el (org-get-compact-tod): Pad with 0 if # of minutes is less than 10. TINYCHANGE --- lisp/org.el | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 26e653f..89e023c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16088,9 +16088,12 @@ with the current time without prompting the user. (if (not t2) t1 (setq dh (- h2 h1) dm (- m2 m1)) - (if ( dm 0) (setq dm (+ dm 60) dh (1- dh))) + (when ( dm 0) (setq dm (+ dm 60) dh (1- dh))) (concat t1 + (number-to-string dh) - (if (/= 0 dm) (concat : (number-to-string dm + (when (/= 0 dm) (concat : +(if ( dm 10) +(concat 0 (number-to-string dm)) + (number-to-string dm) (defun org-time-stamp-inactive (optional arg) Insert an inactive time stamp. -- 1.8.3.4
[O] How can I set the maximum height of the other window created with org-agenda-follow-mode?
I like turning on agenda-follow-mode by default, but I don't like how it automatically uses up half the frame real estate when it shows the other window. Is there a way to make that other window take only 25% of the frame? Leaving the remainder for the actual agenda? I didn't find any mention in the documentation or the defcustoms in org.el and org-agenda.el. I realize this may be a more emacs-general question about controlling window configuration, but I'm also stuck on that front as well. Google searches about controlling emacs window size take me to SO answers for how to maximize the frame on startup. -- Trevor Murphy GnuPG Key: 0xCB06EAAF
Re: [O] How can I set the maximum height of the other window created with org-agenda-follow-mode?
Eric's correct. My original message must not have been clear enough, my bad. I did find org-agenda-window-frame-fractions, and I tried setting it to '(0.75 . 0.75). On a lark I also tried '(0.9 . 0.9). In those cases, the agenda window initially popped up at 75% and 90% of the frame, respectively (as expected), but as soon as I moved to an agenda item the follow window stole half the frame. -- Trevor Murphy GnuPG Key: 0xCB06EAAF
Re: [O] [PATCH] org.el: Don't flyspell check within source code blocks
Thanks, Bastien. Your suggestion has been working perfectly fine for me. Updated patch sent in reply to the first in the chain (I hope ... still trying to master git send-email). Trevor On Sat, May 25, 2013 at 11:52 AM, Bastien b...@gnu.org wrote: Hi Trevor, Trevor Murphy trevor.m.mur...@gmail.com writes: + (not (eq (org-element-type (org-element-at-point)) 'src-block) I think `org-in-src-block-p', while a bit less reliable, will be faster, and reliable/fast enough for this use-case. Let's see what others think/test. Thanks, -- Bastien
[O] [PATCH] org.el: Don't flyspell check within source code blocks
Hi, list. I recently started using flyspell, but I wasn't pleased with the spell checking in my source code blocks. After digging a bit for a solution, I found a post to the list with a nice solution[0]. However, it seems no patch was ever submitted. So, here goes. If there's a deeper reason this part of the code was never changed, please enlighten me. I didn't see any further mailing list discussion, so I assumed it was still fair game. Thanks, Trevor [0]: http://lists.gnu.org/archive/html/emacs-orgmode/2012-12/msg00764.html
[O] [PATCH] org.el: Don't flyspell check within source code blocks
* lisp/org.el (org-mode-flyspell-verify): Check if `org-element-at-point' is of type `src-block', and don't flyspell if that's the case. TINYCHANGE --- lisp/org.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 94078f9..81428f5 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -23596,7 +23596,8 @@ To get rid of the restriction, use \\[org-agenda-remove-restriction-lock]. (not (member-ignore-case word (org-get-export-keywords))) (not (member-ignore-case word (mapcar 'car org-element-block-name-alist))) -(not (member-ignore-case word '(BEGIN END ATTR)) +(not (member-ignore-case word '(BEGIN END ATTR))) +(not (not (eq (org-element-type (org-element-at-point)) 'src-block)) (defun org-remove-flyspell-overlays-in (beg end) Remove flyspell overlays in region. -- 1.8.2.3
Re: [O] [PATCH] org.el: Don't flyspell check within source code blocks
Ack, what? Please disregard, I slipped a double negative in somehow. On Sat, May 25, 2013 at 3:17 AM, Trevor Murphy trevor.m.mur...@gmail.comwrote: * lisp/org.el (org-mode-flyspell-verify): Check if `org-element-at-point' is of type `src-block', and don't flyspell if that's the case. TINYCHANGE --- lisp/org.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 94078f9..81428f5 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -23596,7 +23596,8 @@ To get rid of the restriction, use \\[org-agenda-remove-restriction-lock]. (not (member-ignore-case word (org-get-export-keywords))) (not (member-ignore-case word (mapcar 'car org-element-block-name-alist))) -(not (member-ignore-case word '(BEGIN END ATTR)) +(not (member-ignore-case word '(BEGIN END ATTR))) +(not (not (eq (org-element-type (org-element-at-point)) 'src-block)) (defun org-remove-flyspell-overlays-in (beg end) Remove flyspell overlays in region. -- 1.8.2.3
[O] [PATCH] Take 2 on org.el: Don't flyspell check within source code blocks
Very sorry about the email spam. This fixes the blindingly obvious double negative in my previous submission. Thanks, Trevor
[O] [PATCH] org.el: Don't flyspell check within source code blocks
* lisp/org.el (org-mode-flyspell-verify): Check if `org-element-at-point' is of type `src-block', and don't flyspell if that's the case. TINYCHANGE --- lisp/org.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 94078f9..ce48bb0 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -23596,7 +23596,8 @@ To get rid of the restriction, use \\[org-agenda-remove-restriction-lock]. (not (member-ignore-case word (org-get-export-keywords))) (not (member-ignore-case word (mapcar 'car org-element-block-name-alist))) -(not (member-ignore-case word '(BEGIN END ATTR)) +(not (member-ignore-case word '(BEGIN END ATTR))) +(not (eq (org-element-type (org-element-at-point)) 'src-block) (defun org-remove-flyspell-overlays-in (beg end) Remove flyspell overlays in region. -- 1.8.2.3
[O] Bug: Lisp error: (void-variable org-babel-tangle-lang-exts) when loading languages at startup
Hi, all. First bug report here, so please let me know if I can be more helpful / less verose. I didn't see this previously reported on the mailing list and I'm not yet familiar enough to patch it myself. After updating, I'm receiving the error in the subject line. For reference, I'm running Arch and am using the latest org from elpa. So: Emacs : GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.6.4) of 2013-03-18 on eric Package: Org-mode version 7.9.4 (7.9.4-elpa @ /home/trevor/.emacs.d/elpa/org-20130318/) To produce the error, I start a fresh instance with emacs -Q, then run the following: (add-to-list 'load-path /home/trevor/.emacs.d/elpa/org-20130318/) (setq org-babel-load-languages '((python . t))) ; also works with latex, C, ruby, at which point I got bored (require 'org) I expect this to load just fine, but instead I receive a backtrace that freaks out at line #39 in ob-python.el (similarly for other language examples): 38 (defvar org-babel-tangle-lang-exts) 39 (add-to-list 'org-babel-tangle-lang-exts '(python . py)) 40 Seems that the defvar counts for nothing? Perhaps because it's already a defcustom in ob-tangle.el? I don't understand emacs well enough to know, but I will say that inserting a (require 'ob-tangle) anywhere before the offending line solves the problem. Trev
