Gather to current heading (,gh) mixes up different headings

[hfs]

Gather to current heading (,gh) doesn’t work as intended. Instead of adding all marked headings as subheading of the current heading, the current heading is taken elsewhere.

Given this org file content:

* First
** Subone
** Subone
* Second
** Subtwo
* Third
** Subthree

Mark the third top-level heading: 6G,<Space>. It is marked with a > in front.

I want to move the third top-level heading below the first one. Go to the first heading and issue “Gather to current heading”: gg,gh. This is the result:

* Second
** Subtwo
** First
*** Subone
*** Subone
* Third
** Subthree

Whereas I would have expected

* First
** Subone
** Subone
** Third
*** Subthree
* Second
** Subtwo

[hsitz]

On Sun, Mar 18, 2012 at 9:37 AM, hfs
[email protected]
wrote:

Gather to current heading (,gh) doesn’t work as intended. Instead of adding all marked headings as subheading of the current heading, the current heading is taken elsewhere.

Given this org file content:

   * First
   ** Subone
   ** Subone
   * Second
   ** Subtwo
   * Third
   ** Subthree

Mark the third top-level heading: 6G,<Space>. It is marked with a > in front.

Thanks for the report. I'm pretty sure the function works properly
most of the time but that you've found an edge case -- last heading or
last line in document -- where it breaks. Regardless, I'll get it
fixed. -- Herb

[hfs]

Hi,

thanks for the quick response. I’m afraid the function does not work for me. The “current” heading will always be made a child of the first top-level heading, regardless what was marked.

Take a look at this example:

* Heading 1
** Heading 1.1
** Heading 1.2
* Heading 2
** Heading 2.1
** Heading 2.2
* Heading 3
** Heading 3.1
** Heading 3.2
* Heading 4
** Heading 4.1
** Heading 4.2

Mark heading 2: 4G,<Space>
Gather at heading 3: 7G,gh

Result: Heading 3 is made a child of heading 1

* Heading 1
** Heading 1.1
** Heading 1.2
** Heading 3
*** Heading 3.1
*** Heading 3.2
* Heading 2
** Heading 2.1
** Heading 2.2
* Heading 4
** Heading 4.1
** Heading 4.2

Expected result would be

* Heading 1
** Heading 1.1
** Heading 1.2
* Heading 3
** Heading 3.1
** Heading 3.2
** Heading 2
*** Heading 2.1
*** Heading 2.2
* Heading 4
** Heading 4.1
** Heading 4.2

Of course this is not a big issue for me.

I use VimOrganizer daily find it very useful, so thank you for all your effort!

[hsitz]

On Sun, Mar 18, 2012 at 11:59 AM, hfs
[email protected]
wrote:

Hi,

thanks for the quick response. I’m afraid the function does not work for me. The “current” heading will always be made a child of the first top-level heading, regardless what was marked.

I just did some manipulations with your sample text, all of which
worked fine for me, including your original description of what I
thought might be a problem with an edge case with final heading in
document.

I'm not sure what the problem could be.

-- Herb

[hfs]

This is a locale problem...

In my German locale sign place returns something like

--- Zeichen ---
Zeichen für /tmp/test.org:
    Zeile=7  id=7  Name=marked

This of course doesn’t match the regex in s:AssembleFileHeadingsDict().

I’m not sure if there is a solution to this? Even if you tried to make the regex more generic, you couldn’t even be sure that “Signs for” translates to two words in other languages.

As a workaround I can start Vim with an English locale and gathering works as expected.

[hsitz]

On Sun, Mar 18, 2012 at 2:32 PM, hfs
[email protected]
wrote:

This is a locale problem...

In my German locale sign place returns something like

   --- Zeichen ---
   Zeichen für /tmp/test.org:
       Zeile=7  id=7  Name=marked

This of course doesn’t match the regex in s:AssembleFileHeadingsDict().

I’m not sure if there is a solution to this? Even if you tried to make the regex more generic, you couldn’t even be sure that “Signs for” translates to two words in other languages.

As a workaround I can start Vim with an English locale and gathering works as expected.

Thanks for tracking that down. I think a workable solutiion would be
to make the regex into a global variable with default of English
locale words but settable by users in their vimrc. I have this on the
todo list. There are quite a few features that depend on parsing
output of the 'sign place' command, so I will also note issue in docs.

Thanks again,

Herb

[hfs]

While you’re at it, in s:AssembleFileHeadingsDict could you replace

if (ftest > '')

with

if (ftest ># '')

like for the other string comparisons? This may break gathering, too.

[hsitz]

Thanks very much. Vim 7.3 bug returns wrong result for empty strings
using only '>' comparison. It's patched but I don't think patch is
part of main version yet, so I should always be using '>#'. -- Herb

On Thu, Mar 22, 2012 at 1:39 AM, hfs
[email protected]
wrote:

While you’re at it, in s:AssembleFileHeadingsDict could you replace

   if (ftest > '')

with

   if (ftest ># '')

like for the other string comparisons? This may break gathering, too.

---

Reply to this email directly or view it on GitHub:
#33 (comment)