A few small issues with Sigil's formatting controls (not just 2.x)

[Vanguard3000]

I've had these two small issues for a long time now, and both involve the format and align buttons.

The first is that the formatting buttons won't work if there are already some formatting tags in effect, even if they're not the same tags. For example with the following:

<p>one two three</p>

I can select "two" and use the bold and italic buttons (or shortcuts) to add those sets of tags, but, with:

<p>one <i>two</i> three</p>

If I select "<i>two</i>" (including the tags) and try to make it bold, nothing happens. I can manually type in the tags and it works just fine, but the buttons and keyboard shortcuts do nothing. Note that I'm not suggesting you be allowed to do "<b><i>two</b></i>", but "<b><i>two</i></b>".

Similarly, with the following:

<p>blah</p>

I would expect to be able to have the cursor anywhere within the <p> block and be able to use the alignment buttons to align centre, right, etc. But if it's at the very end (between the 'h' and '<') nothing happens.

Both of these issues have existed for a long time (unfortunately I can't remember how far back), but I figured now that Sigil is in a new major it might be worth bringing up. Are these the result of a best practice I'm not aware of, or is it maybe an issue others have noticed but no one had brought up yet?

In any case, thanks in advance for the help!

[KevinH]

I will look into these two issues, but I think they are caused by the same thing:

The last one is similar to other issues that were special cased in the past. The cursor position at the end of the line just before the start of the end tag is actually an insertion pointer AFTER the bit of text meaning that spot is inside the end tag (effectively) and running that command when the cursor is in a tag is disabled.

I am betting the first problem you talked about is the same. When you select the i tag and all of its contents, even though the cursor is immediately before the tag, that spot is AFTER the text and so is considered to be in the i tag itself and you can not bold a tag - just its contents.

If I had to do it all over again, I would remove the B, I, U, subscript, and superscript buttons completely. They are just a pain to maintain. And instead, Sigil would ship with 5 pre-added clips (with clip buttons) that would be easier for the user to determine how (what tags) it wants for b, I, U to use or instead to use an in-line style tag. Then I would add a simple button to remove the immediate parent tag first to make swapping tags easier using clips.

Clips would have been a much better way to implement such things giving the user much more control yet as simple to click on as any toolbar button.

Maybe a future version of Sigil will do just that.

[Vanguard3000]

Thanks for letting me know. The whole pointer position thing seems like a weird off-by-one issue, but I'm sure it's more complicated than that or it would have been fixed as a matter of course.

I already have clips set up for smallcaps and the like, I may do as you suggested and make them for italics, bold, etc and override the keyboard shotcuts (ctrl+b etc) if possible. Clicking a second time to remove the tags isn't usually an issue for me as I use undo for that anyway.

[KevinH]

Not quite an off by one, think of the old days when a block blinking cursor was used in place of the I beam style cursor... the character immediately after the I beam would be blinking as the char to be replaced.

I-beam style cursor represented by the | char:

blah|</p>

versus old style blinking block character represented by []:

blah[<]/p>

both represent the exact same position.

But the days of the block flashing cursor are gone leading to changes is how positions in strings are thought about by the user.

But I can special case it for a future release.

[KevinH]

Okay pushed a fix for the second one where you can not align paragraph if cursor just before ending tag </

But the first one is not as easy to handle and I am not sure I consider it a bug. More of a safety feature. And, if you just select the text you can do what you want.

For example, to add <b> around the blah, you just select "blah" and it will nicely do what you want with the i on the outside and the b on the inside.

You can also do the reverse. But trying to bold a tag and not just its contents is asking for trouble.

     <p>one <i>blah</i> two</p>

If that is something you want to often, you can of course just use a clip (as you have already done).

So that is not something I am going to change.

Sorry.

[Vanguard3000]

Originally Posted by KevinH

Okay pushed a fix for the second one where you can not align paragraph if cursor just before ending tag </

Thanks, that's great to hear!

Originally Posted by KevinH

But trying to bold a tag and not just its contents is asking for trouble.

How so, if I've selected the opening and closing tags inclusive? In the example

     <p>one <i>blah</i> two</p>

If I were to select <i>blah</i> and add a bold tag, it should give me

     <p>one <b><i>blah</i></b> two</p>

just as easily as if selecting only blah would give

     <p>one <i><b>blah</b></i> two</p>

The only issue I can see is if you didn't select the entire tag block (i.e. "<i>bl" or "ah</i>") which of course would be bad.

I'm not trying to be ornery about this, and I'm fine with it not being something you're interested in changing; I'm more just interested from a learning/best practices standpoint.

In any case, thanks for everything!