Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

6.3 failings

johann
2013-02-25
2013-04-05
1 2 > >> (Page 1 of 2)
  • johann
    johann
    2013-02-25

    1.) 'replace' is broken:
    replace '><' with '>\n<' does just that ... the special '\n' is not substituted with an EOL
    2.) 'file open' is caching the file list and not re-reading the directory when re-used. i.e., if you last opened a file from x:\y\z and move a new file into that directory with another app and then go to open that file, it will not be visible. the only way to find it is to choose the parent directory (or any directory, save the current one) and then re-select the original child and the file list then is properly re-read from disk.
    3.) 'find' is broken:
    find 'zzz' (NOTE: 'zzz' is file-unique) zooms to it and momentarily stops, but then roars on to somewhere further down in the file.
    4.) long-time problem 'alt-tab' windows switcher ignoring:
    the longer one uses notepad++, the more windows alt-tab switcher becomes a mere tab insert into the data ... very agrevating! of course, the win+click works fine, but is much more cumbersome that alt-tab when working just between two (2) apps.

    there may be other issues, but these caused me to step back a couple of versions so i could get back to work.

    --
    thank you,

    johann

     
  • Loreia2
    Loreia2
    2013-02-25

    Hi Johann,

    1. you can use regular expression mode to achieve desired result
    2. Find works just fine for me, and I use it on daily basis. In fact I use it all the time. Can you reproduce the same issue on a ZIP version of N++?
    3. ALT+TAB and CTRL+TAB again work just fine, and always have been working file.

    Can you try to reproduce these issues with plugins disabled (or with a ZIP version without plugins)?

    BR,
    Loreia

     
  • 1) I can confirm this is a regression in "Extended search mode", which happened somewhere between 6.2.3 and 6.2.3r3. Loreia/Dave/Don, is there someone already working to fix this?

    2) I cannot reproduce that problem under XP SP3, nor under 7 Home SP1. The open dialog is immediately updated, even if the dialog is opened while moving the file. Under which OS you have this weird behavior? Is this a networked drive?

    As for Loreia, I never had problems like 3) or 4).

     
  • Don HO
    Don HO
    2013-02-26

    Hi François, replacing '\n' doesn't work not only in extended but also in regex mode.
    "Replacing '\n'" not working is due to the following condition is not satisfied:


    // If the next find is the same as the last, then perform the replacement
    if (nextFind.cpMin == currentSelection.cpMin && nextFind.cpMax == currentSelection.cpMax)
    {

    Have you any suggestion about fix?

    Don

     
    Last edit: Don HO 2013-02-26
  • bypasser
    bypasser
    2013-02-26

    Shell extension seems to be broken. There's no more entry in the context menu, and when trying to register it manually, it results in the following error message: 'The module "NppShell_05.dll" was loaded but the call to DllRegisterServer failed with error code 0x80004005'.

     
  • bypasser
    bypasser
    2013-02-26

    Sorry. Too early reported. I've just debugged the NppShell_05.dll binary and RegCreateKeyEx returned "Access Denied" when trying to create the registry key HKCR\*\shellex\ContextMenuHandlers\ANotepad++ . But this was silently caused by my local proactive defence.

     
    Last edit: bypasser 2013-02-26
  • johann
    johann
    2013-02-26

    update:
    1.) replace was using 'extended mode'
    2.) file open was in a std win disk dir
    3.) find was being used as always worked before
    4.) alt-tab has been a problem for many versions now

    using vista 32 SP2

    i am back to 5.9.8 which restores items 1-3 to operability

    i am going to close off the plugins and see if this has an affect. i did notice that some 5-6 plugins were updated as the result of the version upgrade when it was applied.

    --
    thank you,

    johann

     
  • johann
    johann
    2013-02-26

    no plugins:
    1.) replace still literally inserts extended chars into the data
    2.) file open is now re-reading the disk directory each time it is utilized
    3.) find is 100%
    4.) amazingly, alt-tab now appears to be 100% reliable. i am not a user of the ctrl-tab facility, but this seems to be working reliably as well.

     
  • johann
    johann
    2013-02-26

    just as an aside, it would be, i believe, welcomed for npp to follow the windows "convention" and to have an 'about' line under the 'windows' tab indicating the version et cetera.

     
  • Hi Don,
    There are two "problems" with '\n': the problem people are complaining about, and the problem you are pointing at.

    I will first say that the meaning of '\n' is "Line feed", not "End of line". It usually does not make sense to use '\n' by itself with Windows end of lines, and if we do not permit to select only the '\n' in '\r\n', the selection will not match what we were searching for, and thus the "Replace" button will not work. "Replace all" will work but will only replace the '\n' in '\r\n', which is what the expression tells. So, in regex mode, the search string should usually use '\R', not '\n'. Extended mode does not currently support '\R', so '\r\n' has to be used to find Windows end of lines. Note that I verified and Scintilla permits to set a selection on only the '\r' or only the '\n' in '\r\n', and replacing that selection will only replace the selected character, but will not display the selection on only one character; it will display no selection when the '\r' is selected and will display a selection on both when the '\n' is selected. If we want to be able to replace '\n' or '\r' one by one, in Windows end of lines, with the "Replace" button, we should change how we select found text, without rounding positions outside of multibyte character sequences.

    As for the problem people are complaining about, is using '\n' in the replace string, not the search string. With latest Notepad++, in "extended" mode, any escape sequence in the replace string will replace text with the raw character sequence when using the "Replace" button, instead of replacing with the cooked (interpreted escapes) text. In "regex" mode, it is correctly cooked.
    Of course, with Windows end of lines it does not really make sense either to use '\n' in the replace string. Note that '\R' is not supported in the replace string since it is a wildcard for an end of line of any format (win/unix/old mac), not a defined sequence. Maybe we should define it as "current end of line format" when used in the replace string.

     
  • Hi Johann,
    Notepad++ follows the Windows "convention" to have an "about" item in the "help" menu, and that menu being the last on right. In Notepad++, the "help" menu is named "?", and I have no objection with that name since in several applications they use a "?" icon for help.

     
  • johann
    johann
    2013-02-26

    i must be missing something here. because, to me, the issue is all about continuity.

    i preponderately use utf8 files with *nix EOL. the appropriate insertion of the '\n' into the data was never a question ... it just worked through -- at least -- 5.9.8. i might point out that the same is true for the other "extended chars" which are now just being inserted literally (i.e., '\t' et alii). certainly, this is not what is intended!

    moreover, through 5.9.8 i was able to use '\n' as a find, replace, and/or insert of extended chars in ANSI files using ANSI EOL ... all without fanfare.

    --
    thank you,

    johann

     
  • johann
    johann
    2013-02-26

    frboyer:

    forgive my blatant oversight, you are perfectly right.

    --
    thank you,

    johann

     
  • Just to sum up here, so I know what I'm supposed to be fixing :)

    1. There is definitely a bug in the replace string in extended mode, not replacing the "extended" characters. This simply needs fixing, and should be trivial.

    2. In regex mode, François' detailed explanation explains it all. Although there is an inconsistency with "Replace", as it isn't consistent with either "Find Next" or "Replace All". This should probably be fixed if possible, but as François already explained - that could be a tricky decision, and changing the way in-between line endings are handled will result in many more cases breaking.

    3. To reply to Johann's point, I don't think this is a consistency issue. The difference between 5.9.8 and 6.0 was not a small bug fix, but a major upgrade in the ability of the regex feature. I think the version number increment, not to mention the release notes show this to be a major change in the software. 6.2.3 to 6.3 was also more-or-less a rewrite of the find/replace code, hence the major version update. 6.3 is now much more consistent with how "standard" regex functions that 5.9.8. For an example, try the line in 5.9.8 - "ababab test ababab", and search ([ab]*). Find next finds the ababab, then no further find nexts work. Replace all, and N++ goes into an infinite loop and freezes.

    Dave.

     
  • johann
    johann
    2013-02-26

    i guess my confusion here stems from the fact that most of my editing using this excellent product involves modifying sometimes large xml/svg files and the more mundane system config files from day-to-day requirements. for me to 'replace' '\n\n' with '\n' in any file has been a comfort since the npp intelligence has been coded in to recognize '\n' as the in situ 'newline' and not the sole possession of a particular file storage type. if would appear to me that losing this "intelligence" is not much of an advance.

    i do realize that the regex ball-of-wax has to ultimately relate to the PCRE-type world, it just seems that the age-old usages have a place as well.

    --
    thank you,

    johann

     
  • Don HO
    Don HO
    2013-02-26

    Hi Dave,

    There is definitely a bug in the replace string in extended mode, not replacing the "extended" characters. This simply needs fixing, and should be trivial.

    Agree.

    In regex mode, François' detailed explanation explains it all. Although there is an inconsistency with "Replace", as it isn't consistent with either "Find Next" or "Replace All". This should probably be fixed if possible, but as François already explained - that could be a tricky decision, and changing the way in-between line endings are handled will result in many more cases breaking.

    IMO, it's a bug. if replacing '\r' works perfectly under windows, then replacing '\n' (line feed) should does as well. Otherwise it brings the confusion to users. But I understand that it could be complex to deal, so fix it or not it's your call.

    Don

     
  • Hi Dave and Don,

    I had a quick look at it, and there is no "tricky decision" to do which might break something, since in 6.2.2 and even 5.9.8 it was selecting only the '\n' in '\r\n' and nobody was complaining. We only need to have the same behavior as before, but with the new code. Of course, some automated tests on that side of the search engine would simplify this kind of modification.

     
  • THEVENOT Guy
    THEVENOT Guy
    2013-03-03

    Hi Dave, François,

    For various reasons, I was a bit " far for N++" ! So, from last Thursday, I
    started to test again the PRCE engine with the Notepad++ 6.3.0. version.

    As I said before, the calltip to see the zero length match is genial!
    Thanks to François-R Boyer.

    The gestion of empty lines is OK and the behaviour of the " Replace "
    button looks more coherent.

    I noticed two bugs about Find/Replace, in "Regex" mode, with Notepad++ 6.3.0
    ( One major and one minor ! )

    1) It's impossible to replace the SEARCH string by the NUL character, in any form
    it's written in the replacement dialog ( \x00, \x{00} , \x{0000} , \0 ... )
    Actually, the replacement delete the SEARCH string.

    As, it's also impossible to use the "Extended" mode because of the issue
    about the escaped sequences, in N++ 6.3.0 only, you just can use the
    Character's Panel to insert the NUL character manually !

    2) When the Regex in the Search dialog is invalid ( for example \d+\1 ) :

    If I press the "Find Next" or the "Replace" button, I get the normal
    box message " Invalid regular expression".

    But, if I press any other button of the Find/Replace windows,
    ( Count, Mark , ...), I get, instead, the message 0 matches.
    without any warning message !

    In addition to these 2 bugs, I also noticed some odd things which are a bit specific.
    These behaviours did exist before the 6.3.0 version and may be resolved later !

    Some BEHIND ASSERTIONS ( \<, \b ... ) and LOOKBEHINDS didn't work, in some cases :

    For example in the given search 'N++ 630' the SEARCH of \<\d shoud select the
    "6" digit ONLY ( Start of a word ). Actually, it also matches the
    digits "3" and "0" !

    Moreover, the "Replace" button doesn't work at all if there's a positive LookBEHIND
    in Search dialog. By chance, with the "Replace All" button, it's all OK !

    For example, we are searching an upper "B" letter, preceded by a upper "A"
    letter => (?<=A)B and we want to replace the letter "B" by the string '000'
    If we click the "Replace" button many times, each occurrence of the SEARCH is
    found, but not replaced !

    Cheers

    guy038

    PS :

    I didn't see the "Extended" mode issue because I don't generally
    use this
    mode. Indeed, we can do almost the same search/replacements in "Regex" mode

    I agree that, "Extended mode" is better than "Regex" mode, ONLY
    if we want manage characters in theirs binary or decimal form :

    For example : the form \d{065} stands for the upper letter "A",
    and the form \b00011011 stands for the Escape character !

     
    Last edit: THEVENOT Guy 2013-03-06
  • Hi Guy,

    1) The problem with null characters was known, maybe we should have listed current limitations. There is also a known problem with Unicode points outside the BMP. I have a development version in UTF32, but not yet with all features we would expect (character classes are not working).

    2) This interface bug should be easy to correct.

    For the behind..., I would have to look more to see if we can easily support it correctly, and even support overlapping lookbehind with end of previous match (this might be more difficult).
    The simple "replace" not working with lookbehind should be corrected with the same correction used to have replacement of '\n' work correctly, if Dave or myself have time to do it correctly. Thanks for your report, this was not known, and will probably change the way we solve the problem with '\n'; my automated tests are currently on the engine only, not the GUI, and thus has not detected these problems even though these simple replacements were tested.

     
  • Hi, sorry I've been quiet for a bit, my weekend was mostly taken up with Day-Job.

    As such, I've only just had chance to look into this. As expected, the extended replace was just a missing line, must have been missed with the initial patch. Apologies.

    The \n search in regex mode I've fixed as follows: we used to disallow any search result that started in the middle of a line end marker (ie. between \r and \n), now, I just disallow zero length matches between \r and \n. This keeps the old behaviour, but allows searching for \n<SOMETHING> or just \n on it's own. Replace and replace all in this work as expected. I've done very limited testing on this, so I'd appreciate it if people could test it again. Links at the end.

    The lookbehind issue I kinda knew about, but I said from the outset that I wasn't spending too much time worrying about lookbehinds for replace mode. Sorry if that wasn't clear. Of course tests would be nice for this sort of thing, but at the moment it's beyond the time and resources I'm willing to invest to refactor the Find/Replace code to support tests (there's a lot of gui goodness mixed in with the logic). For the lookbehind to work with replace, we need to bring the "has the selection or document changed since the last search" code through to the n++ side, then I don't need to perform the search again to check it still matches. I've started to implement this before, then François implemented the Scintilla version, and his version is a lot neater than mine, and makes the N++ code significantly simpler. My current standpoint is that lookbehinds with replace should be implemented when the regex is done by N++, not scintilla, and there are tests in place. If François or anyone else has any better ideas then great, but it's beyond my skill set to work out how else to do it.

    As for the count / mark all not shouting about an invalid regex, I'll take a look at that hopefully tomorrow - that should be pretty straightforward as François said.

    Patch here: https://sourceforge.net/p/notepad-plus/patches/459/

    Binary: http://www.brotherstone.co.uk/npp/npp63r1.7z

    About box says 6.3r1 - should be used with a SciLexer.dll from 6.3.

    Many thanks,
    Dave.

     
  • Don HO
    Don HO
    2013-03-06

    Dave,

    Thank you for the patch, the fix has been committed in SVN.

    Regarding lookbhind replacement: after some tests, both lookahead and lookbhind replacement work with your binary. I don't see any extra work is needed on this issue, or am I missing somethings?

    Don

     
    Last edit: Don HO 2013-03-06
  • THEVENOT Guy
    THEVENOT Guy
    2013-03-06

    Hello Dave, Francois and all,

    I downloaded the 6.30rc1 version yesterday and, as I'm not working
    this Wednesday, I started to test this beta version.

    1)

    I chose the 18 cases of SEARCH below :

    .{0}     ( NULL length string )
    ABCDEF ( simple string )
    \r         ABC\r         \rDEF         ABC\rDEF
    \n         ABC\n         \nDEF         ABC\nDEF
    \r\n       ABC\r\n       \r\nDEF       ABC\r\nDEF
    \n\r       ABC\n\r       \n\rDEF       ABC\n\rDEF

    and the 18 cases of REPLACEMENT below :

    NOTHING ( REPLACEMENT dialog EMPTY )
    TUVXYZ   ( simple string )
    \r         TUV\r         \rXYZ         TUV\rXYZ
    \n         TUV\n         \nXYZ         TUV\nXYZ
    \r\n       TUV\r\n       \r\nXYZ       TUV\r\nXYZ
    \n\r       TUV\n\r       \n\rXYZ       TUV\n\rXYZ

    and I try ALL the possibilities of SEARCH-REPLACEMENT, in
    Regex mode

    ( 18 x 18 = 324 cases exactly ! So I'm not far from madness !!! )

    Conclusion : ALL these S/R do the job correctly ( Whaaoo ! )

    I didn't want to start again this Hercule' work in Extended mode
    but I did do some tests, at random ( about 20 ) and everything
    is also OK !

    For users, just remember you can create an \r or \n character,
    without Character Panel, very easily :

    Just hold DOWN the 'ALT' key and type successively on the :

    '0', '1' and '0' numeric pad key to produce an \n character
    '0', '1' and '3' numeric pad key to produce an \r character

    to get this character at cursor position

    In a WINDOWS file, with EOL = \r\n, as François said in a previous post :

    • the SEARCH of \n, ONLY, selects both \r AND \n characters
    • the SEARCH of \r, ONLY, selects NOTHING but make current line
      the line where \r is found

    But, don't be mistaken about this fact ! Despite this WRONG display,
    it does select the ONLY character \n or \r. To be convinced,
    just replace \r or \n by, let say, the string '123' => the result is :

    \r
    123 if \n had been replaced by '123'

    and

    123\n if \r had been replaced by '123'

    So, despite this odd display, the SEARCH-REPLACEMENT is quite OK

    However, if we 're searching for \n\r, ( the INVERSE of \r\n )
    we may get a strange behaviour !

    Given the TWO lines ABCDEF\r\n, followed by an EMPTY line \r\n
    in a NEW file :

    The SEARCH of \n\r displays the selection the \r\n at the END
    of the FIRST line, after 'ABCDEF'. But, indeed, it selects the
    \n character at the VERY END of the FIRST line and the \r
    character at the BEGINNING of the following EMPTY line.

    Again, to be convinced, just make any REPLACEMENT => It's OK

    To sum up, and up to now, I can't see any error. Thanks to Dave and
    François for all the work done !

    2)

    I confirm that the replacement of a searched string by an NULL
    character, is still IMPOSSIBLE, in regex or extended mode.

    If the REMPLACEMENT string is, for example, 'ABC\0DEF', then
    the SEARCH string is changed into the string 'ABC' only

    May be, we must live with this limitation and use an external
    tool to do this kind of replacement which, I agree, is not
    very common !

    3)

    It's about 18h00 and I'm going, now, to collect all the odd
    results about backward anchors and negative lookbehinds

    For all these specific problems could be connected and can help
    you, Dave, François or anyone else to find out a correct solution
    for the globality !

    Cheers

    Guy038

     
    Last edit: THEVENOT Guy 2013-03-06
  • Hello Guy, Dave, Don, all...

    Handling NULL everywhere is not always easy, as several Scintilla functions use NULL terminated strings.
    For search and replace, I now have a version of the regex engine working with NULL characters in both the search string and the replace string, and both in the form of an escape sequence (e.g. \0) or directly in the string (not tested in the GUI, as neither "copy/paste" nor alt+0 work with NULL characters). This version also handles Unicode outside BMP correctly, and has a new character class [[:inval:]] to match invalid UTF-8 sequences and invalid code points. It does not support Unicode character classes, as it would require a library which is several times bigger than N++.

    For lookbehinds, as Dave said, the "replace" button does not work as the selected text does not match the expression (the engine is not rewinding from the search start position to test for lookbehind), and instead the test should be done with "selection has not changed" as I have written. As it is right now, I'm not willing to switch the search code from SciLexer.dll to notepad++.exe, for lack of test environment on the .exe side. I think it would currently be better to have the .exe ask the .dll if the selection has changed. Do we need the .exe to be compatible with the "original" Scintilla compiled from their repository, or could it be only compatible with the "enhanced" Scintilla compiled for N++?

     
  • Me again, with good news for lookbehinds... I modified two lines in my new search code, and now:

    • The "replace" button works with lookbehinds, using latest notepad++.exe from Dave.

    • Overlapping lookbehinds work, e.g searching for (?<=a)ba* in aabaaaba will correctly find the baaa and ba (for which the lookbehind part overlaps the end of previous match).

    So now it supports "real lookbehind", where searching looks to the left of the start position to check for a possible match of lookbehind.

     
  • That's great news - can we see the patch? :) How does it know how far to lookbehind, are there any limitations?

    Just for clarity, I didn't mean it lightly when I said to move the search to N++ - that was the longer term plan to completely refactor search such that it's testable, add tests, and basically do it properly. It's not a quick fix. However, it does need doing. There's too much code for search/replace and too many edge cases to do this without tests. But, as I said before, I'm not willing to put the work in to refactor the current model to allow for tests - I'd rather rewrite the search with N++ "knowing more" about what's happening in the search, in a testable way.

    Probably now irrelevant, but just watching selection / document changes probably isn't enough, because the document could be changed such that the selection still matches, and hence should still be replaced.

    From François' patch, I assume we'll need to update the N++ code to handle NULLs properly, and use the relevant length-including APIs from Scintilla.

    If this goes into the next release, is this looking more like a 6.4 than a 6.3.1?

    Cheers,
    Dave.

     
1 2 > >> (Page 1 of 2)