I left some posts in the BASIC group documenting some problems with Ver 7 but
have not had any replies so I hope they have been noted.

I just found a problem with FIND in ver 7 pre-release 2 that I hope someone will
verify.  If I don't start getting some answers or verification of problems I
find, I will have to go back to Ver 6 and let someone else do the testing.

I want to match all the spaces at the start of each line. When I do a FIND on
the following data for ^\x20+, it matches from the second space up to and
including the 'a'. Find Next matches from the third space up to and including
the 'a'. After a few more tries, it matches just the 'a'. The next find matches
the '1' of '100'.

       a 100
       mov ax,0040
       mov ds,ax
       or byte ptr [0017],40
       mov ah,1
       int 16
       mov ax,4c00
       int 21

Please tell me it's not something stupid I'm doing.

Joy

I put 4 spaces in front of your lines, and it all worked properly for me. Did
you have regex selected?

Also, I keep hoping for a find 'up' in addition to down and all. If you happen
to go past the thing you're looking for,
in a 200 kb file, you have to either start over, or select 'all' and hope it
restarts at the top, which it does not
always do in the released version. We need to be able to search up, often we
just want to see if the same thing exists
are an earlier point in the file without having to start at the beginning, every
time.

Regards,
John
RecipeTools Web Site:  <http://recipetools.gotdns.com/>
http://recipetools.gotdns.com/

From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of
joy8388608
Sent: Wednesday, April 04, 2012 10:07
To: ntb-clips@yahoogroups.com
Subject: [Clip] Version 7 FIND problems


I left some posts in the BASIC group documenting some problems with Ver 7 but
have not had any replies so I hope they
have been noted.

I just found a problem with FIND in ver 7 pre-release 2 that I hope someone will
verify. If I don't start getting some
answers or verification of problems I find, I will have to go back to Ver 6 and
let someone else do the testing.

I want to match all the spaces at the start of each line. When I do a FIND on
the following data for ^\x20+, it matches
from the second space up to and including the 'a'. Find Next matches from the
third space up to and including the 'a'.
After a few more tries, it matches just the 'a'. The next find matches the '1'
of '100'.

a 100
mov ax,0040
mov ds,ax
or byte ptr [0017],40
mov ah,1
int 16
mov ax,4c00
int 21

Please tell me it's not something stupid I'm doing.

Joy



[Non-text portions of this message have been removed]

Yes, I do have regex selected.
Even though it doesn't matter, you didn't say if it worked for you the way I had
it.  Putting additional spaces in didn't fix anything for me.

That IS odd there is a find UP for REPLACE but not for FIND.

If it helps you, placing a backwards searching hyperlink at the end of your text
will do a FIND up.

For example, placing [ mov^B ] at the end of the doc and double clicking it will
find the last 'mov' in the doc.

I just tried it and it works, but highlights just the 'ov' which is probably
another bug. And SOMETIMES, all the text from the end up to the string is
highlighted and sometimes ONLY the search string is highlighted. But THAT was
also happening in Ver 6.

Joy




--- In ntb-clips@yahoogroups.com, "John Shotsky" <jshotsky@...> wrote:
>
> I put 4 spaces in front of your lines, and it all worked properly for me. Did
you have regex selected?
>
> Also, I keep hoping for a find 'up' in addition to down and all. If you happen
to go past the thing you're looking for,
> in a 200 kb file, you have to either start over, or select 'all' and hope it
restarts at the top, which it does not
> always do in the released version. We need to be able to search up, often we
just want to see if the same thing exists
> are an earlier point in the file without having to start at the beginning,
every time.
>
> Regards,
> John
> RecipeTools Web Site:  <http://recipetools.gotdns.com/>
http://recipetools.gotdns.com/
>
> From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf
Of joy8388608
> Sent: Wednesday, April 04, 2012 10:07
> To: ntb-clips@yahoogroups.com
> Subject: [Clip] Version 7 FIND problems
>
>
> I left some posts in the BASIC group documenting some problems with Ver 7 but
have not had any replies so I hope they
> have been noted.
>
> I just found a problem with FIND in ver 7 pre-release 2 that I hope someone
will verify. If I don't start getting some
> answers or verification of problems I find, I will have to go back to Ver 6
and let someone else do the testing.
>
> I want to match all the spaces at the start of each line. When I do a FIND on
the following data for ^\x20+, it matches
> from the second space up to and including the 'a'. Find Next matches from the
third space up to and including the 'a'.
> After a few more tries, it matches just the 'a'. The next find matches the '1'
of '100'.
>
> a 100
> mov ax,0040
> mov ds,ax
> or byte ptr [0017],40
> mov ah,1
> int 16
> mov ax,4c00
> int 21
>
> Please tell me it's not something stupid I'm doing.
>
> Joy
>
>
>
> [Non-text portions of this message have been removed]
>

Your sample didn't have any spaces at the beginning of the lines, so it
shouldn't find anything. On my computer, it
finds nothing using your search string when I remove the spaces. The caret says
to look at the beginning of the line,
and if there are no spaces, it won't look further inside the line.

Regards,
John
RecipeTools Web Site:  <http://recipetools.gotdns.com/>
http://recipetools.gotdns.com/

From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of
joy8388608
Sent: Wednesday, April 04, 2012 11:00
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Version 7 FIND problems


Yes, I do have regex selected.
Even though it doesn't matter, you didn't say if it worked for you the way I had
it. Putting additional spaces in didn't
fix anything for me.

That IS odd there is a find UP for REPLACE but not for FIND.

If it helps you, placing a backwards searching hyperlink at the end of your text
will do a FIND up.

For example, placing [ mov^B ] at the end of the doc and double clicking it will
find the last 'mov' in the doc.

I just tried it and it works, but highlights just the 'ov' which is probably
another bug. And SOMETIMES, all the text
from the end up to the string is highlighted and sometimes ONLY the search
string is highlighted. But THAT was also
happening in Ver 6.

Joy

--- In ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com> , "John
Shotsky" <jshotsky@...> wrote:
>
> I put 4 spaces in front of your lines, and it all worked properly for me. Did
you have regex selected?
>
> Also, I keep hoping for a find 'up' in addition to down and all. If you happen
to go past the thing you're looking
for,
> in a 200 kb file, you have to either start over, or select 'all' and hope it
restarts at the top, which it does not
> always do in the released version. We need to be able to search up, often we
just want to see if the same thing exists
> are an earlier point in the file without having to start at the beginning,
every time.
>
> Regards,
> John
> RecipeTools Web Site: <http://recipetools.gotdns.com/>
http://recipetools.gotdns.com/
>
> From: ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com> 
[mailto:ntb-clips@yahoogroups.com
<mailto:ntb-clips%40yahoogroups.com> ] On Behalf Of joy8388608
> Sent: Wednesday, April 04, 2012 10:07
> To: ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com>
> Subject: [Clip] Version 7 FIND problems
>
>
> I left some posts in the BASIC group documenting some problems with Ver 7 but
have not had any replies so I hope they
> have been noted.
>
> I just found a problem with FIND in ver 7 pre-release 2 that I hope someone
will verify. If I don't start getting some
> answers or verification of problems I find, I will have to go back to Ver 6
and let someone else do the testing.
>
> I want to match all the spaces at the start of each line. When I do a FIND on
the following data for ^\x20+, it
matches
> from the second space up to and including the 'a'. Find Next matches from the
third space up to and including the 'a'.
> After a few more tries, it matches just the 'a'. The next find matches the '1'
of '100'.
>
> a 100
> mov ax,0040
> mov ds,ax
> or byte ptr [0017],40
> mov ah,1
> int 16
> mov ax,4c00
> int 21
>
> Please tell me it's not something stupid I'm doing.
>
> Joy
>
>
>
> [Non-text portions of this message have been removed]
>



[Non-text portions of this message have been removed]

I too show no spaces.

On 4/4/2012 2:04 PM, John Shotsky wrote:
> Your sample didn't have any spaces at the beginning of the lines, so it
shouldn't find anything. On my computer, it
> finds nothing using your search string when I remove the spaces. The caret
says to look at the beginning of the line,
> and if there are no spaces, it won't look further inside the line.
>
> Regards,
> John

Drat. I don't know how I pasted lines with 7 spaces in front of each line and
they all disappeared in the post. I'm pasting them again and they DO have
leading spaces. At least now - before I hit SEND.

Aside from that, my original post, problem and question stands.

       a 100
       mov ax,0040
       mov ds,ax
       or byte ptr [0017],40
       mov ah,1
       int 16
       Mov ax,4c00
       int 21

Joy


--- In ntb-clips@yahoogroups.com, Don <don@...> wrote:
>
> I too show no spaces.
>
> On 4/4/2012 2:04 PM, John Shotsky wrote:
> > Your sample didn't have any spaces at the beginning of the lines, so it
shouldn't find anything. On my computer, it
> > finds nothing using your search string when I remove the spaces. The caret
says to look at the beginning of the line,
> > and if there are no spaces, it won't look further inside the line.
> >
> > Regards,
> > John
>

Hi everyone,

Thanks for all your feedback so far. I've tried my best to fix all the
reported issues. You can now download the new pre-release of NoteTab
Light and NoteTab Pro Trial version 7.0:

NoteTab Light 7 (freeware)
http://www.notetab.com/ftp/NoteTab_Light_Setup.exe

NoteTab Pro 7 (30-day trial version)
http://www.notetab.com/ftp/NotePro_Trial_Setup.exe

Here's a list of the main changes since pre-release #2:

* The Tools | Text Statistics feature is now based on the new NoteTab
word-count method. When used on an HTML file, NoteTab only counts
visible page text (tags and commented blocks are ignored).

* Fixed several issues affecting wildcard searching.

* Fixed the A option (replace all) issue in:
^$StrReplace("SubStr";"ReplaceStr";"Str";Options)$

* Some other minor improvements and issues fixed.


I look forward to reading your comments and feedback.

--
Regards,

Eric Fookes
http://www.fookes.com/

--- In ntb-clips@yahoogroups.com, "John Shotsky" <jshotsky@...> wrote:
>
> Also, I keep hoping for a find 'up' in addition to down and all.

The Standard and Wildcard Search allows to search 'up'. With RegEx, it has never
been possible to search 'up' or 'backwards' (with 'B' option in a clip). So
that's no issue of NT 7.0 but probably due to the way the RegEx Engine works.

For more details, see the topic '^!Find Command - Reverse Regular Expression
Search' that started with message #18159 of Aug 5, 2008.

Regarding Joy's problem (#22539), I can't reproduce that issue. I get 5 to 6
spaces with her sample text, and '^\x20+' is matching correctly all spaces at
the beginning of every line. It never includes any letter or number.

Flo

Hi Dio,

> Wow. I'm elated by the introduction of regex support in
> ^$StrReplace()$. Thank you, Eric, for granting my primary wish!

You're welcome :)

> I notice that absence of option A doesn't seem to prevent swapping of
> all matches. For example, if the task were to replace only the first
> occurence of repeated characters:
>
> ^!Set %x%=foo bar baa ^!Set %x%=^$StrReplace("(.)\1";"$1";"^%x%";R)$
> ^!Prompt ^%x%
>
> My output* is "fo bar ba" instead of anticipated "fo bar baa." Plain
> literal replacements don't heed the absence of A for me either.

This issue is now fixed in update #3.

--
Regards,

Eric Fookes
http://www.fookes.com/

Hi Axel,

> Eric Fookes wrote:
>> NoteTab will handle UTF-8 text just fine as long as all the characters
>> belong to a single code page.
>
> Which means, more or less, it doesn't really handle UTF-8 at all.

I think this is a slight exaggeration. Having personally analyzed a
large number of UTF-8 files, I found that the vast majority could safely
be translated to ANSI and back without any data loss. In other words,
NoteTab could handle them fine.

> The
> whole point of UTF was and is to escape from the old code-page limits.

You're quite right. But most people create documents that fit nicely
within the code-page limits. And therefore work fine in NoteTab.

> I
> do not mind NoteTab not being a UTF editor, it fits my needs fine, but
> those half baked pseudo-capabilities really annoy. I may well need to go
> back to version 5.8.

Update #3 has a new command-line switch for you to test:
NotePro.exe \RawUTF8

It skips the UTF-8 to ANSI conversion. I must admit I haven't had time
to test it yet.

> The worst real limit, after NoteTab has grown from a humble little HTML
> editor of its beginning to the universal tool it now is, is the hard
> coded highlighting.

I'm still hoping to add some minor improvements the the HTML
highlighting before v7 final...

--
Regards,

Eric Fookes
http://www.fookes.com/

How about that. I never noticed you could search UP unless Reg Exp was checked!

And the FIND problem I reported went away after I installed NTL V7R3.

Those problems that some people have and others don't are a bear.

I am STILL seeing the problem that a tab in my browser opens when I double click
the last or second to last word in a sentence ending with a period.  Can anyone
reproduce THAT?

And double clicking in the middle of a word still selects the word from the
click point to the beginning of the word which is how I found the problem above.

Joy



--- In ntb-clips@yahoogroups.com, "flo.gehrke" <flo.gehrke@...> wrote:
>
> --- In ntb-clips@yahoogroups.com, "John Shotsky" <jshotsky@> wrote:
> >
> > Also, I keep hoping for a find 'up' in addition to down and all.
>
> The Standard and Wildcard Search allows to search 'up'. With RegEx, it has
never been possible to search 'up' or 'backwards' (with 'B' option in a clip).
So that's no issue of NT 7.0 but probably due to the way the RegEx Engine works.
>
> For more details, see the topic '^!Find Command - Reverse Regular Expression
Search' that started with message #18159 of Aug 5, 2008.
>
> Regarding Joy's problem (#22539), I can't reproduce that issue. I get 5 to 6
spaces with her sample text, and '^\x20+' is matching correctly all spaces at
the beginning of every line. It never includes any letter or number.
>
> Flo
>

Think about it with negative and positive look aheads and behinds and so
forth ... there is a specific reason that regex only goes one way :-)

On 4/4/2012 9:03 PM, joy8388608 wrote:
> How about that. I never noticed you could search UP unless Reg Exp was
checked!

You're right, I wasn't thinking of it in terms of backwards searching 'using
regex'. I almost always have regex checked,
as I almost always AM using regex to identify the search. I guess I thought it
would convert it to a text search
automatically, and search backwards. I will try to uncheck regex box to search
upwards in the future, but I suspect that
will be unrewarding, as it will require ONLY a literal, which isn't always
possible, or useful. At least, now I
understand the issue.

The problem could be partly resolved by having a 'previous' choice rather than
an 'up' choice. The problem happens when
you blow by the point you are looking for, and once you've passed it, you are
screwed. You can only go full cycle after
that. I've done it more than once at one time, trust me.  But if it stored the
matches, you could back up through
previous matches and thus find previous matches. Just like 'undo' only simply
backing up through previous matches. That
would be just as useful, and relieve frustration for those that work with larger
documents.

Regards,
John
RecipeTools Web Site:  <http://recipetools.gotdns.com/>
http://recipetools.gotdns.com/

From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of
flo.gehrke
Sent: Wednesday, April 04, 2012 14:18
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Version 7 FIND problems


--- In ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com> , "John
Shotsky" <jshotsky@...> wrote:
>
> Also, I keep hoping for a find 'up' in addition to down and all.

The Standard and Wildcard Search allows to search 'up'. With RegEx, it has never
been possible to search 'up' or
'backwards' (with 'B' option in a clip). So that's no issue of NT 7.0 but
probably due to the way the RegEx Engine
works.

For more details, see the topic '^!Find Command - Reverse Regular Expression
Search' that started with message #18159 of
Aug 5, 2008.

Regarding Joy's problem (#22539), I can't reproduce that issue. I get 5 to 6
spaces with her sample text, and '^\x20+'
is matching correctly all spaces at the beginning of every line. It never
includes any letter or number.

Flo



[Non-text portions of this message have been removed]

Ii never noticed the search direction option change with RegX either but
that is just the way RegX doesn't work.

In NTB7#2 I do not have your problems with double clicking words (WinXP).

I suppose having a wild card search option may be useful but my first
reaction is the new GUI will be a PIA. It requires two clicks instead of
just one and the RegX option is hidden until one clicks on the select box.
I would much prefer having two always visible check boxes in a slightly
larger window than being forced to double the click load. I would even
rather have the previous GUI and forego  a wild card option.

What would be really useful however, would be a way to easily delete a Find
or Replace history entry. Often I have made a typo or have multiple entries
in debugging a RegX pattern and the history gets long and cluttered. A
simple right click and delete on a highlighted entry would be a big
improvement. Another possible method would be to press the delete key on a
highlighted entry. This is the method used by Firefox to delete form
history entries. Or for max convenience, implement both methods.

Namaste',  Art

At 4/4/2012 06:03 PM, Joy wrote:
>How about that. I never noticed you could search UP unless Reg Exp was
>checked!
>Those problems that some people have and others don't are a bear.
>
>I am STILL seeing the problem that a tab in my browser opens when I double
>click the last or second to last word in a sentence ending with a period.
>Can anyone reproduce THAT?
>
>And double clicking in the middle of a word still selects the word from
>the click point to the beginning of the word which is how I found the
>problem above.

I usually always click in a blank part of the regex find so it jumps to
the top and I go top down.  I'm just used to it and I guess my stuff
isn't "that" big like John's is apparently.  It works well for me and I
use it hourly.

The history can get long as Art suggests and cluttered.

What would be really cool Eric is to add a recorder feature for "clip
building".  Do a search and replace, it is what you want, click on
commit and it saves it as a clip step.  You could thus do a series of
steps and have them all saved as a clip for future use.  I do this
manually all of the time.  I get thirty similar documents.  I do a
search and replace, it's successful, so I then copy both halves of it to
a clip replace and save the clip.  Repeat over and over and over until I
have the clip.  Still efficient in the end, but could get way more
efficient.

Is it possible to simply write a clip to do this?

On 4/5/2012 1:49 AM, Art Kocsis wrote:
> Ii never noticed the search direction option change with RegX either but
> that is just the way RegX doesn't work.
>
> In NTB7#2 I do not have your problems with double clicking words (WinXP).
>
> I suppose having a wild card search option may be useful but my first
> reaction is the new GUI will be a PIA. It requires two clicks instead of
> just one and the RegX option is hidden until one clicks on the select box.
> I would much prefer having two always visible check boxes in a slightly
> larger window than being forced to double the click load. I would even
> rather have the previous GUI and forego  a wild card option.
>
> What would be really useful however, would be a way to easily delete a Find
> or Replace history entry. Often I have made a typo or have multiple entries
> in debugging a RegX pattern and the history gets long and cluttered. A
> simple right click and delete on a highlighted entry would be a big
> improvement. Another possible method would be to press the delete key on a
> highlighted entry. This is the method used by Firefox to delete form
> history entries. Or for max convenience, implement both methods.
>
> Namaste',  Art
>
> At 4/4/2012 06:03 PM, Joy wrote:
>> How about that. I never noticed you could search UP unless Reg Exp was
>> checked!
>> Those problems that some people have and others don't are a bear.
>>
>> I am STILL seeing the problem that a tab in my browser opens when I double
>> click the last or second to last word in a sentence ending with a period.
>> Can anyone reproduce THAT?
>>
>> And double clicking in the middle of a word still selects the word from
>> the click point to the beginning of the word which is how I found the
>> problem above.
>
>
>
> ------------------------------------
>
> Fookes Software: http://www.fookes.com/
> NoteTab website: http://www.notetab.com/
> NoteTab Discussion Lists: http://www.notetab.com/groups.php
>
> ***
> Yahoo! Groups Links
>
>
>
>

John wrote:
>
> The problem could be partly resolved by having a 'previous' choice rather than
an 'up' choice. The problem happens when
> you blow by the point you are looking for, and once you've passed it, you are
screwed. You can only go full cycle after
> that. I've done it more than once at one time, trust me.  But if it stored the
matches, you could back up through
> previous matches and thus find previous matches. Just like 'undo' only simply
backing up through previous matches. That
> would be just as useful, and relieve frustration for those that work with
larger documents.
>

Yay to that.

If in my trigger-happy rush I happen to blow past the find that's worthy of
(re)consideration, I place my cursor some lines above (how high depends on a
perceived density of finds in a given doc) and usually get back to the desired
spot within a few invocations of Find Next. In that I'm reliant on the
"short-term memory allocation region" in my ever-shrinking brain, where the last
few contexts of found selections (or any temporarily needed snippets of data)
are continuously rotated.

An arguably more civilized (though hardly elegant) method forgoes the Find and
Replace dialog in favor of a clip that prompts for search/replace patterns (if
not already hard-coded and pulled in sequence from a list), places unique tokens
(to be cleared on exit) in the document and keeps track of them. Everything is
handled by a wizard with choices like Find Next, Replace with [THIS], Replace
with [THAT], etc., Find Previous, Edit Selection, Edit Extended Selection,
Google Selection, and so forth.

But I readily admit that hitting Ctrl+R is my primary and preferred route,
mainly because the convenience of freely jumping between the modeless dialog and
documents is obviously lacking in the modal wizard approach.

- - -

BTW, to handle specifically via Find and Replace hundreds of collected (mostly
trouble-sniffing) patterns that have to be processed "by eye" (the ones that
cannot be safely automated in my workflow), I currently use the following:

1. Custom ini file that holds the patterns (plus a clip to append any new ones)
2. Clip that:
-- looks in the target doc for a single match per each search pattern from ini
-- collects ini section numbers of successful patterns (forming thus a small
array of integers)
-- invokes AutoIt script passing section references collected in the previous
step
3. AutoIt script that:
-- invokes NoteTab's Find and Replace dialog
-- populates it with ini values from a given (iterated) section (from the same
ini file)
-- invokes Find Next (to display the first match)
[at this point my dialog decision-making or/and other editing starts & goes on
until I close F&R]
-- waits until the F&R dialog is closed
-- calls a tiny NT clip that restores the cursor at the doc's top
-- starts the cycle over with the next set of values (until all are processed)

I suppose my earlier motivation to achieve the same functionality solely within
NT waned maybe too quickly. My first clip-only attempt kept track of iterations
and populated dialog entries okay, but it required repetitive manual
reactivation after each pattern's turn, and, worse yet, it wasn't free off
occasional unpredictable and thus unreproducible (for debugging) hiccups. In
contrast, AutoIt offered me plenty of glitch-free love right away, so I never
looked back.

It's a workable solution for me, but it mostly agitates my appetite for a
dedicated app with dialog controls placed in a pane parallel to editor's (maybe
horizontally), displaying description/purpose of a current pattern, number of
matches left to go, number of patterns remaining ahead, various replacement
choices (including backward search), collected replacement statistics, etc.,
maybe with another little pane for jotting down ideas, pattern improvements and
whatnot. To avoid reinventing the wheel, I briefly tested a few of "completely
script-able" editors (leaning heavily towards Lua ones), but found no happiness.
(And to roll out my own, I'm yet to justify any anticipated time & effort
commitment in the context of perceived-as-modest productivity gains.)

Dio

--- In ntb-clips@yahoogroups.com, Eric Fookes <egroups@...> wrote:
>
> Hi Axel,
>
> > Eric Fookes wrote:
> >> NoteTab will handle UTF-8 text just fine as long as all the characters
> >> belong to a single code page.
> >
> > Which means, more or less, it doesn't really handle UTF-8 at all.
>
> I think this is a slight exaggeration. Having personally analyzed a
> large number of UTF-8 files, I found that the vast majority could safely
> be translated to ANSI and back without any data loss. In other words,
> NoteTab could handle them fine.
>
> > The
> > whole point of UTF was and is to escape from the old code-page limits.
>
> You're quite right. But most people create documents that fit nicely
> within the code-page limits. And therefore work fine in NoteTab.
>
> > I
> > do not mind NoteTab not being a UTF editor, it fits my needs fine, but
> > those half baked pseudo-capabilities really annoy. I may well need to go
> > back to version 5.8.
>
> Update #3 has a new command-line switch for you to test:
> NotePro.exe \RawUTF8
>
> It skips the UTF-8 to ANSI conversion. I must admit I haven't had time
> to test it yet.
>
> > The worst real limit, after NoteTab has grown from a humble little HTML
> > editor of its beginning to the universal tool it now is, is the hard
> > coded highlighting.
>
> I'm still hoping to add some minor improvements the the HTML
> highlighting before v7 final...
>
> --
> Regards,
>
> Eric Fookes
> http://www.fookes.com/
>

Eric;
I tried the new version with the switch you suggested and found that the line is
facing the wrong direction!

\RawUTF8
should be
/RawUTF8

Having overcome this speedbump, I opened NT 7 b3 using that switch (required
granting admin password to change properties of link!) and dropped in the file
containing the misspelled V word. The characters displayed in the default
settings showed nothing but question marks.

I played around with different font faces until I discovered that there are just
two fonts that do display the letters correctly: Segoe UI and Tahoma.

Thinking I had found the solution to the codepage problem I opened another file
that contains the actual full UTF subjects for several spam messages that decode
when opened in an email client. To my dismay, although the characters were
displayed more or less the same as NP++, they were not decoded into readable
words, which both NP and NP++ rendered correctly.

This forum does not render the letters correctly, so it's a waste of time
pasting them here. If you are interested in seeing the actual text I am
referring to, I have taken two screen captures and can send them to you as jpg
images. That way I am guaranteed that we both see the same letters.

FYI: The NP++ program has an Encoding menu item. The setting I had to use to get
it to display both the original letters and decoded words, is named "UTF-8
without BOM" and the status bar reads: "ANSI as UTF-8"

Aside from this encoding problem, I like everything else about the program. I
use NT Pro every day for writing and editing HTML, CSS and JS files. It is only
for spam filters using strange coding that I had to use a different program.

Hi!

At the very end of a document(past all of the text)I want to create a Clip to
find the nearest non-whitespace character BEFORE it.

After reading the help I thought this would be the code.

^!FIND \S RB

It still searches forward. I thought the B was supposed to reverse it. What am I
doing wrong?

Thanks!

Cliff

On 4/6/2012 4:51 PM, Celtics2000 wrote:
> Hi!
>
> At the very end of a document(past all of the text)I want to create a Clip to
find the nearest non-whitespace character BEFORE it.
>
> After reading the help I thought this would be the code.
>
> ^!FIND \S RB
>
> It still searches forward. I thought the B was supposed to reverse it. What am
I doing wrong?
>
> Thanks!
>
> Cliff

Cliff,

In the command ^!FIND \S RB, the R denotes regex and the B denotes
backward search,  I believe you'll find that regex does not search
backward.

--
···············································
¤• JD#...97 - ¤• SL...772 - 12.04.06~09.49.04

• In Only 30 Years...
• 1977:> Acid Rock
• 2007:> Acid Reflux

€ hrs €  hsavage € pobox € com

Regular expressions only work forwards.  That particular thing is not
possible to be done that way.

However you can do a multi-line search finding everything up to the last
white space.



>
> After reading the help I thought this would be the code.
>
> ^!FIND \S RB
>
> It still searches forward. I thought the B was supposed to reverse it. What am
I doing wrong?
>
> Thanks!
>
> Cliff

Celtics2000 wrote:
>
> Hi!
>
> At the very end of a document(past all of the text)I want to create a Clip to
find the nearest non-whitespace character BEFORE it.
>

Try the following:

^!Find ""\S(?=\s*+\Z)" WRS

The parenthesized section is a look-ahead (to exclude its target from capture):

\S -- non-whitespace char
(?= -- ahead of...
\s*+ -- any number of whitespace
\Z -- at the end

Dio

I wrote:
>
> ^!Find ""\S(?=\s*+\Z)" WRS
>

Sorry, an extra quotation mark sneaked up on me. It should be:

^!Find "\S(?=\s*+\Z)" WRS

Just discovered a bug in the clip processor.

The following clip snippet worked fine in v5.8 & 6.2 but fails in v7b3 when
the cursor is  anywhere on a line without a line terminator (i.e. the last
line or EOF):

^!SetDebug On
^!Jump Line_End
^!Select +2
^!Continue
^!If "^$GetSelection$" = "" ^!InsertText ^%nl%

To see this create a single line doc without a CRLF or even just an empty doc.
In NTB7b3 the clip processor immediately exits without any error message or
feedback of any kind when attempting the ^!Select +2 command.

There is also a visual difference as well. In v5.8 & 6.2, line terminators
are highlighted while in v7 they are not (even the non-existent virtual one
of the EOF), both within a clip as well as manual editing. To see this
create an empty doc, and press SHIFT-END.

Upon, further testing I find this problem only occurs in NT Pro and has
existed since (at least), NotePro version 4. There may be a legitimate
reason for not highlighting the line terminators but simply exiting a clip
without feedback is not acceptable.

Art

After watching the help file on clips, I must conclude that this is no
longer for me. So I hope that someone would help me.

It is sorting of lines via a part of each line.
- Each line contains a ":" (1 colon). Before and after the colon, there
is all kinds of text, including figures, punctuation marks, spaces, and
ordinary letters.
- The lines should be sorted as a whole, but what is left of the colon
determines the sorting.
It should go from wide to narrow in terms of the text to the left of the
colon. So the longest text to the left of the colon, is top of the list,
the shortest at the bottom.

An example:
r1:1r
weg te zwendelen:weg te toveren
wereld-geldmarkt:wereldgeldmarkt
zuid-oostelijke:zuidoostelijk
zilver uitvoer:zilveruitvoer
wereld-geld:wereldgeld
zetelrover:afperser
weerstreeft:tegenwerkt/knor/armen/werken tegen/toeslaan
0123456789:uitgegeven/weggegeven
zo even:zo-even
zijde:zijde/kant
zog.:zg.
welstandsinstelling:liefdadigheidsinstelling
~$#..w6ek?t:weekwinst
zijden:zijden/kanten
warenquantum:warenkwantum

After sorting:
welstandsinstelling:liefdadigheidsinstelling
weg te zwendelen:weg te toveren
wereld-geldmarkt:wereldgeldmarkt
zuid-oostelijke:zuidoostelijk
zilver uitvoer:zilveruitvoer
warenquantum:warenkwantum
wereld-geld:wereldgeld
~$#..w6ek?t:weekwinst
weerstreeft:tegenwerkt/knor/armen/werken tegen/toeslaan
zetelrover:afperser
0123456789:uitgegeven/weggegeven
zo even:zo-even
zijden:zijden/kanten
zijde:zijde/kant
zog.:zg.
r1:1r

Thanks to those who want to help!
--
Adrien

Off the top of my head ... I remember sorting on columns of text.

I think if you change the delimiter to a colon (assuming that there are
no other colons) then you can sort on a "column" of data ... at one time
Jody had a clip that moved the correct column to the left (yours is
already there) then sorted then removed the moved column.

Just thinking out loud.

On 4/7/2012 11:06 AM, Adrien Verlee wrote:
> r1:1r
> weg te zwendelen:weg te toveren
> wereld-geldmarkt:wereldgeldmarkt
> zuid-oostelijke:zuidoostelijk
> zilver uitvoer:zilveruitvoer
> wereld-geld:wereldgeld
> zetelrover:afperser
> weerstreeft:tegenwerkt/knor/armen/werken tegen/toeslaan
> 0123456789:uitgegeven/weggegeven
> zo even:zo-even
> zijde:zijde/kant
> zog.:zg.
> welstandsinstelling:liefdadigheidsinstelling
> ~$#..w6ek?t:weekwinst
> zijden:zijden/kanten
> warenquantum:warenkwantum

On second thought you need to determine lengths, insert zero padded
lengths in the first column, sort on that, remove them, and then remove
the numbers. ...

I have a clip that will order columns alpha and I just ran it on yours
... not what you want:
~$#..w6ek?t:weekwinst
zuid-oostelijke:zuidoostelijk
zog.:zg.
zo even:zo-even
zilver uitvoer:zilveruitvoer
zijden:zijden/kanten
zijde:zijde/kant
zetelrover:afperser
wereld-geldmarkt:wereldgeldmarkt
wereld-geld:wereldgeld
welstandsinstelling:liefdadigheidsinstelling
weg te zwendelen:weg te toveren
weerstreeft:tegenwerkt/knor/armen/werken tegen/toeslaan
warenquantum:warenkwantum
r1:1r
0123456789:uitgegeven/weggegeven

On 4/7/2012 11:06 AM, Adrien Verlee wrote:
> So the longest text to the left of the colon, is top of the list,
> the shortest at the bottom.

Okay I have length sorting ...
If you want to sort within length you need one more loop in there to
find all that have same length and then sort within ... I capped it a
10000 lines but easy to up that.

My results:
welstandsinstelling:liefdadigheidsinstelling
wereld-geldmarkt:wereldgeldmarkt
weg te zwendelen:weg te toveren
zuid-oostelijke:zuidoostelijk
zilver uitvoer:zilveruitvoer
warenquantum:warenkwantum
~$#..w6ek?t:weekwinst
wereld-geld:wereldgeld
weerstreeft:tegenwerkt/knor/armen/werken tegen/toeslaan
zetelrover:afperser
0123456789:uitgegeven/weggegeven
zo even:zo-even
zijden:zijden/kanten
zijde:zijde/kant
zog.:zg.
r1:1r

^!SetHintInfo ReOrdering...
^!SetScreenUpdate Off
^!Set %Delimiter%=^?{Enter Delimiter: : ^p ^t ; @ , Tab
shown=_:|^p|^%VBAR%|^||^t|;|@|,}

^!Jump Doc_Start

:Loop1
^!Select Eol
^!IfFalse ^$IsEmpty(^%IsSelected%)$ Skip_5
^!Find "^%Delimiter%" TIHS
^!Set %SortLength%=^$GetCol$
^!Jump Line_Start
^!InsertText 000000^%SortLength%|:|
^!If ^$GetRow$ <> ^$GetLineCount$ Next else Loop2
^!Jump +1
^!Goto Loop1

:Loop2
^!replace "^0*(\d{5})" >> "$1" rwais
^!Select All
^$StrSort("^$GetSelection$";No;No;Yes)$
^!Replace "^.*\|\:\|" >> "" RAWS



On 4/7/2012 11:06 AM, Adrien Verlee wrote:
> - The lines should be sorted as a whole, but what is left of the colon
> determines the sorting.

While I'm sure we can figure it out with a script/clip, I'm clueless
what you are talking about.

Maybe a small before and after sample and you will get a much bigger
response on the clips list. I'll copy there and await your example.

On 4/7/2012 7:03 AM, milanboran wrote:
> Hi NTB-Scripters!
>
> Using NoteTab, right now I try to crack a problem re a large list, ca
> 2mio records, stripped all other stuff away, so that only the strings
> that need sorting remain. But I need to sort backwards, from right to
> left. Then the duplicates need to be counted. Right now only the
> R2L-sorting and the dupe-counting remain. Any ideas? Is there a plugin
> for this?
>
> So far spread sheets or database programs seam not to do it per se or I
> simply do not know how to, yet ;) But it would be much easier, if
> NoteTab could do it right with the text file in it, so no export/import
> would be necessary.
>
> Any help is much appreciated. This is not an Easter Egg, but you can
> count it as an Easter Greeting :)
>
> Thank you in advance and best wishes,
> Milan
>
>
> -

So you want a count of how many times something appears ... I get that
... but that sort order is by last character?

so 2, 5, e, i, si, su

Is that the plan?

On 4/7/2012 1:26 PM, milan.boran@... wrote:
> Yes, good idea, Don.
>
> ### Before ###
> hus
> hus
> hus
> hus2
> hus2
> hus345
> hus345
> hus345
> hus345
> hire
> uni
> unity
>
> ### After ###
> hus2    2
> hus2    2
> hus345    4
> hus345    4
> hus345    4
> hus345    4
> hire    1
> uni    1
> unis    1
> hus    3
> hus    3
> hus    3
>
> Many thanks for looking into this,
> Milan
>
>
>
>
>
> On Sat, Apr 7, 2012 at 18:21, Don <don@...> wrote:
>>
>>
>>
>> While I'm sure we can figure it out with a script/clip, I'm clueless
>> what you are talking about.
>>
>> Maybe a small before and after sample and you will get a much bigger
>> response on the clips list. I'll copy there and await your example.
>>
>>
>>
>> On 4/7/2012 7:03 AM, milanboran wrote:
>>> Hi NTB-Scripters!
>>>
>>> Using NoteTab, right now I try to crack a problem re a large list, ca
>>> 2mio records, stripped all other stuff away, so that only the strings
>>> that need sorting remain. But I need to sort backwards, from right to
>>> left. Then the duplicates need to be counted. Right now only the
>>> R2L-sorting and the dupe-counting remain. Any ideas? Is there a plugin
>>> for this?
>>>
>>> So far spread sheets or database programs seam not to do it per se or I
>>> simply do not know how to, yet ;) But it would be much easier, if
>>> NoteTab could do it right with the text file in it, so no export/import
>>> would be necessary.
>>>
>>> Any help is much appreciated. This is not an Easter Egg, but you can
>>> count it as an Easter Greeting :)
>>>
>>> Thank you in advance and best wishes,
>>> Milan
>>>
>>>
>>> -
>>
>>
>
>
>
>
> --
>
>
>
>
> ----------
> Legal Note
> This message, incl. potential attachments, is of confidential or
> privileged nature and intended solely for individual/organization
> addressed. If received in error, please notify sender at once and
> destroy. Unintended use of message is forbidden/potentially illegal.
> Salvatory and severance apply, estoppel is void, e.g. in that any
> message or any part thereof shall be valid in their own context.
> ----------
>
>
> ------------------------------------
>
> Fookes Software: http://www.fookes.com/
> NoteTab website: http://www.notetab.com/
> NoteTab Discussion Lists: http://www.notetab.com/groups.php
>
> ***
> Yahoo! Groups Links
>
>
>
>

--- In ntb-clips@yahoogroups.com, Adrien Verlee <adrien.verlee@...> wrote:
>
> After watching the help file on clips, I must conclude that this is
> no longer for me. So I hope that someone would help me.
>
> It is sorting of lines via a part of each line. Each line contains
> a ":" (1 colon). Before and after the colon, there is all kinds of
> text, including figures, punctuation marks, spaces, and
> ordinary letters.
> - The lines should be sorted as a whole, but what is left of
> the colon determines the sorting...


Adrien,

The following clip might come pretty close to a solution of this task. It's
derived from a clip I wrote for a similar job.

I understand that task as follows: The lines are divided into a left and a right
string and have to get sorted on two levels. On first level, sort the left
strings on their string size. On second level, sort the right strings
alphabetically.

Running the following clip against your sample text seems to achieve the desired
result.

Please note:

1. Only one document containing the source text should be opened because the
clip toggles between the source and a second document used as text buffer.

2. The source text will be changed by the clip. So make sure to save your
original version.

3. The sorting on string size supposes that the maximum length of the left
strings is 99 characters.


^!Jump Doc_Start
^!SetScreenUpdate Off

:Insert_StrSize
^!Find "^[^:]+" RS
^!IfError Sort_left
^!InsertText ^$StrSize(^$GetSelection$)$^%Space%^$GetSelection$
^!Goto Insert_StrSize

:Sort_left
;  Sort descending on length of string size
^!Replace "^(?=\d\x20)" >> "0" AWRS
^!Select All
^$StrSort("^$GetSelection$";0;0;0)$
^!Jump Doc_Start
^!Toolbar New Document
^!Document First

:Sort_right
;  Alpha-sort ascending on string right
;    Capture lines with equal StrSize left
^!Find "^(\d{2}).*\R(\1.*(\R|\Z))+" RS
^!IfError Out
;  Copy block to text buffer
^!SetClipboard ^$GetSelection$
^!Document Next
^!Select All
^!Paste
^!Replace "^([^:]+):(.+)$" >> "$2:$1" WARS
^!Select All
^$StrSort("^$GetSelection$";0;1;0)$
^!Replace "^([^:]+):(.+)$" >> "$2:$1" WARS
;  Remove empty lines at end of string
^!Replace "\R{1,}\Z" >> "" WRS
^!SetClipboard ^$GetText$
^!Document First
^!InsertText ^$GetClipboard$^P
^!Goto Sort_right

:Out
^!Document Next
^!Close Discard
^!Replace "^\d{1,}\x20" >> "" WARS
^!Jump Doc_Start

To watch what the clip is doing, change the second line to '^!ScreenUpdate On'
and run the clip in debug mode (^!SetDebug On).

Regards,
Flo