Lists and headings related issues and feature proposals

[lethefrost]

Hi there @SpacePiggy17 @k4a-l , thanks for the work on #37 . I believe there are some issues with this PR:

1. some logs you guys forgot to remove from debugging

     console.log({
       principleText,
       leadingMarkersRegExp,
       chunk,
       m: removed.match(leadingMarkersRegExp),
       removed
     });

2. and in the settings description it uses the term "headers", where the accurate term is "headings" (many people use these two terms interchangeably! This is a common confusion). "Header" in typesetting is a concept corresponding to "footer", appearing at the top of a page; In programming, it also refers to the part associated with function or method declarations/signatures, such as C/C++ header files. "Heading" is the term for describing documents' titles and subtitles.

Also, I wish we could have something more:

1. Currently, it only works for bullet/unordered lists starting with - , and doesn't work in bullet lists starts with * or + . It doesn't work for numbered/ordered lists syntaxes 1. or 1) or checkbox lists either. For checkbox lists starting with - [ ], it breaks the checkbox syntax by inserting # in between - and [ ] (making - # [ ] contents).
   • Even the original Heading Shifter before this PR, the style remover feature on converting a line to a heading, doesn't work for + , * (if italic remover is turned on, it's recognized and get removed as italic syntax), 1) , and all checkbox syntaxes.
   • I hope to extend the scope to cover the aforementioned lists.
2. I do love this idea of using the same shortcuts of setting heading levels to control list indentation levels as well, but I personally don't need the heading syntaxes inside lists items. I hope we can add an option to control whether the shortcuts insert #s into the list items, or only act on setting the indentation to a certain level.
3. I hope we can create a seamless and continuous shifting experience between lists and headings. For example, if we set an upper limit of heading level (like the current "lower limit of heading" setting), on any heading shifting action where a heading will be indented beyond that upper limit, it is converted into a list; And vice versa, outdenting a first level list item will make it a heading at current level (or 1 level deeper than the current, can be configured).

For example, outdenting on the following list will produce:

Original:

- H1.1
  - H2.1
  - H2.2
    - H3
- H1.2

Outdented once:

# H1.1
- H2.1
- H2.2
  - H3
# H1.2

Outdented twice:

# H1.1
## H2.1
## H2.2
- H3
# H1.2

And if we have an upper limit of H6, then an example of indenting could be like:

Original:

# H1
## H2
### H3
#### H4
##### H5
###### H6

Indented once:

## H1
### H2
#### H3
##### H4
###### H5
- H6

Indented twice:

### H1
#### H2
##### H3
###### H4
- H5
  - H6

I had made some local scripts to do this years ago, but I was too lazy to clean my code and write descriptions so I procrastinated for years and never publish it, but I use it every day, and I believe this could be very useful to many of you too. I think it would be a good fit to integrate into your Heading Shifter now, since starting from this #37 PR its functionality scope starts to involve and interact with lists. If you'd like, I'd be happy to make some PRs for all the aforementioned fixes or new features. Please let me know what you think about them☺️ Thanks for any comments or feedback!

[k4a-l]

I did not implement the shift between lists and headings because I believe they are not necessarily contiguous.
In my actual use case, these two never interact with each other.
However, I do acknowledge the value in this.

The three issues I can think of at the moment are as follows:

1. Increased number of behavior options
   Although we've already incorporated Add Auto Indent Bulleted Headers Feature #37, I'd prefer not to increase the number of behavior branches based on options. Well, this shouldn't be a problem if implemented properly.

2. Whether to consider the existing Headings number during lists->headings conversion

Original:

# H1
- list1
  - list2

Outdented once:
A？

# H1
# list1
- list2

B？

# H1
## List1
- list2

3. Reimplementation of obsidian-outliner

Since I didn't want to get into list processing, the current “Auto Outdent” is also implemented via hotkeys.

obsidian-heading-shifter/src/utils/editorChange.ts

Lines 64 to 68 in 2cfe9bc

	const modifiers: ModifierKey[] = [];
	if (settings.autoOutdent.hotKey.shift) modifiers.push("Shift");
	if (settings.autoOutdent.hotKey.ctrl) modifiers.push("Ctrl");
	if (settings.autoOutdent.hotKey.alt) modifiers.push("Alt");
	simulateHotkey(settings.autoOutdent.hotKey.key, modifiers);

It's not as simple as just increasing or decreasing the number of \s.

---

To reiterate, I believe it's worth implementing as a feature.
PRs are welcome.

[lethefrost]

I did not implement the shift between lists and headings because I believe they are not necessarily contiguous. In my actual use case, these two never interact with each other. However, I do acknowledge the value in this.

The three issues I can think of at the moment are as follows:

1. Increased number of behavior options
   Although we've already incorporated Add Auto Indent Bulleted Headers Feature #37, I'd prefer not to increase the number of behavior branches based on options. Well, this shouldn't be a problem if implemented properly.
2. Whether to consider the existing Headings number during lists->headings conversion

Original:

# H1
- list1
  - list2

Indented once: A？

# H1
# list1
- list2

B？

# H1
## List1
- list2

3. Reimplementation of obsidian-outliner

Since I didn't want to get into list processing, the current “Auto Outdent” is also implemented via hotkeys.

obsidian-heading-shifter/src/utils/editorChange.ts

Lines 64 to 68 in 2cfe9bc

const modifiers: ModifierKey[] = [];
if (settings.autoOutdent.hotKey.shift) modifiers.push("Shift");
if (settings.autoOutdent.hotKey.ctrl) modifiers.push("Ctrl");
if (settings.autoOutdent.hotKey.alt) modifiers.push("Alt");
simulateHotkey(settings.autoOutdent.hotKey.key, modifiers);
It's not as simple as just increasing or decreasing the number of \s.

To reiterate, I believe it's worth implementing as a feature. PRs are welcome.

Hi, thank you for your feedback!

For contiguous shifting, I believe I mentioned in

... And vice versa, outdenting a first level list item will make it a heading at current level (or 1 level deeper than the current, can be configured).

the A or B (btw, I believe this is an outdentation, not indentation. Did you write "indented once" by mistake or was that intended?) can be made as a setting configured by users so they can decide which behavior they want?

Since you welcome such PR, I will try to look into it later when I have some free time!

For (3), I am not sure if I fully understand what you mean. I haven't enabled or used that feature yet. What's the reason for the dependency on obsidian-outliner, and what's the difference between obsidian-outliner's Shift + Tab behavior and the built-in Shift + Tab outdentation? I'd appreciate it if you could please elaborate a bit more. Thank you!

[k4a-l]

Did you write "indented once" by mistake or was that intended?

Indent was a mistake for Outdent (corrected)

---

can be made as a setting configured by users so they can decide which behavior they want?

I'd rather not do that if possible.
Come to think of it, if indent shifts to h6->list1, wouldn't outdent shift to list1->h6 instead of list1->h1?

---

Regarding point 3, the wording was incorrect.
What I meant was that if we implement this feature, it might be necessary to implement it as a built-in function rather than relying on external indent and outdent functions (from obsidian or obsidian-outliner).
But maybe it's not that difficult after all

[lethefrost]

Did you write "indented once" by mistake or was that intended?

Indent was a mistake for Outdent (corrected)

Regarding point 3, the wording was incorrect. What I meant was that if we implement this feature, it might be necessary to implement it as a built-in function rather than relying on external indent and outdent functions (from obsidian or obsidian-outliner). But maybe it's not that difficult after all

Thanks for the clarification!

can be made as a setting configured by users so they can decide which behavior they want?

I'd rather not do that if possible. Come to think of it, if indent shifts to h6->list1, wouldn't outdent shift to list1->h6 instead of list1->h1?

How about making outdented first level list item a heading of current level+1 (as you already implemented for Heading Shifter's "Insert Heading at one level deeper")? So when outdentation shifts lists to headings, the heading level is determined by its context.

For example, if the shifting command is executed on the following selection:

# H1
## H2

[selection begins]
- list1
  - list2
    - list3
- list4
  - list5
[selection ends]

outdent once:

# H1
## H2

[selection begins]
### list1
- list2
  - list3
### list4
- list5
[selection ends]

twice:

# H1
## H2

[selection begins]
## list1
### list2
- list3
## list4
### list5
[selection ends]

Does that make sense? 🤔

[k4a-l]

How about making outdented first level list item a heading of current level+1 (as you already implemented for Heading Shifter's "Insert Heading at one level deeper")? So when outdentation shifts lists to headings, the heading level is determined by its context.

As a standalone operation, I think that's better.

My concern is that indent and outdent operations become irreversible.

# H1
## H2

[selection begins]
- list1
  - list2
    - list3
- list4
  - list5
[selection ends]

outdent once:

# H1
## H2

[selection begins]
### list1
- list2
  - list3
### list4
- list5
[selection ends]

indent once:

# H1
## H2

[selection begins]
#### list1
- list2
  - list3
#### list4
- list5
[selection ends]

Even after indenting following an outdent, it does not revert to its original state.
And if we want to maintain reversibility, the correct behavior is as follows:

Come to think of it, if indent shifts to h6->list1, wouldn't outdent shift to list1->h6 instead of list1->h1?

Even with standard list processing, outdenting from the top level may not revert to its original state, but this seems quite different from that.

- list1
  - list2
    - list3 

outdent once:

- list1
- list2
    - list3 

indent once:

  - list1
  - list2
    - list3 

[k4a-l]

I was looking for reasons not to do it, but this feature seems worth implementing anyway.
If you can create a pull request, it would be helpful if you could create it from the test cases.

Currently, it is structured for simple functionality, so it is acceptable to modify the file structure.

[lethefrost]

I was looking for reasons not to do it, but this feature seems worth implementing anyway. If you can create a pull request, it would be helpful if you could create it from the test cases.

Currently, it is structured for simple functionality, so it is acceptable to modify the file structure.

Ahhh, I see. I now get what your concern is. That's true, the reversibility would be something we need to consider carefully for a consistent user experience. And you are right as well about the in/outdentation on pure list items wouldn't revert either. Thank you for pointing them out, they are indeed worth many attentions🤔 When I have some time later and start working on it, I'll let you know if I run into some problems so we can discuss the details there!

[codey-badger]

hi guys
cool ideas, I hope to see the final implementation in the near future.