0.5.0 Released

[DiapDealer]

You have to copy all three dictionary files together. You can't just toss the hyphen file in with the two pre-existing dictionary files (that came with Sigil). After unzipping the oxt file... copy the en_US.aff, en_US.dic and hyph_en_US.dic files (or en_GB.aff, en_GB.dic and hyph_en_GB.dic) to Sigil's dictionary directory.

Make sure not to mix and match with the older files. I still can't get it to work with the curly apostrophe and a user-added dictionary word though. But if the word is in the dictionary proper... everything behaves as I would expect it to. My emdashes are happy.

[ghostyjack]

Other than the suggestion that DiapDealer has given, I'm not sure what's happening with you ElMiko, all my hyphens and em-dashes are being correctly recognised.

With the files from LibreOffice.

I did completely remove all of the previous files I attempted to use, deleted my user dictionary (luckily if only had a few words in it) and restarted Sigil before adding the new files.

[GeckoFriend]

I tried to install this update today and received the following message:

Sigil-0.5.0-Windoes-x64-Setup.exe is unsafe to download and was blocked by SmartScreen Filter

I has no such issue installing the previous version so have no idea is there truly is a problem with the file or not and how to proceed in either case.

[Ahmad Samir]

Originally Posted by weedfreak

Ok libaudio2 did it thank you. Now I just need to sort out the dictionary , ideally I would like to turn it off, or failing that get it to use the three common languages I already have set up in Libreoffice. Why I should have to copy already installed dictionary files into Sigil config beats me, every other app that needs dictionaries is quite happy to use the globally installed ones.

(FWIW the Firefox binary tarball(s) does the same thing, it ships its own dictionary files and doesn't use the system provided ones. Whereas the Firefox package built by your own distro is patched/configured to use the system provided dictionary packages, that sort of integration is part of the packaging process done by distro maintainers).

[ElMiko]

@ghosty & DD - thanks for your enthusiastic efforts. I've done all those things and it's still the same story. (And as DD noted, custom words also don't work). As I said, It's obviously an international conspiracy. Or there are Gremlins in my computer. Or both.

Anyway, it's not ideal but it's still way, way better than what it was before!

EDIT: well it seems I uncovered the plot/found the gremlin -- when i was inserting em/en dashes (Alt+0151/0150), it was inserting some kind of hidden character (something like a blankspace). It just means going through and removing it via S/R. Again thanks guys for slogging it out with me.

[kiwidude]

I gave up on 0.5, gone back to 0.4.2. Too many find/replace issues - apart from the ones already mentioned I had other scenarios like for instance a regex find expression which works in 0.4.2 did not work for me in 0.5:
<style type="text/css">.*</style>

Maybe that is the new regex engine, but with a blank replace expression all that happens is the (existing 0.4.2 bug) of a blank line being inserted within the style section every time you click replace (and the style section *not* being replaced). Loaded the same book up in 0.4.2 with the exact same expression and it worked first time. It wasn't isolated - I had another major fail of Find All so my confidence is just lost with it.

Fingers crossed for 0.5.1...

[economix]

I seem to be having a problem installing 0.5 on my Ubuntu 11.10 64 bit system.

economix@economix-desktop:~$ cd Desktop/
economix@economix-desktop:~/Desktop$ chmod +x Sigil-0.5.0-Linux-x86_64-Setup.bin 
economix@economix-desktop:~/Desktop$ sudo ./Sigil-0.5.0-Linux-x86_64-Setup.bin 
[sudo] password for economix: 

This will install Sigil on your computer.  Continue? [n/Y] Y


Where do you want to install Sigil? [/opt/sigil] 

Installing Sigil...
Extracting setup files...
Error in action ExecuteAction

Error in action InstallSelectedFiles

couldn't execute "/tmp/ijtmp_84209F33-EC37-7AFC-88F6-CAB27A5AB209/installkit": permission denied
    while executing
"open $cmd"
    (procedure "::InstallJammer::actions::InstallSelectedFiles" line 129)
    invoked from within
"::InstallJammer::actions::$component $this"
    while executing
"$obj execute"
    (procedure "::InstallJammer::ExecuteActions" line 69)
    invoked from within
"::InstallJammer::ExecuteActions $action -parent $id -conditions $eval"
    (procedure "::InstallJammer::actions::ExecuteAction" line 35)
    invoked from within
"::InstallJammer::actions::$component $this"
    while executing
"$obj execute"
    (procedure "::InstallJammer::ExecuteActions" line 69)
    invoked from within
"::InstallJammer::ExecuteActions Console"
    (procedure "::InstallJammer::InstallMain" line 11)
    invoked from within
"::InstallJammer::InstallMain"
    (procedure "ThemeMain" line 2)
    invoked from within
"ThemeMain "
    invoked from within
"if {![info exists ::InstallJammer]} { ThemeMain }"
    (file "/installkitvfs/main2.tcl" line 28407)
    invoked from within
"source [file join $::installkit::root main2.tcl]"
    (file "/installkitvfs/main.tcl" line 3)
economix@economix-desktop:~/Desktop$

[Ahmad Samir]

Originally Posted by kiwidude

I gave up on 0.5, gone back to 0.4.2. Too many find/replace issues - apart from the ones already mentioned I had other scenarios like for instance a regex find expression which works in 0.4.2 did not work for me in 0.5:
<style type="text/css">.*</style>

Maybe that is the new regex engine, but with a blank replace expression all that happens is the (existing 0.4.2 bug) of a blank line being inserted within the style section every time you click replace (and the style section *not* being replaced). Loaded the same book up in 0.4.2 with the exact same expression and it worked first time. It wasn't isolated - I had another major fail of Find All so my confidence is just lost with it.

Fingers crossed for 0.5.1...

It's PCRE (the new regex engine), you can modify that behaviour: https://www.mobileread.com/forums/sho...11#post1910611

[kiwidude]

@Ahmad - thx for the link. So is it the case now that every time you want to do a multiline regex you have to put (?s) at the front of it? If so, that's... ummm, nasty.

The other find/replace operations I did of things like this:
<p class="xxx">&nbsp;</p>\s+<p class"xxx">&nbsp;</p>
worked without any (?s) so clearly I am missing something. Most of the regex operations I do in Sigil are multiline - in particular repairing broken paragraphs but also stripping repeated blank lines, replacing <br><br> separated text with proper paragraphs etc.

However I also tend to rip out those horrific giant <style> sections with hundreds of lines of utterly pointless font declarations. Or <script> sections containing javascript from html conversions that early Sigil versions couldn't cope with.

I'm not clear on when you need (?s) versus when you don't?

[Ahmad Samir]

IIUC, what (?s) does is make "." match anything including newlines.

So, this will work:
<p class="xxx">&nbsp;</p>\s+<p class"xxx">

but this won't work without (?s):
<p class="xxx">&nbsp;</p>.*<p class"xxx">

Quoting from http://perldoc.perl.org/5.8.9/perlrecharclass.html:

White space
\s matches any single character that is consider white space. In the ASCII range, \s matches the horizontal tab (\t ), the new line (\n ), the form feed (\f ), the carriage return (\r ), and the space (the vertical tab, \cK is not matched by \s). The exact set of characters matched by \s depends on whether the source string is in UTF-8 format. If it is, \s matches what is considered white space in the Unicode database. Otherwise, if there is a locale in effect, \s matches whatever is considered white space by the current locale. Without a locale, \s matches the five characters mentioned in the beginning of this paragraph. Perhaps the most notable difference is that \s matches a non-breaking space only if the non-breaking space is in a UTF-8 encoded string.

[user_none]

Originally Posted by kiwidude

So is it the case now that every time you want to do a multiline regex you have to put (?s) at the front of it? If so, that's... ummm, nasty.

That's how it should work with . and also how Python's regex works too. 0.4.2 has a very basic regex engine that did a lot of things that are completely different from what someone using Perl or Python would expect. With 0.5.0 you can pretty much use the same regex's you would in Python with Sigil.

Originally Posted by weedfreak

Why I should have to copy already installed dictionary files into Sigil config beats me, every other app that needs dictionaries is quite happy to use the globally installed ones.

Development is focused on Windows and OS X. While I could spend my time to make Linux specific changes for things like this I would rather spend my time working on features that 95% of users will actually benefit from.

[weedfreak]

My love / hate relationship over the years with Sigil is now getting to a hate / hate relationship.

Every so called 'update' has forced me to change my work process and I see very little in the way of useful features, split view horizontal is about the only positive thing I have found in this version. Search and replace is now docked at the bottom of the screen instead of floating, and wildcard search seems to have disappeared, Sigil still insists on adding unwanted sgc styles to text files and still adds dozens of blank lines between the <style type="text/css"> and /*<![CDATA[*/ lines in the head section and I still cannot delete multiple files in the book browser, all this in addition to the clunky method of moving around within files.

To be honest I do not have time to relearn how to use Sigil every update and I will probably ditch it and go back to my manual method which I know how to do simply, Sigil did seem promising as a streamlined, one stop solution but it is not worth the hassle. As user_none is not interested in Linux he will not miss me.

[meme]

Originally Posted by weedfreak

Search and replace is now docked at the bottom of the screen instead of floating

Actually, this is a great feature - it was always getting in the way before.

Sigil still insists on adding unwanted sgc styles to text files and still adds dozens of blank lines between the <style type="text/css"> and /*<![CDATA[*/ lines in the head section

I'm not sure I see issues raised on the issue log for these 2.

and I still cannot delete multiple files in the book browser

5.1 will support this.

all this in addition to the clunky method of moving around within files.

What's clunky about it? What would you like it to do?

To be honest I do not have time to relearn how to use Sigil every update and I will probably ditch it and go back to my manual method which I know how to do simply, Sigil did seem promising as a streamlined, one stop solution but it is not worth the hassle. As user_none is not interested in Linux he will not miss me.

I don't think he said he's not interested in Linux - just that his focus is on Windows/MAC and on features/issues that most people will use - and that an option for a brand new feature on the least used platform might have a lower priority. But of course, if you don't want to use the program and you've got something that works for you, great.

[kiwidude]

@Ahmad/John - thx for the further clarification. I guess I just preferred the simplicity of the "old" regex engine - I like quick, fast editing, not faffing learning more regex syntax that is crippling to type repeatedly. Any chance of what I have seen often done with other regex dialogs of a "multiline" checkbox for those of us happy to do things the way we always did?

@Weedfreak - I feel your pain and concur with some of your points (not having a separate Find dialog wouldn't bother me, if functionally the replacement was complete). I'll email John with my thoughts rather than publicly here, so he doesn't have to worry about publicly slapping me for the ones he disagrees with Hopefully given time the long list of core issues, particularly those that have *always* existed in Sigil can be sorted out soon. The cosmetic ones are trivial provided there is agreement which is always the hard part. In the meantime, 0.4.2 is the devil I know...

[weedfreak]

Originally Posted by meme

Actually, this is a great feature - it was always getting in the way before.

Good for you I do not like it at all, especially as the toc and validate results are undockable.

I'm not sure I see issues raised on the issue log for these 2.

It has been mentioned here before, it happens with almost any file I edit, especially if the file has been converted with calibre first. No idea about the issue log I did not know where it was and in any case I only get server errors from it.

What's clunky about it? What would you like it to do?

One example, the well formed error check manual correction jumps to the point in the file where Sigil thinks there is an error (it is usually wrong) if I then click in the code view pane to correct the error it jumps away from the line it thinks is wrong to my last edit point, often at the other end of the file. There are lots of other idiosyncrasies but that is the newest pain.