#1230 custom relative indentation depth of wrapped sublines

[Vic]

Although it's for Scintilla in general, I will explain based on SciTE (I currently use Geany but used SciTE and Notepad++ in the past).

wrap.indent.mode as described here allows to specify subline indent level relative to Ist subline as same (if mode 0) or same + 1 indentation level (if mode 1)
This is limitting and I suggest generalizing to any amount of indetation relative to Ist subline. In SciTE it looks like variables (properties) only accepts scalar values, so I suggest 2 variables:

1. A variable P1 to specify number ( 0 or any >0) of indentations levels beyond indentation of Ist subline.
   Thus P1 would replace/generalize both mode 0 and mode 1 above
2. A variable P2 to specify number (0 or any >0) of single spaces ( ) , beyond indentation of Ist subline.
   Thus P2 gives a more fine-grained control of that relative indentation.

Why this is important:

• My personal use case:
  I regularly use itemized lists ( and not just in Markdown), with various bullet kinds (even unicode symbols), and various spacing between the bullet sign and the text, and would like the wrapped sublines to align to the text following the bullet in Ist subline, while next indented items/nodes to indent an amount greater and INDEPENDENT of the amount the wrapped subline is indented.
  • So, with above suggestions, I would be able to create the finished looks of the list you are reading, or of follwing contents without any problems, with long wrapped lines. While with present options, that is impossible.
• It would solve several other feature requests, for other Scintilla-based editors. Tickets found on this site:
  • https://sourceforge.net/p/scintilla/feature-requests/1219/
  • https://sourceforge.net/p/scintilla/feature-requests/1108/

[Neil Hodgson]

[feature-requests:#1219] was committed. SciTE's documentation hasn't been updated.

Deleted [feature-requests:#1229].

[Vic]

Hi Neil, thanks for the quick reply.
From reading [feature-requests:#1219] , it only covers the need for an indentation of the sublines bigger than 1 beyond the level of Ist subline.
It does not cover the need in itemized lists, which requires variable P2 described in this request: an indentation beyond prev subline but smaller than full indent width/tab, hence measured in unit-spaces. This is similar to soft wrap hanging indent in Atom editor's Settings/Editor.

[Neil Hodgson]

My reply was covering the last point: that the change would address outstanding tickets.

The change doesn't fully address [feature-requests:#1108] either as that requires some notion of treating 'prefix text' (such as "-" or "*" for Markdown but, as you say, 'various bullet kinds') separately from 'body text'. Even where the prefix text is always a single constant value, its width may be different from some number of space characters. Its likely that more complex structures like numbered lists "(1);(2);..." may also be wanted.

[Vic]

The change doesn't fully address...

I guess you mean change suggested by this ticket?

Even where the prefix text is always a single constant value, its width may be different from some number of space characters.

But with what I suggest in this ticket, the width would be the same in a monospaced/fixed-width font, wouldn't it? For proportional fonts, one would could achieve an approximation.
Or else, I'm not sure I understand what you meant.
By "P2 " above I meant giving users ability to choose their own arbitrary number of space characters , by hand in the configuration/properties files, just like now one can specify wrap.indent.mode to be 1 or 2.

Or maybe you meant that , in Markdown, the prefix text is not the same # of characters in width everywhere in the same document: * for itemized list, and 1. for numbered list. Then, yes, I agree that my ticket would not fully solve that. But it is very close to.
Ex, I with my suggestion, if I put a single space after both * and 1., and choose wrapping at prev indent level + 2 space characters, I would get:

* adsfasd as asdf 
  asdf asdf aad a
  a asda dasdf asdf


1. asdfas asdf asfd 
  asd asd asd 
  asdf adf adf asf asd

Or I could get used to always put 2 spaces after * (I use a snippet for my bullets) but 1 space after 1. , and set wrapping at prev.level + 3 spaces, and then the wrapped text looks consistent everywhere.

All in all, it's not a perfect solution (nothing is) but still much better what we have currently, and I guess the programming effort is much less than what's required to recognize any possible prefix text.

[Neil Hodgson]

Itemized lists are just one type of text that may be wrapped. Wrapping that makes the body of a list item line up nicely will make other elements wrap with an unexpected extra indent. [feature-requests:#1108] tries to make the wrap position sensitive to its context which is likely better for most circumstances although the implementation in #1108 is too inflexible.

Since SCI_SETWRAPSTARTINDENT uses average character width, that would be more consistent than space character width. A simpler API change would add a SC_WRAPINDENT_RELATIVE mode that reused the SCI_SETWRAPSTARTINDENT value for the indentation past SC_WRAPINDENT_SAME in average character widths.

With proportional fonts, the start of body text is not an integral number of spaces from the start of the prefix text so defining extra indentation in pixels would allow matching more closely.

[Vic]

Hi Neil,

I agree with everything you wrote ( I did not know " average character width ... would be more consistent than space character width" -- I guess for proportional fonts).

I got an idea for [feature-requests:#1108] , I posted it there as reply, please read it there ( however it's not just for Markdown; let me know if it's better to put it under this post ).

With proportional fonts, the start of body text is not an integral number of spaces from the start of the prefix text so defining extra indentation in pixels would allow matching more closely.

True and useful (although, a bit more tedious for the user to compute, and s/he will have to change it when he changes the font family in use).

A simpler API change would add a SC_WRAPINDENT_RELATIVE mode that reused the SCI_SETWRAPSTARTINDENT value for the indentation past SC_WRAPINDENT_SAME in average character widths.

Just one suggestion:
Instead of adding yet another mode, why not just keep the current number of modes (values 0, 1, 2, 3 ,as I see on https://www.scintilla.org/ScintillaDoc.html#SCI_SETWRAPINDENTMODE ) , but modify the effect of modes 1, 2, and 3 as follows:

Symbol	Value	Effect
SC_WRAPINDENT_FIXED	0	Wrapped sublines aligned to left of window plus amount set by SCI_SETWRAPSTARTINDENT
SC_WRAPINDENT_SAME	1	Wrapped sublines are aligned to first subline indent, plus amount set by SCI_SETWRAPSTARTINDENT
SC_WRAPINDENT_INDENT	2	Wrapped sublines are aligned to first subline indent plus one more level of indentation, plus amount set by SCI_SETWRAPSTARTINDENT
SC_WRAPINDENT_DEEPINDENT	3	Wrapped sublines are aligned to first subline indent plus two more levels of indentation, plus amount set by SCI_SETWRAPSTARTINDENT

Since mode 0 and any other mode are mutually exclusive, there should not be any conflict in using same SCI_SETWRAPSTARTINDENT value ; when user changes SCI_SETWRAPINDENTMODE value, he will also cahnge SCI_SETWRAPSTARTINDENT as needed.

It seems to me very consistent, and gets you covered shall in future arrise need to combine SCI_SETWRAPSTARTINDENT with the other possible relative indentations (modes 2 and 3).

Another alternative would be to let first mode to take value -1; and the other modes --value x where x is 0 or 1 or 2 or 3, with effect:
"Wrapped sublines are aligned to first subline indent plus x more level of indentations (where x can be 0, 1, 2 or 3 ) plus amount set by SCI_SETWRAPSTARTINDENT "
But I guess this alternative may get complaints from users which are already using current wrap mode values.

[Neil Hodgson]

Changed status as "committed" means it is ready to be closed when the next release is made.

[Vic]

:) the only options I had for Milestone when creating this ticket were:
Completed
Won't implement
Commited
Duplicate

Maybe it was a joke from those who made that menu :)

[Vic]

Hi Neil, I did not know you are the one who could change those options for "milestone", see the reply I got from creating this ticket https://sourceforge.net/p/forge/feature-requests/667/

[Neil Hodgson]

I managed to add "Committed" in the past but I can't work out how to do so with the current SourceForge site design.

[Vic]

You could bug the SourceForge site admins about that, just like I did