[Orgmode] [ANN] Lists changes pushed to master
Hello Org users, Since a few hours, lists changes are in master branch. Here is a sum up of the new functionalities: * What's new 1. Indentation of text determines again end of items in lists. So, some text less indented than the previous item doesn't close the whole list anymore, only all items more indented than it. 2. Alphabetical bullets are implemented, through the use of the variable `org-alphabetical-lists'. This also adds alphabetical counters like [@c] or [@W]. 3. Lists can now safely contain drawers, inline tasks, or various blocks, themselves containing lists. Two variables are controlling this: `org-list-forbidden-blocks', and `org-list-export-context'. 4. Improve `newline-and-indent' (C-j): used in an item, it will keep text from moving at column 0. This allows to split text and make paragraphs and still not break the list. 5. Improve `org-toggle-item' (C-c -): used on a region with standard text, it will change the region into one item. With a prefix argument, it will fallback to the previous behavior and make every line in region an item. It permits to easily integrate paragraphs inside a list. 6. `fill-paragraph' (M-q) now understands lists. It can freely be used inside items, or on text just after a list, even with no blank line around, without breaking everything. * Incompatible changes Lists inside blocks are not seen by outside elements. As a corollary, check-boxes in such lists cannot be counted by cookies outside the block. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] fix a bug in org-open-at-point
Hello, This is an improba -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] fix a bug in org-open-at-point
My bad, wrong manipulation. Here is the patch. To reproduce the error, you can type the following in a fresh Org #+begin_src org target some text <<>> another text target #+end_src Using C-c C-o on any of the two links will return an error. >From f7738f3e9239fc4fddccc7850dad7a0936087a58 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Sat, 19 Feb 2011 09:37:48 +0100 Subject: [PATCH] Fix bug with link to radio target at beginning or end of buffer * lisp/org.el (org-open-at-point): if a link to a radio target is the first, (resp. the last), element of a buffer, function cannot find the property change required to get its boundaries, and `buffer-substring' is called with an invalid nil argument. --- lisp/org.el |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index b92186a..bfe9296 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -9214,8 +9214,10 @@ application the system uses for this file type." pos (if (get-text-property (1+ (point)) 'org-linked-text) (1+ (point)) (point)) path (buffer-substring - (previous-single-property-change pos 'org-linked-text) - (next-single-property-change pos 'org-linked-text))) + (or (previous-single-property-change pos 'org-linked-text) + (point-min)) + (or (next-single-property-change pos 'org-linked-text) + (point-max (throw 'match t)) (save-excursion -- 1.7.4.1 Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Headlines export problem
Hello, PASZTOR Miklos writes: > I'm using org-mode version 7.4. When I export org files to html - having > H:2 in the options line - it seems that each third level headline > becomes a *separate* unnumbered list. > > Example: > > * FIRST HEADLINE > ** second > *** These lines will be > *** separate unnumbered lists, > *** not just one. > > Becomes: > > > These lines will be > > > > separate unnumbered lists > > > > Not just one > > > Can I have orgmode to create a *single* unnumbered list from the third level > headlines above? A patch fixing this has been submitted a few days ago. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: indentation for section headings vs bulleted lists
Hello, Linus Arver writes: > Again, I'm very curious why org-mode's indenting code treats bulleted > lists differently than section headings. This is due to a combination of org-indent-mode and visual-line-mode. Actually, it's a a two-parts problem. Firstly, org-indent-mode only works by sections. That means the whole section gets the same indent prefix, whatever can be inside. Thus, lists cannot be treated differently for now. Secondly, org-indent-mode is not indenting anything: it only fakes it. While this is fine for headings, this causes problems with lists, which are depending on real indentation. Anyway, I'm on it. I'll post a patch as soon as I find and implement a decent way to solve this. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: indentation for section headings vs bulleted lists
Hello, Carsten Dominik writes: > while it might be posible to add additional line-prefix stuff to plain > lists, you need to be careful about performance. Yes, this is my main concern actually. When I speak about a "decent" solution, I'm really thinking about a "sufficiently reactive" one, provided such a thing exists. As far as I can tell, line-prefix is fine as it is. Lists just need to take it as real indentation before processing. Alas, wrap-prefix is the real problem. A solution would be to distinguish if org-indent-refresh-section is called with point in a list or not. In the former case, it would skip lists when changing warp-prefix in the section. In the latter situation, it would only set warp-prefix for the list at point. But then, hooks like org-after-demote-entry-hook would need to call org-indent-refresh-section with an argument telling it to redefine warp-prefix for everything in section, lists included. After all, a small delay is acceptable for interactive use. Does it sound "decent"? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] indentation for section headings vs bulleted lists
Hello, Here is an attempt to solve the problem at hand. Linus, would you mind testing it and reporting back? >From 77aad13b9a322032763148b17dd9cb3073bdbf23 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Sun, 20 Feb 2011 13:44:00 +0100 Subject: [PATCH] Integrate lists with org-indent-mode and visual-line-mode * lisp/org-list.el (org-list-insert-item): keep prefix properties when inserting a new item. (org-list-struct-apply-struct): keep prefix properties when modifying an item. * lisp/org-indent.el (org-indent-mode): promoting and demoting should refresh subtree. (org-indent-add-properties): Add lists support. Refactor and comment code. (org-indent-refresh-subtree): No need to remove properties before refreshing. Also, make sure beg is at beginning of line. (org-indent-refresh-to, org-indent-refresh-section): Refactor. No need to remove properties before refreshing either. --- lisp/org-indent.el | 132 ++- lisp/org-list.el | 18 ++- 2 files changed, 73 insertions(+), 77 deletions(-) diff --git a/lisp/org-indent.el b/lisp/org-indent.el index a177a6f..4411cd2 100644 --- a/lisp/org-indent.el +++ b/lisp/org-indent.el @@ -39,6 +39,7 @@ (require 'cl)) (defvar org-inlinetask-min-level) +(declare-function org-in-item-p "org-list" ()) (declare-function org-inlinetask-get-task-level "org-inlinetask" ()) (declare-function org-inlinetask-in-task-p "org-inlinetask" ()) @@ -161,13 +162,12 @@ FIXME: How to update when broken?" (add-to-list 'buffer-substring-filters 'org-indent-remove-properties-from-string) (org-add-hook 'org-after-demote-entry-hook - 'org-indent-refresh-section nil 'local) + 'org-indent-refresh-subtree nil 'local) (org-add-hook 'org-after-promote-entry-hook - 'org-indent-refresh-section nil 'local) + 'org-indent-refresh-subtree nil 'local) (org-add-hook 'org-font-lock-hook 'org-indent-refresh-to nil 'local) -(and font-lock-mode (org-restart-font-lock)) -) +(and font-lock-mode (org-restart-font-lock))) (t ;; mode was turned off (or we refused to turn it on) (save-excursion @@ -181,9 +181,9 @@ FIXME: How to update when broken?" (delq 'org-indent-remove-properties-from-string buffer-substring-filters)) (remove-hook 'org-after-promote-entry-hook - 'org-indent-refresh-section 'local) + 'org-indent-refresh-subtree 'local) (remove-hook 'org-after-demote-entry-hook - 'org-indent-refresh-section 'local) + 'org-indent-refresh-subtree 'local) (and font-lock-mode (org-restart-font-lock)) (redraw-display)) @@ -222,82 +222,66 @@ useful to make it ever so slightly different." (defun org-indent-add-properties (beg end) "Add indentation properties between BEG and END. -Assumes that BEG is at the beginning of a line." +Assume BEG is at an headline, inline task, or at beginning of buffer." (let* ((inhibit-modification-hooks t) (inlinetaskp (featurep 'org-inlinetask)) - (get-real-level (lambda (pos lvl) - (save-excursion - (goto-char pos) - (if (and inlinetaskp (org-inlinetask-in-task-p)) - (org-inlinetask-get-task-level) - lvl - (b beg) - (e end) - (level 0) - (n 0) - exit nstars) + (m end)) (with-silent-modifications + ;; 1. Starting from END, move to each headline and inline task, + ;;and set prefixes point and the headline/inline task below + ;;(saved in M). `line-prefix' property is only set on inner + ;;part of that area, not on headlines. (save-excursion + (goto-char end) + (while (re-search-backward org-indent-outline-re beg 'move) + (let ((pf (aref org-indent-strings + (if (and inlinetaskp (org-inlinetask-at-task-p)) + (1+ (org-inlinetask-get-task-level)) + (1+ (org-current-level)) + (add-text-properties (point) m `(wrap-prefix ,pf)) + (add-text-properties (point-at-eol) m `(line-prefix ,pf)) + (setq m (point + ;; Special case for area before first headline. + (when (bobp) + (add-text-properties (point) m '(wrap-prefix nil line-prefix nil))) + ;; 2. Set `wrap-prefix' in lists between BEG and END. For each + ;;item, length of prefix is the sum of length of + ;;`line-prefix', indentation and size of bullet. (goto-char beg) - (while (not exit) - (setq e end) - (if (not (re-search-forward org-indent-outline-re nil t)) - (setq e (point-max) exit t) - (setq e (match-beginning 0)) - (if (>= e end) (setq exit t)) - (unless (and inlinetaskp (org-inlinetask-in-task-p)) - (setq level (- (match-end 0) (match-beginning 0) 1))) - (setq nstars (* (1- (funcall get-real-level e level)) - (1- org-ind
[Orgmode] Re: [PATCH] indentation for section headings vs bulleted lists
Hello, Giovanni Ridolfi writes: > In Linus's example file there was no heading, I think this is > *not* a "regular example". > > The manual states: " Within an entry of the outline tree,". > > Nicolas, does this constrain still apply with the 'new' > way of handling lists? It should work anywhere in an outline tree and before first headline, if that's your question. So there is no constrain on lists. Please note that the patch isn't ready for submission yet. I'll include some speed improvements (scanning every list in section every 0.2s sure sounds a bit scary) and a bit of polishing a bit later. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bytecompiler is unhappy...
Hello, I've taken care of: > In org-fill-paragraph: > org.el:19105:27:Warning: assignment to free variable `struct' > org.el:19110:33:Warning: reference to free variable `struct' > In end of data: > org-list.el:3007:1:Warning: the function `outline-flag-region' is not known to > be defined. But I'm not sure what's the best way to handle this: > In end of data: > org.el:19993:1:Warning: the following functions are not known to be defined: > org-inlinetask-at-task-p, org-inlinetask-toggle-visibility, > org-inlinetask-outline-regexp (require 'org-inlinetask) within eval-when-compile, or declare the functions? I leave it to the enlightened ones. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bytecompiler is unhappy...
Hello, Carsten Dominik writes: > NO. Declare the functions an use (defvar name) for the variables. This is what I thought at first, but, in org.el, no function was declared already, and a whole package (gnus-sum) was required when compiling. So, I hesitated. Anyway, that part is done now. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [bug] [ANN] Lists changes pushed to master
Hello, Eric S Fraga writes: > I have not changed any org customisations in a while... > > The error only happens if I have a list 4 levels deep, from what I can > see. I have odd levels only set, by the way. I cannot understand why > the depth should matter, mind you. I cannot reproduce this for now. May I have a look at your full configuration ? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-toggle-checkbox bug
Hello, Patch applied. Thanks for catching this. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bug in creating LOGBOOK drawers and maybe in visibility cycling of drawer contens.
Hello, Rainer Stengele writes: > 1. Having a text block like this: > > ** Headline >SCHEDULED: <2011-02-25 Fr> >CLOCK: [2011-02-25 Fr 17:04]--[2011-02-25 Fr 17:04] => 0:00 >CLOCK: [2011-02-25 Fr 17:03]--[2011-02-25 Fr 17:04] => 0:01 >CLOCK: [2011-02-25 Fr 14:30]--[2011-02-25 Fr 16:45] => 2:15 >CLOCK: [2011-02-24 Do 16:30]--[2011-02-24 Do 17:00] => 0:30 >CLOCK: [2011-02-24 Do 14:30]--[2011-02-24 Do 16:00] => 1:30 >CLOCK: [2011-02-23 Mi 13:15]--[2011-02-23 Mi 15:45] => 2:30 >CLOCK: [2011-02-22 Di 09:00]--[2011-02-22 Di 12:30] => 3:30 >CLOCK: [2011-02-21 Mo 13:00]--[2011-02-21 Mo 17:00] => 4:00 >CLOCK: [2011-02-21 Mo 11:15]--[2011-02-21 Mo 12:00] => 0:45 >CLOCK: [2011-02-21 Mo 09:00]--[2011-02-21 Mo 10:00] => 1:00 >- item1 > * [2011-02-21 Mo] more text >- item2 This should be fixed in master now: the whole list will be swallowed by the drawer (I think it is the intent of the original author of the function). > 2. In the Org manual I find: > > , > | Visibility cycling (see Visibility cycling) on the headline will > | hide and show the entry, but keep the drawer collapsed to a single line. > | In order to look inside the drawer, you need to move the cursor to the > | drawer line and press there. > ` > > which does not work for me. I cannot collapse the drawer by pressing TAB. May you be more explicit here ? I have no problems collapsing and expanding drawers here. Is the drawer you want to collapse in `org-drawers', or after #+DRAWERS: in the buffer ? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bug in creating LOGBOOK drawers and maybe in visibility cycling of drawer contens.
Rainer Stengele writes: > thank you! Unfortunately now the :END: encloses even more lines further > down the block! Indeed, the drawer is wrapped around the list. I think this is required as the list may well be some notes or TODO states to put into the logbook. If you don't want to have the list into the drawer, you can skip a line before it. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [bug] [ANN] Lists changes pushed to master
Hello, This bug has been fixed in master branch, but I forgot to tell it to the ML. Thanks again, Eric. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Org cause Emacs to hang
Hello, Marvin Doyley writes: > remove #+STARTUP: indent solved the problem. > > Thanks > M Could you try the following branch, by any chance, and tell me if that fixes your problem, even with that line? git://github.com/ngz/org-mode-lists.git indent-patch-no-timer Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BUG] ? Stray \end{LIST} in latex export
Hello, Jeff Horn writes: > I noticed this last week and can reproduce it. I was just preparing a > bug report on this very problem, and my test file is similar to yours. > > Minimal org setup. > Org-mode version 7.4 (release_7.4.501.gc6dbde.dirty) > GNU Emacs 24.0.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) > of 2011-02-10 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev I cannot reproduce this. Could you try to upgrade to a more recent version, just in case? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BUG] ? Stray \end{LIST} in latex export
Hello, Jeff Horn writes: > | variable | setting | > |+-| > | org-list-ending-method | indent | Ok, this is the culprit. I'll investigate this today. Thanks for the debugging. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org export not working
Hello, John Rakestraw writes: > Symbol's function definition is void: org-search-forward-unenclosed This function has been removed (or to be more precise replaced by `org-list-search-forward') recently, and there's no occurrence of it left in the code base. Did you reload Org properly after upgrading? Do you have some function in your own configuration files calling it? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BUG] ? Stray \end{LIST} in latex export
Hello,
Kieran Healy writes:
> I've had the following issue with recent org-mode builds (since early
> January, I think). A document with an itemized list in it does not
> export properly to latex: the export process inserts/leaves behind
> a stray \end{LIST} statement which breaks the .tex file. For example,
> doing C-c C-e l on this document:
>
>
> #+TITLE: Example
> #+AUTHOR: Example
>
> ** Example
> - Lorem ipsum dolor sit amet
> - Lorem ipsum dolor sit amet
>
> The end.
>
>
> gives the following relevant bit of output:
>
>> \Section{Example}
>> \label{sec-1}
>>
>> \begin{itemize}
>> \item Lorem ipsum dolor sit amet
>> \item Lorem ipsum dolor sit amet
>> \end{itemize}
>> \end{LIST}
>>
>> The end.
It should be now fixed in master. Could you confirm this?
Thanks for reporting this bug !
Regards,
--
Nicolas
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: Automatic Org-mode mailing list signature -- Was: Let's stick to one list for now
Hello,
"Eric Schulte" writes:
> While there are changes to the administration of the mailing list.
> Would it be difficult to change the list signature from
>
> : ___
> : Emacs-orgmode mailing list
> : Please use `Reply All' to send replies to the list.
> : Emacs-orgmode@gnu.org
> : http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> to
>
> : __
> : Emacs-orgmode mailing list
> : Please use `Reply All' to send replies to the list.
> : Emacs-orgmode@gnu.org
> : http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> (note the space after the double hyphen) at the beginning of the second
> signature. I /believe/ (but don't have any reference) that the "-- "
> string is the standard signature delimiter, and it would result in at
> least gnus, and probably other mailing agents, stripping the signature
> from replies by default.
For that particular problem, I have
#+begin_src emacs-lisp
(setq gnus-parameters
'(("string_matching_orgmode_list_folder"
(banner . "___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode";
#+end_src
Regards,
--
Nicolas
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: export to latex broken
Hello, suvayu ali writes: > Emacs (24) hangs with a message saying "Applying style hooks" in the > minibuffer and the cpu usage shoots up and I have to kill emacs. Can > someone else confirm this? I've pushed a fix in master. Is it fixed now? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: export to latex broken
Suvayu Ali writes: > However after I sent my previous email I noticed a separate bug was > introduced in a commit somewhere between the previous commit I mentioned > and > [...] > All babel source blocks are quoted inside a verbatim environment when > exported to latex. I haven't narrowed down the commit yet though. IMO, you shouldn't bother trying to find the commit that introduced the error (the one you cited earlier was actually wrong). It's better to provide a test file, and some pertinent configuration variables. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: Simple Indentation question: indentation behaviour changed some time ago.
Hello, Rainer Stengele writes: > * headline > - item > TEXT > ^ > > cursor on first "T" of "TEXT" and pressing "TAB" I got: > > * headline > - item > TEXT > > nowadays I get > > * headline > - item > TEXT > I checked the org-*indent* variables but could not find a matching variable. > How can I configure the old behaviour? You can set `org-list-ending-method' to 'regexp, meaning that you will need to provide two blank lines (that's configurable though, see `org-empty-line-terminates-plain-lists' and `org-list-end-regexp') to end a list. Otherwise, lists are determined by indentation, so, in your example, TEXT end the list as it is less indented than any of its items. Thus, when pressing TAB, Org indent the line accordingly, that is as a line belonging to the headline but not to the list. Also note that, if TEXT isn't already typed, you can use C-j after "item" to stay inside list and go on typing. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: Simple Indentation question: indentation behaviour changed some time ago.
Hello, Rainer Stengele writes: > I do not understand why when pressing TAB being at point ^: > > - item > > ^ > > results in > > - item > > ^ > > > but having > > > - item > TEXT > ^ > > and pressing TAB results in > > - item > TEXT > ^ > > How can I get the indentation same as with empty lines? You can't. Once TEXT is typed at column 0, by definition, the list before is over, and indentation reflects that. And this makes sense: how could an user end a list if all his text was eventually being inserted inside the list? On the other hand, if no text is typed yet, like in your first case, the list isn't over, and TAB will indent line into the last item of the list, as if you had typed C-j. I hope it is clearer now. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: Simple Indentation question: indentation behaviour changed some time ago.
Rainer Stengele writes: > Many times I start with something like > > > headline > item1 > Text belonging to item1 > Text belonging to item1 > Text belonging to item1 > item2 > Text belonging to item2 > Text belonging to item2 > Text belonging to item2 > > > and then later want to bring in more structure, > making item1 and item2 a list item. > I would then expect to get the "Text belonging to" lines being indented as in > > > headline > - item1 >Text belonging to item1 >Text belonging to item1 >Text belonging to item1 > - item2 >Text belonging to item2 >Text belonging to item2 >Text belonging to item2 That's easy. Select region from "item1" to third "Text belonging to item1", and use "C-c -". This command turns a region into an item (with development version of Org, that is). Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: identation in enabled org-indent-mode and disabled OIM
Hello, Thomas Hisch writes: > why is there no consistent identation between disable OIM and enabled > OIM, or is there a way to enable this consitent identation ?? You have to keep in mind that OIM fakes indentation, that is, you think your line is indented, but in fact, it still lays at column 0. Thus, most the spaces used to indent a line outside OIM aren't needed anymore with OIM on. Anyway, it isn't as bad as it sounds. When you stop OIM, you just have to re-indent the whole buffer to get your spaces back (C-x h C-M-\ for example). Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: identation in enabled org-indent-mode and disabled OIM
Thomas Hisch writes: > After reindenting the whole buffer with > C-x h C-M-\ the list (item1) is not indented properly: > > * Head 1 > Test 0 > ** Subhead 1 >Test 1 > *** Subsubhead 1 > Test 1a > ** Subhead 2 >Test 2 > - item 1 > lals2 > lsakdl3 > lkal3 >item 2 As you may have observed when pressing TAB at an item, lists are never indented. Or more precisely, their indentation is independent from current level of headline. This is because TAB is also used to cycle visibility of the item at point. Well, it may do both actions, but I'm not sure if it's worth implementing it. Anyway, you can still move a whole list to the desired column using M-S-right or M-S-left on the very first level of the list. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: Automatic Org-mode mailing list signature -- Was: Let's stick to one list for now
Hello, Bastien writes: >> While there are changes to the administration of the mailing list. >> Would it be difficult to change the list signature from >> >> : ___ >> : Emacs-orgmode mailing list >> : Please use `Reply All' to send replies to the list. >> : Emacs-orgmode@gnu.org >> : http://lists.gnu.org/mailman/listinfo/emacs-orgmode >> >> to >> >> : __ >> : Emacs-orgmode mailing list >> : Please use `Reply All' to send replies to the list. >> : Emacs-orgmode@gnu.org >> : http://lists.gnu.org/mailman/listinfo/emacs-orgmode > > Done -- except that I used "-- ", not "__ ". > > "-- " is the standard separator for signatures. It may be too late, but I don't think it is an adequate solution. A banner isn't a signature, but now, they look the same, regexp wise. And as signatures are searched from bottom to top, the banner, being the first in that order, will be found first. Thus, now, the banner will be fontified like a signature instead of the real one. If you try to hide the signature, you will only hide the banner, and so on. Regards, -- Nicolas -- Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Re: Strange indentation bevaviour: cannot find out why
Hello, Rainer Stengele writes: > I tested with a minimal emacs config and the "bug" was gone. > So I know it is in my settings, > but I could not find the reason in my configuration. > The behaviour I see appeared only a few weeks or months ago. > Has anybody an idea? This is not the fault of your configuration. This is due to indent-tabs-mode not being nil. I thought I had fixed this bug some time ago, but it looks like I was wrong. I have pushed a (hopefully) final fix for this. Regards, -- Nicolas
[O] Re: latex export issue
Hello, Stephen Eglen writes: > With the following minimal org buffer: > > Simple test > > here here here here here here here here here here here here here here > 2010. here here here here here here here here here here here here > here here here here here here here here here here here here here here > This is modified from a real case; is there any way that the "2010." can > be interpreted as the end of the sentence rather than the start of a > enumerate list? (I have fixed it for now by reformatting my paragraph > so that 2010 does not begin the line.) I get similar behaviour with > html export. I usually suggest to insert a non-breakable space just after the dot. Thus, the pattern doesn't match definition of a numbered list item anymore. Regards, -- Nicolas
[O] Re: lists and fill-region
Hello, michael hohn writes: > after upgrading to the current git head (from a version around 6.36), > fill-region produces wrong indentation for my lists. Starting with > > - one > - very, very, very, very, very, very, very, very, very, very, very, very, > long > - short > > and marking the second item via mark-paragraph followed by fill-region > results in > > - one > - very, very, very, very, very, very, very, very, very, very, very, > very, long > - short > I have pushed a fix for this case. Thanks for your report, it reminds me filling in lists is still a bit fragile, and needs some care. Regards, -- Nicolas
[O] Re: lists and fill-region
Hello, Matt Lundin writes: > A related bug: > >> - one >> - very, very, very, very, very, very, very, very, very, very, very, >> very, long >> - short > > If one calls unfill-paragraph on the "very, very" line above, nothing > happens. In the past, unfill paragraph would turn the item into a single > line, which is very convenient for fixing improperly indented multi-line > items. Could you tell me if the problem with unfill-paragraph persists? If it does, as there is no unfill-paragraph in standard Emacs, could you provide the definition you gave it? Thanks. Regards, -- Nicolas
[O] Re: latex export issue
Hello, Scot Becker writes: > That sounds like it means that any documents you might want to export to > LaTeX (and format with hard line breaks) should always have non-breaking > spaces after the periods---or you should keep a manual eye on your paragraph > formatting to make sure no numbers come first on the line. Would that work for you? #+begin_src emacs-lisp (defun org-fill-item-nobreak-p () "Non-nil when line break would insert a new item." (and (looking-at (org-item-re)) (org-list-in-valid-block-p))) (add-to-list 'fill-nobreak-predicate 'org-fill-item-nobreak-p) #+end_src If it is fine, we may as well include it by default in Org. Regards, -- Nicolas
[O] Re: Symbol's function definition is void: fill-forward-paragraph
Hello, Frank Jäkel writes: > * A > I'm trying to fill this > paragraph by pressing > M-q now > > I get the following error: > > Debugger entered--Lisp error: (void-function fill-forward-paragraph) > (fill-forward-paragraph -1) > (save-excursion (fill-forward-paragraph -1) (setq itemp > (org-in-item-p))) > (cond ((and ... ...) t) (table\.el-p t) (table-p (org-table-align) t) > (itemp (let* ... ... ... t)) ((save-excursion ... ...) (let ... ...)) (t > nil)) > (let ((table-p ...) (table\.el-p ...) (itemp ...)) (cond (... t) > (table\.el-p t) (table-p ... t) (itemp ...) (... ...) (t nil))) > org-fill-paragraph(nil) > fill-paragraph(nil) > call-interactively(fill-paragraph) > > Strangely, if I now go back to the buffer and try M-q this time it will > fill the paragraph as intended. So you mean `fill-forward-paragraph' is known by Emacs afterwards? > A solution that worked for me was to replace all calls to > fill-forward-paragraph with fill-paragraph. I don't think it is a solution as fill-forward-paragraph is a movement function, not a filling one: they can't be equivalent. Regards, -- Nicolas
[O] Re: Symbol's function definition is void: fill-forward-paragraph
Sorry to reply to myself, but I've pushed a change that should satisfy emacsen older than 23 in that area.
[O] Re: latex export issue
Hello, Scot Becker writes: > Looks good, but I can't get it to work. To test it, can I just > evaluate the two sexp's in the block you gave inside a scratch buffer, > then switch to my trial org file and export to LaTeX? Yes, but I guess you misunderstand the goal of the snippet. It will not "fix" export (which isn't broken in that case) but will prevent auto-fill-mode from creating a new item by cutting line at a wrong position i.e. you won't have to keep an eye on the formatting anymore. Regards, -- Nicolas
[O] Re: [Workaround] Escaping false list items
Hello, Christian Moe writes: > Back to the problem with e.g. "2011. " being interpreted as a list > item when it happens to be at the beginning of a line: Did you read my suggestion to avoid filling at such positions? While it won't help on existing documents, I think it is a more general approach to the problem. Regards, -- Nicolas
[O] Re: [Workaround] Escaping false list items
Christian Moe writes: > Did you have a particular trick in mind, or just to avoid filling > manually? I tend to have auto-fill on by default. I meant automatically. Please have a look at: http://article.gmane.org/gmane.emacs.orgmode/39149 Regards, -- Nicolas
[O] Re: [org-list] problem with checkbox intermediate state
Hello, Matt Lundin writes: > Previously, when one hit C-c C-c on an item with an intermediate state, > the item would be checked as completed. I.e., [...] > Would it be possible to restore the old behavior? A progression from > partial completion to full completion seems the most logical sequence. Agreed, and done. Thanks. Regards, -- Nicolas
[O] Re: [BUG] Unmatched #+end-src
Hello, Aankhen writes: >> --8<---cut here---start->8--- >> * Unmatched #+end-src bug >> >> #+end_src >> --8<---cut here---end--->8--- >> >> With the above simple org file, placing the cursor at the end of >> #+end_src and hitting return causes emacs to hang. >> > The =cond= is part of a =while= loop; it just keeps looping, entering > that branch and doing nothing (rather than moving point and picking up > again from there). Going by the other branches, I think the correct > thing to do is just exit the loop: I don't think exiting the loop that way is the right thing to do, as it always return nil, even though the #+end_ might be in the list. Moreover, there are other parts of the file that should also be fixed. I think there are 3 options here: 1. Effectively stop everything, but at least throw an informative error. 2. Consider the #+end_ as normal text after all, and resume the loop. 3. Consider #+end_ as normal text and message the user about his syntax problem. I'm not sure yet what's the best way to go, but I think option 2 is sufficient. Regards, -- Nicolas
[O] Re: [BUG] Unmatched #+end-src
Hello, Martyn Jago writes: > I've supplied a patch which passes all of my tests, but I will look at > providing additional tests looking at other cases within this loop since > I'm currently in the habit of writing tests anyway. Your patch has the same weakness as the previous one and I explained why. For example, in the following example, calling (org-in-item-p) with point anywhere on line "some text" will return nil, which is obviously wrong. - item 1 #+end_ some text - item 2 Actually, it is not a matter of patch, which is just changing #+begin_src emacs-lisp ((looking-at "^[ \t]*#\\+end_") (re-search-backward "^[ \t]*#\\+begin_" nil t)) #+end_src into #+begin_src emacs-lisp ((and (looking-at "^[ \t]*#\\+end_") (re-search-backward "^[ \t]*#\\+begin_" nil t))) #+end_src once for blocks and once for drawers, in both org-in-item-p and org-list-struct. The real problem is: how should Org react when parsing syntactically erroneous buffers? I concede that freezing Emacs isn't nice, but otoh, code can't deal with every possible user error. So, what is the expected behavior here? Consider orphan #+end_ as normal text, throw an error, or both? An answer to this question would be more useful than code, honestly. I hope I am clearer now. Regards, -- Nicolas
[O] [dev] org-indent-mode patch
Hello, I'd like to submit the following org-indent-mode patch for testing. git://github.com/ngz/org-mode-lists.git indent-patch-no-timer It implements two things: 1. It indents correctly text when using visual-line-mode; 2. It removes the idle timer previous implementation was using, which means it won't refresh indentation more often than necessary. Unfortunately, there is a price to pay: 1. Initialization will be much longer for large Org files, but I've added a message to the user saying so. 2. It is a bit slower, as the algorithm has more things to check. Last point is obviously my main concern. Although not noticeable on my not-so-recent laptop, I don't know how it behaves on old machines. That's why a testing is necessary to determine (bugs and) if it is usable. Any help welcome. Regards, -- Nicolas
[O] Re: Set the beginning section number
Hello,
lbml...@hethcote.com writes:
> I may have not read sufficiently, but I have not yet found how to set
> the beginning number when exporting to HTML and I'm desiring to start
> with a number other than 1.
>
> * This
> ** is the example
> *** that I play
> *** with
>
> Exports to:
>
> 1 This
> 1.1 is the example
> 1.1.1 that I play
> 1.1.2 with
>
> What I would like to do is set the initial number so that the exported
> reads as:
>
> 33 This
> 33.1 is the example
> 33.1.1 that I play
> 33.1.2 with
This may not be exactly what you're looking after, but lists can do
something like this:
#+title: Say 33
33. [@33] This
1. is the example
1. that I play
2. with
Regards,
--
Nicolas
[O] Re: [Bug] MCE for HTML test of export
Hello, Sébastien Vauban writes: > * Russian dolls > > In the following, I see one block in the other, with visible > =ORG-LIST-END-MARKERs=. > > *** TODO To send > > - This > - That > > *** END > > *** TODO To receive > > - Pictures > - Invoice > > *** END It will not be very helpful, but: I cannot reproduce it, even with minimal setup. Regards, -- Nicolas
[O] Re: [REGRESSION] Description List + HTML
Hello, Jambunathan K writes: > My head is at git commit 6a369 and > > With `emacs -Q', do a C-c C-e h on bug.org. > > See that the following paragraph (or whatever!) > > "But in the end, no individual scenes matter but the film as a whole. > Important actors in this film are" > > is NOT within any HTML tags and is floating. I don't see anything wrong here. What would you expect instead? Regards, -- Nicolas
[O] Re: [REGRESSION] Description List + HTML
Jambunathan K writes: > Validation with nxml mode is succeeding. So the document is > well-formed. But it does look strange to me. I may help if you would elaborate. > Anyways, I am attaching the same file exported with release_7.3. You > would notice that the disputed text is enclosed within . > > Would you consider enclosing them in paragraph tags. I've pushed a fix in that direction. Is it correct now? Regards, -- Nicolas
[O] Re: List-table feature (or a potential quick and easy mullti-lines table in org?)
Hello, Ben writes: > I'm thinking about a potential alternative and I would like to know if > anyone here would know if this can be done with org. > ReStructured Text [2] has a nice feature called list-tables. As you can > guess from the name, you write a list and an instruction to process it and > it creates a table out of the list in the export target. See the ReST > documentation for a quick explanation [3]. What is does it to transform a > nested list in a simple table. And potentially it would make long list items > / table content easy to edit. > > Does anyone has heard of such a possibility in Org? Out of boredom, I've written a draft for it. First we need the following function that might be of some use (i.e. to Babel, as you can write an Org list as a lisp list and write it to the buffer). Well anyway, here it is: #+begin_src emacs-lisp (defun org-list-to-org (list) "Convert LIST into an Org list. LIST is as returned by `org-list-parse-list'." (let ((sep (if (eq org-plain-list-ordered-item-terminator ?\)) ")" ".")) (ltype (make-vector 20 "-"))) (org-list-to-generic list '(:isep "\n" :ostart (and (aset ltype depth (concat "1" sep)) "") :dstart (and (aset ltype depth "-") "") :ustart (and (aset ltype depth "-") "") :icount (concat (make-string depth ?\ ) (org-list-bullet-string (aref ltype depth)) (format "[@%d] " counter)) :istart (concat (make-string depth ?\ ) (org-list-bullet-string (aref ltype depth))) :cbon "[X]" :cboff "[ ]" :dtstart (if (and org-list-two-spaces-after-bullet-regexp (string-match org-list-two-spaces-after-bullet-regexp "-")) " " " ") :csep "\n" :ddstart " :: " #+end_src Next, we need bi-directional internal representation converters from a table to a list: #+begin_src emacs-lisp (defun org-lisp-list-to-table (list) "Change LIST lisp representation into a table lisp representation." (mapcar (lambda (sub) (cons (nth 1 sub) (mapcar (lambda (item) (nth 1 item)) (cdr (nth 2 sub) (cdr list))) (defun org-lisp-table-to-list (table) "Change TABLE lisp representation into a list lisp representation." (cons 'unordered (mapcar (lambda (row) (list nil (car row) (cons 'unordered (mapcar (lambda (cell) (list nil cell)) (cdr row) table))) #+end_src Finally, we need the interactive functions for the user. Those will also clean up output. #+begin_src emacs-lisp (defun org-convert-list-to-table () "Transform list at point into a table." (interactive) (if (org-at-item-p) (let ((parsed (org-list-parse-list t))) (insert (orgtbl-to-orgtbl (org-lisp-list-to-table parsed) nil) "\n") (goto-char (org-table-begin)) (org-table-align)) (error "Not at a list"))) (defun org-convert-table-to-list () "Transform table at point into a list." (interactive) (if (org-at-table-p) (let ((pos (point)) (table (org-table-to-lisp))) (delete-region (org-table-begin) (org-table-end)) (insert (org-list-to-org (org-lisp-table-to-list table))) (goto-char pos) (org-list-repair)) (error "Not at a table"))) #+end_src That's it. All of this will convert - Row 1 - 1.1 - 1.2 - 1.3 - Row 2 - 2.1 - 2.2 - 2.3 to | Row 1 | 1.1 | 1.2 | 1.3 | | Row 2 | 2.1 | 2.2 | 2.3 | and the other way. Notes : - I'm far from being an Org table expert. There probably are corner cases. This also doesn't support hlines. - This requires latest git head (b6fc03b) Regards, -- Nicolas
[O] Re: [Bug] MCE for HTML test of export
Hello,
Sébastien Vauban writes:
> Regarding this problem only, it must be an interaction then with my following
> setting for the inline task in HTML:
>
> #+begin_src emacs-lisp
> ;; templates for inline tasks in various exporters
> (setq org-inlinetask-export-templates
> '((html "%s%s%s"
> '((unless (eq todo "")
> (format "%s%s "
> class todo todo priority))
> heading content))
> (latex "\\todo[inline]{\\textbf{\\textsf{%s
> %s}}\\linebreak{} %s}"
> '((unless (eq todo "")
> (format "\\textsc{%s%s}" todo priority))
>heading content))
> (ascii " -- %s%s%s"
> '((unless (eq todo "")
> (format "%s%s " todo priority))
>heading
>(unless (eq content "")
> (format "\n ¦ %s"
> (mapconcat 'identity
> (org-split-string content
> "\n")
> "\n ¦ ")))
> #+end_src
Indeed, it came from your templates. To prevent this, I made sure, with
the following patch, that CONTENT is always enclosed by newline
characters. Would you mind testing it before I apply it ?
Also, you may have a look at default templates, as your HTML variant is
slightly wrong (wrt tag).
Thanks.
Regards,
--
Nicolas
>From 35c116e16b319354322318b8405e557a61da4459 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Thu, 17 Mar 2011 12:12:31 +0100
Subject: [PATCH] org-inlinetask: modify export of inline tasks
* lisp/org-inlinetask.el (org-inlinetask-export-templates): fix
default templates.
(org-inlinetask-export-handler): Ensure contents of inline task, if
any, starts and ends with a newline character. Refactor and comment
code.
---
lisp/org-inlinetask.el | 98 ++--
1 files changed, 53 insertions(+), 45 deletions(-)
diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el
index 990a1ac..96809ce 100644
--- a/lisp/org-inlinetask.el
+++ b/lisp/org-inlinetask.el
@@ -107,12 +107,12 @@ When nil, they will not be exported."
:type 'boolean)
(defvar org-inlinetask-export-templates
- '((html "%s%s\n%s\n"
+ '((html "%s%s%s"
'((unless (eq todo "")
(format "%s%s "
class todo todo priority))
heading content))
-(latex "\\begin\{description\}\n\\item[%s%s]~\n%s\n\\end\{description\}"
+(latex "\\begin\{description\}\n\\item[%s%s]~%s\\end\{description\}"
'((unless (eq todo "") (format "\\textsc\{%s%s\} " todo priority))
heading content))
(ascii " -- %s%s%s"
@@ -306,66 +306,74 @@ If the task has an end part, also demote it."
"Handle headlines with level larger or equal to `org-inlinetask-min-level'.
Either remove headline and meta data, or do special formatting."
(goto-char (point-min))
- (let* ((nstars (if org-odd-levels-only
-(1- (* 2 (or org-inlinetask-min-level 200)))
- (or org-inlinetask-min-level 200)))
-(re1 (format "^\\(\\*\\{%d,\\}\\)[ \t]+.*\n" nstars))
-(re2 (concat "^[ \t]*" org-keyword-time-regexp))
-headline beg end stars content)
-(while (re-search-forward re1 nil t)
- (setq headline (match-string 0)
- stars (match-string 1)
- content nil)
- (replace-match "")
- (while (looking-at re2)
- (delete-region (point) (1+ (point-at-eol
- (while (looking-at org-drawer-regexp)
- (setq beg (point))
- (if (re-search-forward org-property-end-re nil t)
- (delete-region beg (1+ (match-end 0)
- (setq beg (point))
- (when (and (re-search-forward "^\\(\\*+\\)[ \t]+" nil t)
-(= (length (match-string 1)) (length stars))
-(progn (goto-char (match-end 0))
- (looking-at "END[ \t]*$")))
- (setq content (buffer-substring beg (1- (point-at-bol
- (delete-region beg (1+ (match-end 0
+ (let* ((keywords-re (concat "^[ \t]*" org-keyword-time-regexp))
+(inline-re (concat (org-inlinetask-outline-regexp) ".*")))
+(while (re-search-forward inline-re nil t)
+ (let ((hea
[O] Re: List-table feature (or a potential quick and easy mullti-lines table in org?)
Hello, Ben writes: > Oh actually you went the 'line' way -- and not the column. > Considering, I actually think you're right. > I got used to the ReST way (1 item + sub-items = 1 column) but I think your > way seems more natural. I went that way because it was easier to implement. Though, there is code somewhere to transpose tables (in Library of Babel, I think). So you can type list items as columns instead, change the list into a table, and transpose it. Voilà. Regards, -- Nicolas
[O] Re: Future Worg publishing failure :)
Hello,
Bastien writes:
>> Current org code takes the 14. as an item in a numbered list. When
>> exporting to HTML, this causes an error in org-html-export-list-line -
>> hence the subject line. It's not a problem right now but it will be when
>> orgmode.org gets the updated version. I reformatted the line to avoid
>> the awkward newline, so the future publishing failure will not
>> happen.
>
> Thanks for that!
>
>> I'll let Nicolas worry about what should be done about the error.
>
> Let's not leave Nicolas alone here :) I'll take a look myself into it
> over the week-end.
Phew, what a relief ;)
The only solution I could think of is somewhere in the patchwork server
("Auto-fill shouldn't insert new items").
Regards,
--
Nicolas
[O] Re: [BUG] LaTeX export + footnotes with lists
Hello, Puneeth Chaganti writes: > Footnotes with lists don't seem to export properly to LaTeX. The > string "ORG-LIST-END-MARKER" is appended to the list, when it is > exported. I will look into it, but I would appreciate if you could give me an example to work on in the meantime. Thanks. Regards, -- Nicolas
[O] Re: Future Worg publishing failure :)
Hello,
Nick Dokos writes:
>> The only solution I could think of is somewhere in the patchwork server
>> ("Auto-fill shouldn't insert new items").
>>
>
> Are you saying that the patchwork server introduced this? Or that the
> patchwork server should solve it? In the case I stumbled upon (a Worg
> file), the patchwork server is nowhere in sight, I think: the change was
> (I'm guessing here) directly committed, so maybe the original writer had
> auto-fill turned on, but maybe not and just typed it that way. So
> neither the patchwork server nor making auto-fill smarter would provide
> a guaranteed solution. But maybe there is no such thing.
I'm not sure to understand. I mean that there is a patch waiting to be
processed in the patchwork server, that should get us as close to the
solution as I can think of (so, probably not very close).
It is true that the patch only solves the problem if it would happen
with auto-fill (or fill-paragraph). On the other hand, if the original
writer typed it that way, it's an user problem, and I don't think we
should add cruft to solve it.
> Perhaps a heuristic in html export to just take care of the error: if
> it looks like a numbered list item but there is no item body, bail and
> assume it's part of the text.
I introduced support for empty items on purpose. That would be
a regression.
> Or a combination of that together with the item number > 1. Would that
> work?
It would partly work. But:
- You would get false positives (rarely, but still),
- It wouldn't handle case when line, beside the bullet, isn't empty,
- It isn't only about HTML export, not even about export, as the same
situation happens in Org buffers.
Again, preventing the problem to happen automatically, i.e. without the
user knowing for sure about it, is taken care of by the patch (provided
it doesn't break anything else, thus its journey on the patchwork
server). In every other case, we can assume that the user knows (should
know) both Org syntax and what he is doing.
Now, for already introduced problems, it is indeed possible to build
a function using heuristics to scan files, and when matching, offer to
join lines and fill-paragraph. I don't think there are enough cases to
justify this, though.
Regards,
--
Nicolas
[O] Re: [BUG] LaTeX export + footnotes with lists
Puneeth Chaganti writes: > Thanks for looking into this. I have attached a simple example file. > > Hope that helps, It does ! I have pushed a fix in master that should fix the problem. This is due to the marker I use for list end "ORG-LIST-END-MARKER": it must be on a line on its own. Basically, every problem with that string appearing in the output is related to that: code was inserted just after the marker. At some point, I may have to allow the marker to live in a non-empty line, but I'm pretty sure it won't be as easy as it sounds. Regards, -- Nicolas
[O] Re: Future Worg publishing failure :)
Nick Dokos writes: > However, there is still the problem that an empty item in a numbered > list will trigger the error that I posted, so > org-html-export-list-line will need to be taught how to deal with an > empty list item - correct? Correct. I overlooked that part of the problem, being focused on the number interpretation as a list item. This is now fixed in master, for HTML and DocBook. Thanks ! Regards, -- Nicolas
[O] Re: [Bug] MCE for HTML test of export
Hello, Sébastien Vauban writes: > Perfect. Works like a charm. Please do apply it... Done. >> Also, you may have a look at default templates, as your HTML variant is >> slightly wrong (wrt tag). > I'm not sure to understand what's "wrong". You mean the fact I added manually > a tag after the title? I just meant that you could replace by . I think both are valid HTML-wise, but Emacs doesn't report an error with the latter. Regards, -- Nicolas
[O] Re: [BUG] fill-paragraph in orgstruct mode blows up
Hello, Nick Dokos writes: > I use orgstruct mode when composing email and fill-paragraph blew up > with the following backtrace when I tried to fill a paragraph after a > drawer, as described in the last paragraph of this email. This should be fixed now. Thanks for your report (again). Regards, -- Nicolas
[O] Re: Org minor mode in mail-mode
Hello, Matt Lundin writes: >> Any idea on how to make use of org minor mode in mail-mode and still >> be able to fill-paragraph without impacting mail headers? > > The org minor modes set the local value of fill-paragraph-function to > org-fill-paragraph. You can override this by adding a line to your hook > function: > > (defun turn-on-full-org-mailing () > (turn-on-orgstruct++) > (turn-on-orgtbl) > (load "org-html-mail") > (setq fill-paragraph-function 'message-fill-paragraph)) > > I'm not sure how this will affect calling fill on lists or tables, > however. It will break list and tables filling. > A proper fix would probably add a test to org-fill-paragraph to see if > we are in message mode. Another idea would be to change `paragraph-start' and `paragraph-separate' values when turning on orgstruct and orgtbl. #+begin_src emacs-lisp (setq paragraph-start (concat (regexp-quote mail-header-separator) "$\\|" "-- $\\|" ; signature delimiter "---+$\\|"; delimiters for forwarded messages page-delimiter "$\\|" ; spoiler warnings ".*wrote:$\\|"; attribution lines message-cite-prefix-regexp "$\\|" ; empty lines in quoted text ; mml tags "<#!*/?\\(multipart\\|part\\|external\\|mml\\|secure\\)" paragraph-start)) (setq paragraph-separate paragraph-start) #+end_src Regards, -- Nicolas
[O] Re: org-toggle-checkbox does not work on entry with logbook entries
Hello, Matt Lundin writes: > When I call org-toggle-checkbox on the following headline: > > * An entry with logbook entries > SCHEDULED: <2011-03-19 Sat 08:00 .+1d> > :LOGBOOK: > CLOCK: [2011-03-23 Wed 08:07] > - State "DONE" from "NOW"[2011-03-18 Fri 13:44] > CLOCK: [2011-03-18 Fri 13:11]--[2011-03-18 Fri 13:44] => 0:33 > - State "DONE" from "NOW"[2011-03-01 Tue 08:51] > :END: > > - [ ] Item one > - [ ] Item two > - [ ] Item three > > All the items are checked correctly. > > - [X] Item one - [X] Item two - [X] Item three > > But when I call org-toggle-checkbox on the entry again, the items are > not unchecked. > > If I remove the LOGBOOK drawer, everything works as expected. This should be now fixed on master. Thank you for reporting this. Regards, -- Nicolas
[O] Re: advice: how to export a list without exporting all entries
Hello, Eric S Fraga writes: > I would like to move to a system in which all the actions are numbered > sequentially. At present, they are numbered sequentially within a list > for each meeting. I would like to have a single list which grows over > time. However, when I distribute the minutes of the latest meeting, I > would like to only have those actions which are not yet complete listed > in the document I circulate. The complication is that I want those > actions that have actually been done still in the list but not exported. > > Is there any way to /comment/ out individual list items (whether bullet > or enumerated) on export? I export typically to latex but this need not > be a constraint. Simply putting [ ] versus [X] boxes on the items is not > satisfactory as the list would be very long if all items were included in > the export. > > Is there some hook that I can intercept that would enable this? Can I > encapsulate individual list items into latex macros with the status of > the [ ] or [X] boxes? I am more than happy to write latex code as > required! Or even, at a push, elisp code... I'm not sure to fully understand what you want, but couldn't you delete-matching-lines toggled check-boxes in a copy of the original buffer, and export that? Regards, -- Nicolas
[O] Re: [BUG] Unmatched #+end-src
Hello, Martyn Jago writes: > Hi > > * Unmatched #+end-src bug > > #+end_src > > With the above simple org file, placing the cursor at the end of > #+end_src and hitting return causes emacs to hang. I've pushed a fix that should solve the problem. Please tell if it doesn't. Thank you for your report. Regards, -- Nicolas
[O] Re: Continuation of main section text after subsections ?
Hello, "Filippo A. Salustri" writes: > The workaround I use is to use lists instead of headlines. The > problem then becomes the extra work of turning lists into > headines+text later. What about using C-c C-* on the list? Regards, -- Nicolas
[O] Re: [PATCH] org-latex: Don't append newline to end of footnote
Hello,
Lawrence Mitchell writes:
> * lisp/org-latex.el (org-export-latex-preprocess): Don't add a newline
> character to a processed footnote.
>
> The extra newline before the closing } character in a footnote
> confuses the list parsing code. The } appears at the beginning of a
> line, so it looks like the end of the list. LaTeX gobbles the space
> anyway, so don't add it.
> ---
>> Hi
>
>> if I export the fiollowing snippet
>
>> * Project Participants
>> - Rainer M Krug :: [fn::My email]
>> My address
>
> The list is closed incorrectly. This appears to be a problem in
> the interaction between the list parsing and footnote processing
> code. When exporting footnotes, we add a newline at the end, so
> in the above example the intermediate file seen by the list
> processing code is:
>
> | * Project Participants
> | - Rainer M Krug :: \footnote{My email
> | }
> | ORG-LIST-END-MARKER
> | My address
>
> The } at the beginning of the line below the list entry is
> considered to end the list, so we get:
>
> | * Project Participants
> | \begin{description}
> | \item[Rainer M Krug] \footnote{My email
> | \end{description}
> | }
> | ORG-LIST-END-MARKER
> | My address
>
> Note how the description list is ended /inside/ the footnote
> command.
>
> Since LaTeX gobbles the trailing space in the footnote anyway, it
> makes sense not to insert it in the first place, which this patch
> does. Your test case now exports correctly.
The analysis is good, but unfortunately the patch has a flaw.
In fact, your patch work in that particular situation, but not if
a footnote definition ends with a list, nor if it ends with a link. To
solve the latter, you need to insert a white-space before the closing
bracket. To solve the former, I thought adding a newline instead of the
white-space was enough, but it now appears it was a bad idea.
Thus, the solution lies elsewhere.
Regards,
--
Nicolas
[O] Re: [PATCH] org-latex: Don't append newline to end of footnote
Hello,
Rainer M Krug writes:
> Additional information: I changed to 7.5 (released version) and it works
> there as expected.
>
> Rainer
>
>
> On 30/03/11 11:14, Lawrence Mitchell wrote:
>> Nicolas wrote:
>>> Hello,
>>
>>> Lawrence Mitchell writes:
>>
>>
>> [...]
>>
>>> The analysis is good, but unfortunately the patch has a flaw.
>>
>>> In fact, your patch work in that particular situation, but not if
>>> a footnote definition ends with a list, nor if it ends with a link. To
>>> solve the latter, you need to insert a white-space before the closing
>>> bracket. To solve the former, I thought adding a newline instead of the
>>> white-space was enough, but it now appears it was a bad idea.
>>
>>> Thus, the solution lies elsewhere.
>>
>> Ugh, indeed. I wonder whether it would be enough to add the
>> correct list indent to the beginning of the line with the closing
>> brace.
>>
>> ALthough I notice without my patch, the export of a footnote
>> containing a list which is in a list also does not work:
>>
>> - Hello [fn:1]
>>
>> * Footnotes
>>
>> [fn:1] Goodbye
>>- an item
>>
>> No idea how to fix this though, sorry.
Would the attached patch work ? I've tested it successfully on the
following buffer:
--8<---cut here---start->8---
#+title: Test footnotes
* Titre
Text [fn:1] and a list
- [fn:2]
- three
Another try [fn:3]
* Footnotes
[fn:1] A definition with
- a list
- of two elements
[fn:2] Test
[fn:3] [[file:~/.bashrc][bashrc]]
--8<---cut here---end--->8---
Regards,
--
Nicolas
>From ccba9a10dddffb805635ecc10e760e92bf6ca8d2 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Wed, 30 Mar 2011 23:52:33 +0200
Subject: [PATCH] org-latex: fix footnotes wrt lists and links
* lisp/org-latex.el: pay attention to end of footnote. Before closing
the command, ensure that list is properly closed or that last link
is separated from the curly brace.
---
lisp/org-latex.el | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index e42b64d..47fdfa7 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -2418,12 +2418,15 @@ The conversion is made depending of STRING-BEFORE and
STRING-AFTER."
(replace-match (org-export-latex-protect-string
(concat "$^{" (match-string 1) "}$")))
(replace-match "")
- (let ((end (save-excursion
- (if (re-search-forward "^$\\|^#.*$\\|\\[[0-9]+\\]"
nil t)
- (match-beginning 0) (point-max)
-(setq footnote (concat (org-trim (buffer-substring (point)
end))
- ; last } won't be part of a link or
list.
- "\n"))
+ (let* ((end (save-excursion
+(if (re-search-forward "^$\\|^#.*$\\|\\[[0-9]+\\]"
nil t)
+(match-beginning 0) (point-max
+ (body (org-trim (buffer-substring (point) end
+;; Fix for footnotes ending on a link or a list.
+(setq footnote
+ (concat body
+ (if (string-match "ORG-LIST-END-MARKER\\'" body)
+ "\n" " ")))
(delete-region (point) end))
(goto-char foot-beg)
(delete-region foot-beg foot-end)
--
1.7.4.2
[O] Re: Timer mode doesn't hyphenate correctly
Hello,
"Mark S" writes:
> Hello Matt,
>
> --- On Wed, 3/30/11, Matt Lundin wrote:
>
>>I cannot reproduce this.
>>All of the following timer items were entered quickly using
>> M-Tab:
>> - 0:01:04 :: An item
>> - 0:01:07 :: Another item
>> - 0:01:10 :: Yet another
>>
>
> It appears that you can get different results depending on how you
> start the timer and whether there are prior entries there. Basically,
> you need to start on a blank line with no prior timing entries. If you
> start your timer, either with C-c C-x 0 or with C-c C-x - with prior
> timer entries, you are likely to get the results I described before
> (double hyphens), or error messages ("not a timer list").
>
> So to people who know the right incantation, I suppose it looks ok.
> But if you take even a slight detour you may get some strange results.
>
> Maybe there should be a bit more warning in the manual. But now that
> I've worked out the land-mines, I'm sure its going to be very useful.
I cannot reproduce what you are describing. I may be misunderstanding
you. Could you please post an ECM for that?
Regards,
--
Nicolas
[O] Re: unnumbered subsections in latex export
tput Org buffer in the
chosen format;
5. create (many are readily available) functions for each backend to
interpret them.
Now about that explicit format. Taking this buffer,
--8<---cut here---start->8---
#+title: Example buffer
Some text before first headline.
* First section
First paragraph $\alpha = 1$.
Second paragraph.
- item 1
- item 2
#+begin_center
Text
#+end_center
| Row 1 | 1 | 2 |
| Row 2 | 3 | 4 |
* Second section
Text with footnote[fn:1].
*** Inline task
Some text and
a [[http://www.gnu.org/software/emacs/][link]]
:DRAWER:
- I like
- lists.
:END:
*** END
* Footnotes
[fn:1] Footnote definition.
--8<---cut here---end--->8---
It could be parsed as the following:
'((:title "Example buffer")
(paragraph "Some text before first headline.")
(headline "First section"
(paragraph "First paragraph "
(latex "$\alpha = 1")
".")
(paragraph "Second paragraph")
(list unordered (nil "item 1")
(nil "item 2")
(center (paragraph "Text")))
(table ("Row 1" "1" "2")
hline
("Row 2" "3" "4")))
(headline "Second section"
(paragraph "Text with footnote"
(footnote "Footnote definition")
".")
(inlinetask "Inline task"
(paragraph "Some text and\na "
(link "link" "http://www.gnu.org/";))
(drawer (list unordered (nil "I like")
(nil "lists."))
Note that such a parsing will need a decent forward-paragraph function.
It's also a very simplified example: headlines would need more than the
title string (todo keyword, priority, tags) before starting the body.
I have no code to offer at the moment, and, as we all know, Devil is in
the details. But if the output from org-exp.el is clear, exporters will
be more coherent. It is even provide tools to help exporters doing their
task (a function to extract footnotes from the output, for example).
Again, it may be a big task to undertake, but I think it will be
necessary at some point.
Regards,
--
Nicolas
[O] Re: Timer mode doesn't hyphenate correctly
Hello, "Mark S" writes: >>I cannot reproduce what you are describing. I may be >> misunderstanding you. Could you please post an ECM >> for that? >> > What's an ECM? A minimal Org buffer with a recipe to reproduce the bug. > Another thing I've noticed is that sometimes the list items are > created in chronological order, and other times in > reverse-chronological order. In fact, most of the time it wants to go > in reverse-chronological order. Since there's no example in the > manual, I'm not sure which one is "normal". I would prefer > chronological order, but I can see why some might prefer > reverse-chronological. It doesn't "want" anything. If you hit M-RET between left margin and beginning of item's body, the new item will be inserted before the current one. Otherwise, it will be inserted after it, as in any other type of list. Anyway, you can always sort your timer list with "C-c ^". Regards, -- Nicolas
[O] Re: Timer mode doesn't hyphenate correctly
"Mark S" writes: > --- On Thu, 3/31/11, Nicolas wrote: > >> It doesn't "want" anything. If you hit M-RET between left >> margin and >> beginning of item's body, the new item will be inserted >> before the >> current one. Otherwise, it will be inserted after it, as in >> any other >> type of list. >>Anyway, you can always sort your timer list with "C-c ^". >> > > Actually, its a little different. If you hit alt-enter at the end of > a line, without typing other text first, like > >- 0:00:02 :: > > It thinks that you're at the beginning of a line and places the > date-stamp *above* : > >- 0:03:43 :: >- 0:00:02 :: I didn't say at the beginning of line but before _item's body_. The tag in a description list (or a timer list) isn't considered as the body of the item, so my point is still valid. It would be the same with a checkbox. The advantage of this behavior is that M-RET will (or should) never break list structure. Imagine M-RET in the middle of a checkbox or an item tag. Regards, -- Nicolas
[O] Re: advice: how to export a list without exporting all entries
Hello, Eric S Fraga writes: > Nicolas writes: >> Eric S Fraga writes: >>> I would like to move to a system in which all the actions are numbered >>> sequentially. At present, they are numbered sequentially within a list >>> for each meeting. I would like to have a single list which grows over >>> time. However, when I distribute the minutes of the latest meeting, I >>> would like to only have those actions which are not yet complete listed >>> in the document I circulate. The complication is that I want those >>> actions that have actually been done still in the list but not exported. >>> Is there any way to /comment/ out individual list items (whether bullet >>> or enumerated) on export? I export typically to latex but this need not >>> be a constraint. Simply putting [ ] versus [X] boxes on the items is not >>> satisfactory as the list would be very long if all items were included in >>> the export. >>> Is there some hook that I can intercept that would enable this? Can I >>> encapsulate individual list items into latex macros with the status of >>> the [ ] or [X] boxes? I am more than happy to write latex code as >>> required! Or even, at a push, elisp code... >> I'm not sure to fully understand what you want, but couldn't you >> delete-matching-lines toggled check-boxes in a copy of the original >> buffer, and export that? >> >> Regards, > > Thanks for the suggestion. I think you did understand me and, yes, that > would work, but only *if* each list entry were a single line. > Unfortunately, I tend to fill my list paragraphs so that each item in > the list is often several lines and, in fact, often several paragraphs > (especially when it concerns minutes of a meeting and resulting > actions). delete-matching-lines would delete the first line of a list > entry only. > > I need to be able to "delete" whole list entries automatically based on > their status, whether in a copy or during export. Maybe the following functions might help you. Their docstring is explicit. #+begin_src emacs-lisp (defun esf-list-remove-if (predicate struct) "Remove all items satisfying PREDICATE in STRUCT and in buffer. PREDICATE is a function called with item position as argument. The modified STRUCT is returned." (let ((rev-struct (reverse struct)) res e) (while rev-struct (setq e (pop rev-struct)) (let ((item (car e))) (if (funcall predicate item) (delete-region item (nth 6 e)) (push e res res)) (defun esf-clear-toggled-checkboxes () "Remove toggled check-boxes from list at point. Move point at the end of the list." (interactive) (if (not (org-at-item-p)) (error "Not at a list item") (let* ((struct (org-list-struct)) (end (copy-marker (org-list-get-bottom-point struct (esf-list-remove-if (lambda (e) (equal "[X]" (org-list-get-checkbox e struct))) struct) (goto-char end #+end_src Then, remove toggled checkboxes in an hook called just before list processing: #+begin_src emacs-lisp (add-hook 'org-export-preprocess-after-tree-selection-hook (lambda () (goto-char (point-min)) (while (org-list-search-forward (org-item-beginning-re) nil t) (esf-clear-toggled-checkboxes #+end_src Note that this solution doesn't handle nested lists (i.e. checkboxes in lists inside a drawer itself in a list). HTH, Regards, -- Nicolas
[O] Re: advice: how to export a list without exporting all entries
Eric S Fraga writes: > Thanks for the code. This looks like it would do what I originally > thought I wanted but Carsten, as always, has come to the rescue and > provided exactly what I needed (as opposed to what I asked for ;-). See > his recent email on the list about =org-new-numbered-action=! Ah, I didn't follow closely this thread. I wish I could read minds like Carsten! Regards, -- Nicolas
[Orgmode] Re: Bug with M-RET on headline with text below it
Hello, >>>>> Anthony Lander writes: > On the latest git pull, Org-mode version 7.01trans (release_7.01h. > 500.gbbac.dirty), I encountered a problem with M-RET. When on a > headline with text below it, M-RET will insert a new heading after > the current heading, but before the text. This is the expected behavior for M-RET. What you are looking for is C-RET (`org-insert-heading-respect-content'). Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Org capture with predefined entries from a list?
Hello, >>>>> Miguel Ruiz writes: > Might I implement an org capture template with predefined entries > from a list instead of typing the final entry? > If not, please, whats the minimal code to get a shortkey to launch a > selection of an item of a list and insert in the buffer? I am not sure to understand what you are trying to accomplish. Could you provide an example about it? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments
Hello, >>>>> Sébastien Vauban writes: > 1) Ask for it. > 2) Make it, answering the following questions: >- Got the docs? >- Signed them? >- Checked it? >THIS LINE DOES NOT SHOW UP in LaTeX!!! The whole list should indeed end at this line. I sent a patch correcting this. > * Other remarks > - Before, if I remember good, the sequence of list levels was: =-=, > =+=, =*=, =1.= and =1)=. Now, the last two have been inverted: > first, =1)=, then =1.=. Just a tiny detail (was used to it). I hadn't noticed that before and the doc-string of `org-cycle-list-bullet' says you are right. Fixed. > - When =S-right arrowing= this line twice, I *sometimes* get my list > items transformed into headlines... Though, I cannot repeat with as > many times as I want... Conditions still strange to me. I cannot reproduce it at the moment. Please tell me if you have more data about it. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments
Hello, >>>>> Eric S Fraga writes: > However, more strange behaviour appears as soon as you have multiple > nested lists. Just to avoid any misconception: if I get it correctly, what you do call "multiple nested lists" cannot exist. You can have nested lists, but no more than one sub-list at each level. As soon as a line is less indented than the preceding item of the list, *all* sub-lists end at that line. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments
>>>>> Eric S Fraga writes: > So you are saying, if I understand you correctly, that you cannot > have something like this: > --8<---cut here---start->8--- > 1. some text >- a nested list >- with two items >some more text for the first numbered item >- another nested list - with two items > 2. the second outer list item > --8<---cut here---end--->8--- Exactly. > If so, why not? This would seem to be quite a likely and useful > scenario. It would require a slightly different model with an added depth of complexity. To tell the truth, I had looked into this, but hadn't found a satisfying (clean) solution. For example, how should Org handle indentation of such a line, or any line within the list? Should it "round" the indentation to the closest level of a sub-list? And if you add a new line, should the user insert spaces to reach the desired level of sub-list, or should Org TAB-cycle indentation through every level of the list? Wouldn't this be painful on deeply nested lists? If the list is so long that you can't display it's first items, what happens when you want to end the 4th of 6 sub-lists? Could you remember what proper indentation is needed? Those questions are more rhetorical than anything else. My point is just that this kind of scenario, while certainly doable, would need more thought, and much more work to implement. Is it _that_ useful? > I do this all the time in latex and I was sure that I had done this > before in org. Is my recollection wrong? Was this not possible > before? As far as I remember, LaTeX exporter has never been able to parse this, though the HTML one did. Note that a TAB on your line of text was (i.e. in the latest stable release) indenting it past the second nested list item. That signifies even Org wasn't understanding properly the meaning of your list. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Hello, >>>>> Carsten Dominik writes: > Nicolas, can you in particular please take a look at this - I > believe you earlier said that you saw problems with it. Sure, I will have a look at it on Sunday. But before testing it, there is, by design, one thing that seems dangerous to me. Let's consider the following text: This is a sentence in a not so short paragraph, ending where it should not. What is this line supposed to mean for Org? If this is a recognized as a list, wouldn't this line get wrongly indented? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] problem with label in latex export
Hello, >>>>> Bastien writes: > You're right that there is a problem. > The usual way of turning radio links invisible is to comment them, > but Org comments need to be at the beginning of the line, which > breaks list indentation. (Btw, no need for the '+' in '#+' -- '#+' > is the syntax prefix for optional elements like blocks, etc.) #+ is also a valid comment syntax according to the manual. By the way, do you think lists should ignore indentation of comments, that is lines matching "^#[ \t]+"? Regards -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [Bug] Level 2 text not exported in LaTeX (well in HTML) + some comments
Hello, >>>>> Sébastien Vauban writes: > And, in the case that such a construct would not be used, I wouldn't > mind having to manually indent the paragraph where I want to place > it, as long as the indentation is used to decide to what the text > must be attached to. Please (re-)read my "rhetorical" questions: this is not as simple as it sounds. > (thinking at backward-compatibility solution) I have to disagree here, as those constructs were only partly recognized (and partly broken): again, LaTeX exporter and auto-indentation weren't aware about them. Anyway, before thinking at backward-compatibility, the design should be fixed first. Now, on the other hand, there's Carsten's "ASCII duck head" idea... Well, I still can't help thinking those constructs are ill-defined and can be avoided by reorganizing the list, or using headings. Even those do not support such constructs, for a good reason. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Hello, I've tried the patch today. There are still some easily-fixed glitches (like letters not included in org-cycle-list-bullet, or bullets allowing mixed text and numbers). But, there is apparently one major drawback, as I said in a previous post. If the line starts with a word followed by a dot or a parenthesis, Org will see a bullet there. This is bad news because the following line will be indented, or a M-RET will delete the word, replacing it with a) or a. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
>>>>> Nathaniel Flath writes: >> But, there is apparently one major drawback, as I said in a >> previous post. If the line starts with a word followed by a dot or >> a parenthesis, Org will see a bullet there. This is bad news >> because the following line will be indented, or a M-RET will delete >> the word, replacing it with a) or a. > Yes, this happens - it's not something that comes up during my > normal usage, so I didn't notice. Can you think of a way to > determine if this is the case vs. a list is actually wanted? Unfortunately, I can't see anything clean. This is tricky because lists are the closest construct to raw text. -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Hello, >>>>> Carsten Dominik writes: > Or, alternatively, put it in with an option to turn it on (default > off, I think). And maybe we should after all limit it to a single > character to avoid confusion. Yes, I do realise that I asked for > several characters - but I am learning... What will then happen if the user is cycling bullets in a 100+ items list and hits alphabetic bullets? Besides undoing that move, there's nothing much that could be done then. Further cycling would become impossible. One idea would be to count items before cycling, and skipping alphabetic bullets for lists above 26 items. It has to be carefully implemented, as it could get very heavy on computations with large lists. Also, inserting new items in an alphabetical list should check if the 27th item has been reached and change bullets back to numbers if needed. I'm sure there are others subtleties that I can't think of right now. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] buglet in org-toggle-checkbox
Hello, >>>>> Robert Goldman writes: > When I invoke org-toggle-checkbox with ^U in order to add a checkbox > to a list item that doesn't have one, I get this message in the > minibuffer: > "Invalid search bound (wrong side of point)" Patch sent to maintainers. Thank you. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
>>>>> Carsten Dominik writes: > I think it would be appropriate in this case to simply throw an > error and let the user clean up with undo. Certainly, but this still means that any 27+ items list will never be able to complete a full bullet cycle as the user will have to undo each time alphabetical bullets are reached. It could perhaps start again at letter 'a'... > Nicolas, would you *object* against a patch by Nathaniel that > implements this? You are Mr lists now, so your green light will be > needed. I wouldn't object against it as some people are finding it useful and as it won't be turned on by default (if I remember correctly). But I can't help thinking this could lead to unexpected results in some cases (admittedly less than when alpha bullets could be any size long). Regards, -- Ni^W Mr lists ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] how to reverse a region of outline items
Hello, C-c ^ A will sort the list alphabetically, in reversed order. If you do not really have A, B, etc. you can, well, add "marks" (numbers) to items with the help of `org-apply-on-list', sort the list numerically (in reversed order, with C-c ^ N), then remove the marks. Here is an example sexp to mark list: (org-apply-on-list '(lambda (c) (org-get-bullet) (goto-char (match-end 0)) (insert (format " %s" c)) (1+ c)) 0) Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] full production use of org-mode: time to say thanks again!
Hello, >>>>> Carsten Dominik writes: > On Oct 9, 2010, at 12:46 PM, Eric S Fraga wrote: >> Footnotes: [1] If I have one niggle to report it is that indenting >> text after an in-line todo doesn't seem to work properly: it >> indents any subsequent paragraphs much too far, lining up with the >> headline text for the in-line todo. This seems conceptually wrong >> to me. Not a big deal, mind you. > This is clearly a bug. Nicolas, could you be persuaded to have a > look at that? You have worked on the indentation code reently in > connection with the plain lists. I can have a look at it, but I would need an example to work on as I never use "inline todo". I don't want to sound too lazy, but could Eric provide a minimal example to get me started ? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] full production use of org-mode: time to say thanks again!
Hello,
Could you try the following patch and tell me if it fixes your issue?
As a side note (to maintainers), the second patch isn't really needed,
but I thought, while I was at it, that it would make sense
(`org-inlinetask-min-level' doesn't need to be a boolean).
Regards,
-- Nicolas
>From ab4b86b56654887be564d0519dd9e4407d9fc732 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Mon, 11 Oct 2010 08:10:31 +0200
Subject: [PATCH 1/2] Fix indentation of text after an inline task.
* org.el (org-indent-line-function): Conditionnaly indent text inside
and outside indented tasks. Also skip any list above point.
* org-inlinetask.el (org-inlinetask-in-task-p): new function.
---
lisp/org-inlinetask.el | 16
lisp/org.el| 21 ++---
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el
index fce515d..e18dce8 100644
--- a/lisp/org-inlinetask.el
+++ b/lisp/org-inlinetask.el
@@ -129,6 +129,22 @@ If prefix arg NO-STATE is set, ignore
`org-inlinetask-defaut-state'."
(end-of-line -1))
(define-key org-mode-map "\C-c\C-xt" 'org-inlinetask-insert-task)
+(defun org-inlinetask-in-task-p ()
+ "Return true if point is inside an inline task."
+ (save-excursion
+(let* ((nstars (if org-odd-levels-only
+ (1- (* 2 (or org-inlinetask-min-level 200)))
+(or org-inlinetask-min-level 200)))
+ (stars-re (concat "^\\(?:\\*\\{"
+(format "%d" (- nstars 1))
+",\\}\\)[ \t]+"))
+ (task-beg-re (concat stars-re "\\(?:.*\\)"))
+ (task-end-re (concat stars-re "\\(?:END\\|end\\)")))
+ (beginning-of-line)
+ (or (looking-at task-beg-re)
+ (and (re-search-forward "^\\*+[ \t]+" nil t)
+ (progn (beginning-of-line) (looking-at task-end-re)))
+
(defvar htmlp) ; dynamically scoped into the next function
(defvar latexp) ; dynamically scoped into the next function
(defun org-inlinetask-export-handler ()
diff --git a/lisp/org.el b/lisp/org.el
index a80286f..d9e26e9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18601,6 +18601,8 @@ which make use of the date at the cursor."
(itemp (org-at-item-p))
(case-fold-search t)
(org-drawer-regexp (or org-drawer-regexp "\000"))
+(inline-task-p (and (featurep 'org-inlinetask)
+(org-inlinetask-in-task-p)))
column bpos bcol tpos tcol bullet btype bullet-type)
;; Find the previous relevant line
(beginning-of-line 1)
@@ -18656,7 +18658,14 @@ which make use of the date at the cursor."
;; what to do.
(t
(beginning-of-line 0)
- (while (and (not (bobp)) (looking-at "[ \t]*[\n:#|]")
+ (while (and (not (bobp))
+ ;; skip comments, verbatim, empty lines, tables,
+ ;; inline tasks
+ (or (looking-at "[ \t]*[\n:#|]")
+ (and (org-in-item-p) (goto-char (org-list-top-point)))
+ (and (not inline-task-p)
+ (featurep 'org-inlinetask)
+ (org-inlinetask-in-task-p)))
(not (looking-at "[ \t]*:END:"))
(not (looking-at org-drawer-regexp)))
(beginning-of-line 0))
@@ -18675,16 +18684,6 @@ which make use of the date at the cursor."
((looking-at "\\([ \t]*\\):END:")
(goto-char (match-end 1))
(setq column (current-column)))
- ;; There was a list that since ended: indent relatively to
- ;; current heading.
- ((org-in-item-p)
- (outline-previous-heading)
- (if (and org-adapt-indentation
-(looking-at "\\*+[ \t]+"))
- (progn
- (goto-char (match-end 0))
- (setq column (current-column)))
- (setq column 0)))
;; Else, nothing noticeable found: get indentation and go on.
(t (setq column (org-get-indentation))
(goto-char pos)
--
1.7.3.1
>From 89caeaa34fb2e76626954226e51f29590ecaba91 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Mon, 11 Oct 2010 08:25:53 +0200
Subject: [PATCH 2/2] inlinetask: Make `org-inlinetask-min-level' an integer
instead of a boolean.
* org-footnote.el (org-footnote-normalize): Remove unnecessary check
for org-inlinetask-min-level.
* org-inlinetask.el (org-inlinetask-min-level): Variable is now of
type integer.
* org-inlinetask.el (org-inlinetask-in-task-p): Remove unnecessary check
for org-inlinetask-min-level.
* org-inlinetask.el (org-inlinetask-export-handler): Remove unnecessary check
for org-inlinetask-min-level.
* org-inlinetask.el (org-inlinetask-fontify): Remove unnecessary check
for org-inli
Re: [Orgmode] full production use of org-mode: time to say thanks again!
>>>>> Carsten Dominik writes: >> As a side note (to maintainers), the second patch isn't really >> needed, but I thought, while I was at it, that it would make sense >> (`org-inlinetask-min-level' doesn't need to be a boolean). > Hmmm, what happens is a user has customized this variable and it has > a value nil. I guess then your patch will break things? Probably. I wasn't sure a nil value would have any meaning and thus that anyone would set it so. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] full production use of org-mode: time to say thanks again!
>>>>> Carsten Dominik writes: >> As a side note (to maintainers), the second patch isn't really >> needed, but I thought, while I was at it, that it would make sense >> (`org-inlinetask-min-level' doesn't need to be a boolean). > Hmmm, what happens is a user has customized this variable and it has > a value nil. I guess then your patch will break things? Probably. I wasn't sure a nil value would have any meaning and thus that anyone would set it so. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] puzzling plain list and tree folding behaviour
Hello, >>>>> Brian van den Broek writes: > org-version: 7.01h emacs version: 23.1.1 ubuntu 10.04 I have not set > any org-mode variables that treat of plain lists. Many changes have been made to plain lists since 7.01h. For example, your third point is definitely gone. You may upgrade to Org git version. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Bug: ordered lists after unordered
Hello, >>>>> Richard Lawrence writes: > I think I've found a bug with the way org-meta-return behaves. I > occasionally need to follow an unordered list by an ordered list, > without any intervening text. For example: > * Some heading > - unordered > - unordered > - unordered > > 1) ordered > I am using Org version 7.01trans. This behavior has been fixed in development version of Org mode. You may upgrade. By the way, please note that, by default, you now need to insert two blank lines to separate lists (that is unless you set `org-empty-line-terminates-plain-lists' to t). Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] struggling with simple indentation
Hello, >>>>> Rainer Stengele writes: > Dear all, > I am struggling with a simple indentation problem. > Having this: (1) > > * test > - indented > line > ^ > point at "^" and pressing TAB results in: > * test > - indented > line > > Having this: (2) > * test > - indented > - indented > line > ^ > point at "^" and pressing TAB results in: > * test > - indented > - indented > line > ======== I cannot reproduce this. I always get case (1). Are you using development version ? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [PATCH] Alphabetical ordered lists
Hello, >>>>> Nathaniel Flath writes: > I think I've fixed the issues brought up with this new patch. Please > let me know what you think. I've noticed a couple of glitches. First, you are using (> 28 (length struct)) to know when to replace letters by numbers. But (length struct) doesn't always match list length, so it will lead to errors when outdenting items. For example, try outdenting, with its subtree, the item marked with "<<<" in the list below: a) etsiun b) etsiun c) etsiun d) etisun e) etsiun f) etsiun g) etsiun h) etsiun i) etisun j) etsiun k) etsiun l) etsiun m) etsiun n) etsiun a) Outdent me and my children ! <<< a) tersiu b) etsiru c) estiur d) etsnriu e) etsiun f) etiune g) etuirsnet b) etsiun o) etsiun p) etsiun q) etsiun r) etsiun s) etsiun All the lists will be numbered although they could keep alphabetical bullets. Another (lesser) problem is coming from the regexp chosen for bullets, that is "[0-9A-Za-z]+". I would suggest something alike "\\(\\(?:[0-9]\\)+\\|[A-Za-z]\\)". At the moment, you can set counter to [...@a4] and break you list when applying it. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: struggling with simple indentation
Hello, >>>>> Rainer Stengele writes: > One thing that is annoying me still: > Having > ** headline >- indent > text > ^ > and pressing "TAB" I end up with > ** headline >- indent >text >^ > but would like to have > ** headline >- indent > text > ^ > Is this configurable? Yes. The less intrusive way of obtaining this is to use C-j instead of RET after the "indent" line. If you do not want lists to rely on indentation ever, you can set `org-list-ending-method' to `regexp'. In this case, only blank lines can end a list (see variable doc-string for more information), so "text" will get back into the item after pressing TAB. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: struggling with simple indentation
Hello, >>>>> Rainer Stengele writes: > One thing that is annoying me still: > Having > ** headline >- indent > text > ^ > and pressing "TAB" I end up with > ** headline >- indent >text >^ > but would like to have > ** headline >- indent > text > ^ > Is this configurable? Yes. The less intrusive way of obtaining this is to use C-j instead of RET after the "indent" line. If you do not want lists to rely on indentation ever, you can set `org-list-ending-method' to `regexp'. In this case, only blank lines can end a list (see variable doc-string for more information), so "text" will get back into the item after pressing TAB. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: struggling with simple indentation
Hello, >>>>> Rainer Stengele writes: > Sometime I do save some an email body text under an org item. > Pasting the text under "item" leads to > * heading > - item > E-Mail body text line1 > E-Mail body text line2 > ... > Now I cannot use C-j of course. How do I easily get > * heading > - item > E-Mail body text line1 > E-Mail body text line2 > ... There is no way for Org to guess what you have in mind here (and this is why I don't like that much the "indent" method in `org-list-ending-method'). In your situation, I would use C-x r o with an adequate rectangle selection. After all, we are _also_ in Emacs. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: struggling with simple indentation
>>>>> Carsten Dominik writes: > I think it would be OK to modify the indentation code to do the most > useful thing in this case, which is indenting to under the list. Is > is OK to put the burden for terminating list by indentation on the > user. I fear that by doing this modification, we're letting in again a dreadful bug. Let me explain it. This is not the most useful thing in this case, but the most conservative one. This is needed when you want to correct indentation of a region (or the whole buffer). If we turn the behavior the other way, indenting the buffer will ruin parts of it, like before, as any text beyond a list would go inside its last item, regardless of text position. And this is worse than having to cope with some rectangle selection, because it would modify parts of buffer outside user's view. With the current behavior, what's in stays in, and what's out stays out. Another idea would be to slightly modify `org-paste-special' and `org-yank' so anything yanked inside a list is automatically put inside the item at point. The exact behavior of this has yet to be defined, though. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [patch] struggling with simple indentation
Hello, >>>>> Anthony Lander writes: > With regards to the discussion below, if I set > org-list-ending-method to 'regex The correct value is 'regexp. > it seems to get confused if there is a drawer between the headline > and the first line of text, so pressing TAB with the cursor at the > vertical bar in this example: > 8--- > ** Headline > :PROPERTIES: > :FOO: Bar > :END: > | > 8--- > Does not indent to the position under the "H" in the headline. The > TAB key silently does nothing. Same effect with the properties > drawer folded. Is it possible to indent correctly, ignoring the > drawer? Actually, this has nothing to do with the value of org-list-ending-method, but I think you are right, indentation should ignore drawers. Here is a patch to do so. Does it work for you ? Regards, -- Nicolas >From 8aa0a33e36be4593ad605d9a3c283942a275e580 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Tue, 26 Oct 2010 23:34:49 +0200 Subject: [PATCH] indentation: lines outside of drawers ignore indentation of drawers * org.el (org-indent-line-function): Ignore drawers above the current line when indenting --- lisp/org.el | 13 ++--- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index c4c64ee..edc0b74 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18704,7 +18704,7 @@ which make use of the date at the cursor." (beginning-of-line 0) (while (and (not (bobp)) ;; skip comments, verbatim, empty lines, tables, - ;; inline tasks + ;; inline tasks, and lists (or (looking-at "[ \t]*[\n:#|]") (and (org-in-item-p) (goto-char (org-list-top-point))) (and (not inline-task-p) @@ -18714,8 +18714,11 @@ which make use of the date at the cursor." (not (looking-at org-drawer-regexp))) (beginning-of-line 0)) (cond - ;; There was an heading above. - ((looking-at "\\*+[ \t]+") + ;; There was an heading or the end of a drawer above. + ((or (looking-at "\\*+[ \t]+") + (and (looking-at "[ \t]*:END:") +(ignore-errors (org-back-to-heading 'invisible-ok)) +(looking-at "\\*+[ \t]+"))) (if (not org-adapt-indentation) (setq column 0) (goto-char (match-end 0)) @@ -18724,10 +18727,6 @@ which make use of the date at the cursor." ((looking-at org-drawer-regexp) (goto-char (1- (match-beginning 1))) (setq column (current-column))) - ;; The drawer had ended: indent like its :END: line. - ((looking-at "\\([ \t]*\\):END:") - (goto-char (match-end 1)) - (setq column (current-column))) ;; Else, nothing noticeable found: get indentation and go on. (t (setq column (org-get-indentation)) (goto-char pos) -- 1.7.3.2 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Release 7.02
Hello, >>>>> Sébastien Vauban writes: > Does that mean that we must admit this will stay like that forever, > or will one try to look and see if it's possible to make that > extension? Nobody said it was impossible. For now, it is unavailable because not satisfying enough. The main difficulty isn't coming from exporters or even to make Org recognize such constructs. It is, as I already said, about user interface. How do you create such lists? How does Org is supposed to react when you ask to indent such lists? I asked others practical questions about it in a previous thread. Did you read them? Do you have some answers? What do you think about Carsten's idea to use "- @<"? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [bug] two bugs: one with comments and with exporting inline tasks
Hello, >>>>> Eric S Fraga writes: > I believe both of these problems are related to the new list > handling as I used to be able to export inline tasks perfectly fine > in September. Well, this is strange. I tried to get back to 7.01h, 7.01 and 6.36c and I obtain this same behavior. What kind of export did you use to obtain? Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] org-meta-return and lists
Hello, >>>>> Tom Short writes: > With the new list handling mechanism in v7.02, org-meta-return acts > differently for me following lists. If I hit M-RET with the cursor > in the (blank) row or two after a list, it adds another list item. > Before, I'd get a new heading (what I want), and I'd only get > another list item if the cursor is still on a line with a list when > I hit M-RET.. > Based on looking at the source of org-insert-heading and > org-in-item-p, I can reduce the behavior to within one empty row > after a list by setting org-empty-line-terminates-plain-lists to t. > Anyone know how I can go back to the previous behavior? Just use C-u M-RET to enforce an heading, wherever point is. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
