Hi, doku of `org-insert-heading' says: ,---- | If point is not at the beginning, do not split the line, | but create the new headline after the current line. `---- which sounds wisely. Unfortunately function behaves different, splits line uses it's following part to create the new headline from, an inconvenience, resp. bug IMHO. Also tex-info endorses that: ,---- | When this command is used in | the middle of a line, the line is split and the rest of the line becomes | the new headline@footnote{If you do not want the line to be split, | customize the variable `---- Seems something across anyway. Suggest to restore/enable the behaviour of the doku-string. Could send a patch. Interesting to read the reason for this change/difference anyway, so maybe I change my opinion too... Thanks all Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/
Hi Andreas, On Oct 15, 2010, at 7:38 PM, Andreas Röhler wrote: > > Hi, > > doku of `org-insert-heading' says: > > ,---- > | If point is not at the beginning, do not split the line, > | but create the new headline after the current line. > `---- > > which sounds wisely. > > Unfortunately function behaves different, splits line > uses it's following part to create the new headline > from, an inconvenience, resp. bug IMHO. > > Also tex-info endorses that: > > ,---- > | When this command is used in > | the middle of a line, the line is split and the rest of the line > becomes > | the new headline@footnote{If you do not want the line to be split, > | customize the variable > `---- > In fact, splitting the line is the intended behavior, and there is a variable to change that. I have updated the docstring of the command. - Carsten > Seems something across anyway. Suggest to restore/enable the > behaviour of the doku-string. Could send a patch. > > Interesting to read the reason for this change/difference anyway, so > maybe I change my opinion too... > > Thanks all > > > Andreas > > -- > https://code.launchpad.net/~a-roehler/python-mode/python-mode- > components > https://code.launchpad.net/s-x-emacs-werkstatt/ > > > _______________________________________________ > 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
Am 16.10.2010 07:30, schrieb Carsten Dominik: > Hi Andreas, > > On Oct 15, 2010, at 7:38 PM, Andreas Röhler wrote: > >> >> Hi, >> >> doku of `org-insert-heading' says: >> >> ,---- >> | If point is not at the beginning, do not split the line, >> | but create the new headline after the current line. >> `---- >> >> which sounds wisely. > >> >> Unfortunately function behaves different, splits line >> uses it's following part to create the new headline >> from, an inconvenience, resp. bug IMHO. >> >> Also tex-info endorses that: >> >> ,---- >> | When this command is used in >> | the middle of a line, the line is split and the rest of the line >> becomes >> | the new headline@footnote{If you do not want the line to be split, >> | customize the variable >> `---- >> > > In fact, splitting the line is the intended behavior, and there is a > variable > to change that. > > I have updated the docstring of the command. > > - Carsten > Hi Carsten, as far as your time permits, would think it's useful to keep this point for a style discussion. For me, that's a classical way Emacs handles things, but it's a classical fault too. The reason, why Emacs is censored having a steep learning curve, get its rumour being difficult is just here IMHO. Well, OTOH success of Emacs and org-mode itself are against me. Finally I use Emacs myself, so it can't be that grave. So what's wrong writing programs that way at this point? I'll leave the answer open for now. Want to see if I'm the only way raising that concern. Meanwhile I use the variable.... Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ > >> Seems something across anyway. Suggest to restore/enable the >> behaviour of the doku-string. Could send a patch. >> >> Interesting to read the reason for this change/difference anyway, so >> maybe I change my opinion too... >> >> Thanks all >> >> >> Andreas >> >> -- >> https://code.launchpad.net/~a-roehler/python-mode/python-mode-components >> https://code.launchpad.net/s-x-emacs-werkstatt/ >> >> >> _______________________________________________ >> 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 > >
Aloha all, With the following Org mode file, there is a dead space where org-insert-heading doesn't do anything. In the following example, if the point is on either of the empty lines marked [dead space] no heading is created. Is this behavior intended? * Folded heading ... [dead space] [dead space] * Heading All the best, Tom -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Hi Thomas,
tsd@tsdye.com (Thomas S. Dye) writes:
> With the following Org mode file, there is a dead space where
> org-insert-heading doesn't do anything. In the following example, if the
> point is on either of the empty lines marked [dead space] no heading is
> created.
>
> Is this behavior intended?
I can't reproduce it... anyone?
--
Bastien
Hi Bastien, Bastien <bzg@gnu.org> writes: > Hi Thomas, > > tsd@tsdye.com (Thomas S. Dye) writes: > >> With the following Org mode file, there is a dead space where >> org-insert-heading doesn't do anything. In the following example, if the >> point is on either of the empty lines marked [dead space] no heading is >> created. >> >> Is this behavior intended? > > I can't reproduce it... anyone? I looked more closely and found that the behavior I described happens when the folded material ends in a list. If I end the list by adding some regular text, then I get the expected behavior. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Hi Thomas,
tsd@tsdye.com (Thomas S. Dye) writes:
> I looked more closely and found that the behavior I described happens
> when the folded material ends in a list. If I end the list by adding
> some regular text, then I get the expected behavior.
Confirmed -- I quickly looked, it seems that `org-in-item-p' should do
a better job when preceeded by invisible text.
--
Bastien
Hello,
Bastien <bzg@gnu.org> writes:
> Confirmed -- I quickly looked, it seems that `org-in-item-p' should do
> a better job when preceeded by invisible text.
I need to rewrite this function.
Anyway, I'm not sure what you mean in your last sentence because, as
a low-level function, its results shouldn't be affected by folding
status of the document (I didn't follow the thread closely, though, and
could be off tracks).
Regards,
--
Nicolas Goaziou
Hi Nicolas,
Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> Confirmed -- I quickly looked, it seems that `org-in-item-p' should do
>> a better job when preceeded by invisible text.
>
> I need to rewrite this function.
>
> Anyway, I'm not sure what you mean in your last sentence because, as
> a low-level function, its results shouldn't be affected by folding
> status of the document (I didn't follow the thread closely, though, and
> could be off tracks).
The problem is this one:
* Folded subtree...
^-{ Point here
then M-x org-insert-heading RET will *not* insert a heading if the
folded subtree is ending with a list, because `org-in-item-p' will
infer point is within a list.
So maybe `org-insert-heading' should be fixed instead, as a higher
level function, ignoring the folded content before the point?
--
Bastien
On 14.11.2013, at 23:53, Bastien <bzg@gnu.org> wrote: > Hi Nicolas, > > Nicolas Goaziou <n.goaziou@gmail.com> writes: > >>> Confirmed -- I quickly looked, it seems that `org-in-item-p' should do >>> a better job when preceeded by invisible text. >> >> I need to rewrite this function. >> >> Anyway, I'm not sure what you mean in your last sentence because, as >> a low-level function, its results shouldn't be affected by folding >> status of the document (I didn't follow the thread closely, though, and >> could be off tracks). > > The problem is this one: > > * Folded subtree... > > ^-{ Point here > > then M-x org-insert-heading RET will *not* insert a heading if the > folded subtree is ending with a list, because `org-in-item-p' will > infer point is within a list. I think it is dangerous to change the behavior in such a way that it will depend on the heading being folded or not. Definitely org-in-item-p should not depend on that. I am still debating with myself if org-insert-heading should. Maybe only in interactive use or something like that. Dangerous territory. - Carsten > > So maybe `org-insert-heading' should be fixed instead, as a higher > level function, ignoring the folded content before the point? > > -- > Bastien >
Hi Carsten,
Carsten Dominik <carsten.dominik@gmail.com> writes:
> I think it is dangerous to change the behavior in such a way that
> it will depend on the heading being folded or not. Definitely org-in-item-p
> should not depend on that. I am still debating with myself if org-insert-heading
> should. Maybe only in interactive use or something like that.
> Dangerous territory.
My rather simple take on this is that org-insert-heading should ignore
the context (like a list) when it's invisible, at least interactively.
2 cents of course,
--
Bastien
Question concerning the behaviour of org-insert-heading;
The manual states the following.
>>
If the command is used at the end of a folded subtree (i.e., behind the
ellipses at the end of a headline), then a headline will be inserted after
the end of the subtree.
<<
However at least in my installation (Emacs 34.3, org-mode 8.2.10), the new
heading is created prior to the ellipses.
For example
* Heading folded...
^ cursor here, then M-<RET> results in the following.
* Heading folded
* ...
^ cursor here
Luke Crook <luke <at> balooga.com> writes:
> However at least in my installation (Emacs 34.3, org-mode 8.2.10),
Emacs 24.3 obviously.
Hello,
Luke Crook <luke@balooga.com> writes:
> Question concerning the behaviour of org-insert-heading;
>
> The manual states the following.
>>>
> If the command is used at the end of a folded subtree (i.e., behind the
> ellipses at the end of a headline), then a headline will be inserted after
> the end of the subtree.
> <<
>
> However at least in my installation (Emacs 34.3, org-mode 8.2.10), the new
> heading is created prior to the ellipses.
>
> For example
>
> * Heading folded...
>
> ^ cursor here, then M-<RET> results in the following.
Point is /before/ the ellipses here. You need to move after them, e.g.,
using C-f or mess with `org-special-ctrl-a/e'.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes: > > Point is /before/ the ellipses here. You need to move after them, e.g., > using C-f or mess with `org-special-ctrl-a/e'. > > Regards, > OK thanks. I understood "behind the ellipses at the end of a headline" as "before" the ellipses, not "after". But I still don't think it works as it is meant to. Org creates a new list item in the folded heading if the last line is a list item. Otherwise org creates a new heading at the same level as the folded heading. So * TEST<cursor here, then M-enter> - skfjdskjfs gives the following * TEST * <cursor here> - skfjdskjfs But * Test...<cursor here, then M-enter> gives the following * TEST - skfjdskjfs - <cursor here> Also the following won't create a new header or list item at all. * TEST... <cursor here, then M-enter> Doesn't do anything
Luke Crook <luke <at> balooga.com> writes:
>
> * TEST...
> <cursor here, then M-enter>
>
> Doesn't do anything
>
The above I cannot consistently reproduce. So ignore for now.
Thanks.
Luke Crook <luke@balooga.com> writes:
> But I still don't think it works as it is meant to.
>
> Org creates a new list item in the folded heading if the last line is a
> list item. Otherwise org creates a new heading at the same level as the
> folded heading.
>
> So
>
> * TEST<cursor here, then M-enter>
> - skfjdskjfs
>
> gives the following
>
> * TEST
> * <cursor here>
> - skfjdskjfs
>
> But
>
> * Test...<cursor here, then M-enter>
>
> gives the following
>
> * TEST
> - skfjdskjfs
> - <cursor here>
>
> Also the following won't create a new header or list item at all.
>
> * TEST...
> <cursor here, then M-enter>
>
> Doesn't do anything
This should be fixed. Thank you.
Regards,