What Features or Tools does Sigil Still Need Yet?

[BeckyEbook]

2. Enable automatic selections for common editing operations based on cursor position for CV editing (Bold, Italic, Headings, etc)

Let me remind you so shyly that adding tags has stopped working.
The last commits from the end of December changed something, and then nothing, and it doesn't work right now. Then you moved to a new CSS parser, but those improvements to Code View have been discontinued.

Inserting tags (B, I, U etc.) works in bare BODY, but not in paragraphs.

For example, try to bold or italicize any word in the code:

<p>This is an example text paragraph.</p>

[KevinH]

Yes, lots of rework has been done in CV but I obviously broke something. Thank you for letting me know it was broken! Fixing the whole wrong CSS removal took quite a lot of work and so took me away from rewriting the CV editor.

I am on it.

Originally Posted by BeckyEbook

Let me remind you so shyly that adding tags has stopped working.
The last commits from the end of December changed something, and then nothing, and it doesn't work right now. Then you moved to a new CSS parser, but those improvements to Code View have been discontinued.

Inserting tags (B, I, U etc.) works in bare BODY, but not in paragraphs.

For example, try to bold or italicize any word in the code:

<p>This is an example text paragraph.</p>

[KevinH]

And please do not be shy about bug reports! Fixing bugs always helps improve Sigil and this bug appears to be a doozy.

[KevinH]

Hmm... Those functions call ToggleFormatSelection and that is actually one of the routines in CodeViewEditor I have not touched, so I have no idea why it is broken.

[BeckyEbook]

I don't remember when exactly it stopped working, but the very first commit on December 18 made the tagging different.
Certainly, this group of commits is suspicious (image).

I did not report it before - after all, the work was "in progress", the changes were significant, and I stopped understanding them.

[Thasaidon]

Originally Posted by KevinH

Okay to bring this thread to a close, here is what my to-do list looks like based on these discussions. No promises mind you but ..

Already In the Next Release (Sigil-1.5.0)

1. Add tag begin end pair highlighting to CV
   
2. Enable automatic selections for common editing operations based on cursor position for CV editing (Bold, Italic, Headings, etc)
   
3. Enable Saved Searches to read in from csv and text files to automate search and replace (ala Atlantis WP similar feature)
   
4. Enable Nav to include of role="doc-toc" on nav toc and similarly for page-list

On the List for Future Versions of Sigil (no particular order and no promises)

1. Add Indicator in Status Bar if epub in old Sigil "Standard Format" or Preference to force load into old format
   
2. Split updating of manual into workable sections and ask for volunteers
   
3. Basic Table-based Metadata Editor with an "advanced" button to go to current one
   
4. Allow users to create their own replacement functions in python3 for Search and Replace
   
5. Add a regex validator to validate regex expressions used in Find and Replace
   
6. Add a flag to limit search to Find in only Open Tabs
   
7. Make Saved Searches keep track of all the search flags they were used with (by saving options flags)
   
8. Make default Shortcuts be smart about use of alt on international systems that use/need alt and altgr
   
9. Flag to control writing of Sigil version to metadata (under consideration only since doable via plugin)
   
10. Some form of supported templating for HTML TOC and Index generation (under consideration but doable by plugin)
    
11. Multiple paragraph justification setting via the CV alignment icon (although PageEdit does this now)
    
12. Add a tool/icon to automatically remove matched begin/end tags based on cursor position in either start or end tag
    
13. Add a regex to be used to build TOC when no headings tags exist (considering but this is against accessibility, as headings are important.)
    

Thank you for this update as to where Sigil is going.

And thank you even more to you and DiapDealer for all the work you put into Sigil. It is much appreciated.

[KevinH]

I fixed that ToggleFormatSelection routine to actually make sense and work when it checks if the selection end was in a tag. The original code had an off by one as the end() points *past* the last character selected (much like python substrings ranges are done).

So with this change, all of the Bold, Italic, etc started working for me.

I have NO IDEA how the original code actually worked at all. It was broken from the very beginning.

I think my actually fixing the detection of being in a tag has exposed this issue.

Please try a pull from master and let me know if you still run into any trouble.

Thanks!

Originally Posted by BeckyEbook

I don't remember when exactly it stopped working, but the very first commit on December 18 made the tagging different.
Certainly, this group of commits is suspicious (image).

I did not report it before - after all, the work was "in progress", the changes were significant, and I stopped understanding them.

[BeckyEbook]

The issue could only be seen by personally compiling the development build, not the stable build, so it wasn't such a problem. I rarely put tags with B, I, U… so I waited for further work. On the other hand, you rarely commit something that doesn't work later and I was able to get your attention faster.

Back to the recent changes. It's nice, but on December 18th I noticed that adding tags around a word works ALMOST always well:

• at the beginning of the word: OK
• in the middle of the word: OK
• at the end of a word: OK except for one case - immediately after this word there is an opening or closing tag

I am attaching an animated GIF that shows these cases.

And here is the test line of text (I marked in red the places where surrounding by html tag does not work).

<p>micro|<b>computer|</b></p>

Perhaps applying a similar solution you have been using recently here would help.

[Ashjuk]

May I respectfully remind of the problem I suffered where words I was trying to add to the default dictionary were in fact being added to a temporary book specific dictionary, and subsequently were deleted when I removed that dictionary.

[KevinH]

Auto selecting of a word is only designed to work when the cursor is actually in a word not after a word. Your last case the cursor is after the word and nothing is autoselected. That is how it was designed to work. Highlighting a word and then selecting the format is the normal way this is handled. The auto selection of a word *under* the cursor is Qt not us.

The key is that for a word to be under the cursor the cursor must be in one of the positions indicated by the '|' below, not after the word (one spot for each letter).

|w|o|r|d



So to me it appears to work as expected. What am I missing?

Kevin

Originally Posted by BeckyEbook

The issue could only be seen by personally compiling the development build, not the stable build, so it wasn't such a problem. I rarely put tags with B, I, U… so I waited for further work. On the other hand, you rarely commit something that doesn't work later and I was able to get your attention faster.

Back to the recent changes. It's nice, but on December 18th I noticed that adding tags around a word works ALMOST always well:

• at the beginning of the word: OK
• in the middle of the word: OK
• at the end of a word: OK except for one case - immediately after this word there is an opening or closing tag

I am attaching an animated GIF that shows these cases.

And here is the test line of text (I marked in red the places where surrounding by html tag does not work).

<p>micro|<b>computer|</b></p>

Perhaps applying a similar solution you have been using recently here would help.

[KevinH]

That code was untouched from earlier versions and I am not seeing that issue, but perhaps I am not reproducing exactly the sequence of steps you do.

So please provide a step by step set of instructions so that I can see exactly what you are seeing.

Is all of this being done from the spellcheck dialog itself or from a menu? Are the words all in one language or many? Do you have multiple dictionaries set (ie both Primary and Secondary dictionaries or only primary). Are you changing from default to a new wordlist in the Sigil Preferences or someplace else? How exactly are you telling it which wordlist to use, in the SpellCheck dialog itself?

Thanks,

Kevin

Originally Posted by Ashjuk

May I respectfully remind of the problem I suffered where words I was trying to add to the default dictionary were in fact being added to a temporary book specific dictionary, and subsequently were deleted when I removed that dictionary.

[Ashjuk]

Originally Posted by KevinH

That code was untouched from earlier versions and I am not seeing that issue, but perhaps I am not reproducing exactly the sequence of steps you do.

So please provide a step by step set of instructions so that I can see exactly what you are seeing.

Is all of this being done from the spellcheck dialog itself or from a menu? Are the words all in one language or many? Do you have multiple dictionaries set (ie both Primary and Secondary dictionaries or only primary). Are you changing from default to a new wordlist in the Sigil Preferences or someplace else? How exactly are you telling it which wordlist to use, in the SpellCheck dialog itself?

Thanks,

Kevin

Kevin,

1. Is all of this being done from the spellcheck dialog itself or from a menu? - from the menu that pops-up when you right-click a word.

2. Are the words all in one language or many? - English only.

3. Do you have multiple dictionaries set (ie both Primary and Secondary dictionaries or only primary) - Primary only (English - Great Britain)

4. Are you changing from default to a new wordlist in the Sigil Preferences or someplace else? - Not sure what you mean. I don't think I am changing from default just adding a new wordlist specific to the book I am working on. (img)

5. How exactly are you telling it which wordlist to use, in the SpellCheck dialog itself? - I am not using the spellcheck dialog, this is when working in code-view and right-clicking on an underlined word.

When right-clicking on an underlined (misspelled) word you have the following options:

1 - Add To Default Dictionary

2 - Add to Dictionary > (which lists the dictionaries available( img))

If I select option 1 the word does NOT get added to default, but to (as in this case) Bell.

Surely if the options 1 and 2 were correct the word should have been added to default NOT Bell.

If I remove 'Bell' any words that I then add to default using option 1 are saved correctly. The 'slang' dictionary I added does not seem to have any effect on the operation of saving to default.

Hope that makes it a bit clearer.

https://www.mobileread.com/forums/at...1&d=1611847769

[KevinH]

I rarely use the CV menus for spellchecking and was doing all of my testing in the SpellCheck Dialog itself and that all appears to work as expected. I will try to recreate what you are seeing with using just the CV menus. If I can recreate the issue, I should be able to fix it.

Thanks,

Kevin

[Ashjuk]

Thanks Kevin.

Here is what I do if anyone else wishes to try it.

1. Open any book
2. Go to Edit/Preferences/Spellcheck Dictionaries
3. Click on Add and create new dictionary for the book.
4. Open any chapter.
5. In code-view right-click any underlined misspelt word.
6. Click on Add To Default Dictionary.
7. Check in code-view that word is no longer underlined.
8. Go to Edit/Preferences/Spellcheck Dictionaries and remove the dictionary created at step 3.
9. Close and return to code-view and check word again.

If the word is once again underlined it shows that the word was added to the dictionary created for the book and not the default as per the menu.

[DiapDealer]

Originally Posted by Ashjuk

When right-clicking on an underlined (misspelled) word you have the following options:

1 - Add To Default Dictionary

2 - Add to Dictionary > (which lists the dictionaries available( img))

If I select option 1 the word does NOT get added to default, but to (as in this case) Bell.

Surely if the options 1 and 2 were correct the word should have been added to default NOT Bell.

I think a big part of the confusion here is that "Bell" IS your default user dictionary. As indicated by the text "Default dictionary: Bell" in the lower portion of the dialog you posted an image of in your above post.

And since "Bell" and your default dictionary are in fact one and the same, it is only natural there is no difference between choosing to add to the default user dictionary, or choosing to specifically add it to the "Bell" user dictionary.

Selecting a user dictionary in the preferences and then clicking 'OK' makes that dictionary the default directory (check out the tooltip when mousing over a blank area in the user dictionary list). There is no all-time-default user dictionary--even if it happens to be named "default". Just rename it something other than "default" if you want to avoid confusion.