Nicolas Goaziou writes:
> Thank you for the suggestion,
Thank you for consideration and implementation.
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
__
> Achim Gratz writes:
> But I sustain the suggestion for instead of a space
> character. :-)
Done. You may need to use -f flag.
Thank you for the suggestion,
--
Nicolas
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to t
Nicolas Goaziou writes:
> Checkboxes are not boldened anymore since that patch. They are
> enclosed in tags. You may be, somehow, looking at old code.
Indeed I was on a branch that hadn't been fully merged with your latest
changes, sorry for the confusion. But I sustain the suggestion for
ins
Hello,
> Achim Gratz writes:
> Nicolas Goaziou writes:
>> I've pushed a change in that direction. Unchecked boxes do not rely
>> anymore on visibility:hidden style property.
> Looks OK, but the space should probably be replaced by to
> avoid possible tearing of the checkbox. The regex for
Achim Gratz writes:
> I've found some time today to install the new-struct branch at my work
> machine. Things look good so far and the checkboxes have started to
> work again. :-)
I've since been working with the code (and doing the occasional pull)
without noticing any ill effects. I'd like t
Nicolas Goaziou writes:
> I've pushed a change in that direction. Unchecked boxes do not rely
> anymore on visibility:hidden style property.
Looks OK, but the space should probably be replaced by to avoid
possible tearing of the checkbox. The regex for matching does not
catch "[-]", which expl
Hello,
> Karl Maihofer writes:
> This does not work for me. Lists in inline tasks are still exported
> as follows:
> *
> item 1
> *
> item 2
> What do I miss?
Well, nothing. I just pushed a small patch to remove unneeded newline
characters. It does help a bit in you situation.
Though,
Nicolas,
Nicolas Goaziou gmail.com> writes:
> > 2. Lists in inline tasks are not exported properly (item 2a in the
> > example below).
>
> This should be fixed now. Thanks.
This does not work for me. Lists in inline tasks are still exported as follows:
*
item 1
*
item 2
What do I miss?
R
Hello,
> David Maus writes:
> The non-breaking space in an unchecked item would not (necessarily)
> be as wide as the X in a checked item. But a checkbox list that does
> not align is in my eyes far better than unchecked items that appear
> as checked when viewed w/o CSS.
I've pushed a chang
Nicolas Goaziou writes:
> I think folding and filling should behave better now. You will need to
> force a branch update, as I rebased the repo against master.
Works wonderfully well with the limited testcase I have here at home. I
expect it will do just as well with my stuff at work, I'll let y
Hello,
> Karl Maihofer writes:
> I do have another issue when I export inline tasks:
> 1. If the inline task doesn't have a "headline", there is an empty
> space before the content of the inline task. I think in earlier
> versions it wasn't there. See item 2 in the example below. I
> sometim
> Karl Maihofer writes:
> It seems as if the list in the inline task confuses the cycle
> functionality.
Folding has been fixed, but you will need to use "git pull -f".
Regards,
--
Nicolas
___
Emacs-orgmode mailing list
Please use `Reply All' to
Hello,
> Achim Gratz writes:
> Also, fill-paragraph doesn't know about inline text unless you are
> using blank lines atop. That's probably to be expected, but in case
> there's something one can do about it I'd like to know - I'd like to
> have no blank lines if possible.
I think folding an
At Thu, 27 Jan 2011 21:39:03 +0100,
Nicolas Goaziou wrote:
>
> > The unfinished checkboxes and progress cookies are not boldened as
> > they are in Orgmode itself and putting a hidden "X" inside the not
> > begun checkboxes is somewhat tenous as the "hidden" attribute might
> > not be honored (as h
Nicolas Goaziou writes:
> You did not open a new list. By default, 2 blank lines are required to
> end a list. In fact, you just added a new item to the previous list,
> separated from others by a blank line. M-RET tries to be smart and
> separate items with a blank line from that point.
Ah, OK -
Hello,
> Achim Gratz writes:
> 1) If you open a new list after another list, M-RET will not produce
> a new list item, but yet another new list:
> --8<---cut here---start->8---
> - list 1
> - entry
> - more entries
> - list 2 <-- M-RET
> - <-- is produc
Nicolas Goaziou writes:
> Lists in drawers (or blocks, or inline tasks) are, now, completely
> unrelated to outer parts of the buffer. Even though you make it look
> like the list in the drawer is in continuity of the other one, it is
> not the case. As a corollary, boxes in such a list cannot be
Nicolas,
I found another bug. When I put the cursor on item 2 in my example and
cycle through with TAB, I get the following:
TAB once:
- item 2...
another TAB:
- item 2
***
Inline Task without a "headline"
*** END
- item 2a... (=> item 2b is missing!!)
th
Nicolas,
thanks, demoting works now as expected.
I do have another issue when I export inline tasks:
1. If the inline task doesn't have a "headline", there is an empty
space before the content of the inline task. I think in earlier
versions it wasn't there. See item 2 in the example below.
Hello,
> Achim Gratz writes:
> There's another regression with regards to checkboxes vs. the "old"
> 7.01h that I've noticed. If sublists are put into drawers, then
> checkboxes depending on that sublist are not updated with your new
> version and progress boxes on that sublist will always be
Hi Nicolas,
Nicolas Goaziou writes:
[...]
I've found some time today to install the new-struct branch at my work
machine. Things look good so far and the checkboxes have started to
work again. :-)
I've briefly switched on alphabetical lists and that has worked quite
well on the lists I tried i
Hello,
> Karl Maihofer writes:
> Pressing M- with the cursor on "Item 2" in the example below
> inserts a space before the inline task, so that it's no longer
> recognized as a task.
> - Item 1
> - Item 2
> - Item 2.1
>
> *** Inline Task
> Text
> *** END
>
> -
Nicolas,
Nicolas Goaziou gmail.com> writes:
> I would like to announce, and submit to discussion, some list code
> upgrades. So, let me introduce the changes done in development branch:
Great! Thanks a lot. I just tested the inline task part and have an issue with
demoting of list items, please
Hello,
> Achim Gratz writes:
> Just been trying to do a make, there are a few undeclared items you
> may want to check upon:
Compiling should be clean now. Thank you.
Regards,
--
Nicolas
___
Emacs-orgmode mailing list
Please use `Reply All' to s
> Bernt Hansen writes:
> I tried reproducing it too and failed...until I added 2 blank lines
> BEFORE the list.
Ok. Spotted and fixed. Thanks to Carsten and you.
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Ema
Nicolas Goaziou writes:
> http://github.com/ngz/org-mode-lists.git
Thanks, that works nicely - should be working fine from work I guess.
Just been trying to do a make, there are a few undeclared items you may
want to check upon:
In org-in-item-p:
org-list.el:443:41:Warning: reference to free va
Nicolas Goaziou writes:
> Hello,
>
>> Carsten Dominik writes:
>
>>> In original patch, bullet type was passed to HTML and DocBook
>>> exporters. I removed that part of the code for various reasons.
>
>> I am not sure if I understand this. What was passed through in the
>> original patch, and
Hello,
> Achim Gratz writes:
> Can I access through http://, as I'll be behind a firewall for
> testing?
I guess you can clone instead:
http://github.com/ngz/org-mode-lists.git new-struct
> Also, the repository is a clone of the orgmode.git, so your branch
> should work as a remo
Nicolas Goaziou writes:
> While Bernt Hansen helped me a lot already, some more testing would
> be appreciated. The repository is at:
>
> git://github.com/ngz/org-mode-lists.git new-struct
>
> It supersedes "recursive-lists" branch, submitted to the ML a few
> weeks ago.
Can I a
> 2) There is now support for finite alphabetical lists, thanks to
> Nathaniel Naff.
Oops, I meant Nathaniel Flath.
-- Nicolas
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.
30 matches
Mail list logo
