--- In ntb-clips@yahoogroups.com, Art Kocsis  wrote:
>
> I don't have much hair left to pull so maybe you guys can save
> my scalp and suggest a way to make this search pattern work in
> a clip.
>
> I am trying to verify a selection to be a well formed numeric
> field. By that I mean, the selection may have leading white space,
> possibly a plus or minus sign (possibly followed by horizontal
> white space), followed by one or more decimal digits with no
> embedded or trailing white space. The total width of the selection
> is fixed and known and may range from one to a large number. The
> selection may be preceded or followed by any text. The preceding
> code guarantees the selection to contain at least one non-white-
> space character.
>
>
> For example these would all be well formed, valid fields:
>          |<-test->|
>    + 123
>     +123
>   -  123
> +      3
> +      356456       [next line is at EOF]
> +      3
>
> And these would all be ill-formed, invalid fields:
>
>          |<-test->|
>   -+ 123   [multiple operators]
>     2+23   [embedded operator]
>   - 1 23   [embedded white space]
> +  aa  3   [non-digit character]
>      2     [trailing white space] [next line is at EOF]
> a+     3
>
> The RegEx pattern, "^\s*[\+-]?\s*\d*?\K[\D]+?", seemed to work OK
> in the Toolbar dialog. Although the toolbar Find does not respect
> selection boundaries for selections less than 24 characters, the
> matches found for valid fields were outside the selection field
> and could be testable by their column number.
>
> However, in a clip (target fields are preselected),
>
>  ^!Find "^\s*[\+-]?\s*\d*?\K[\D]+?" HRS
>
> yields entirely different results and consistently matches valid
> operators and white space within the selection. It seems that the
> clip command is respecting the selection.
>
> Upon further investigation, I found that pressing the F3 key to
> invoke the search (instead of clicking the Find next button),
> yields the same results as the clip. Another inconsistency of
> Notetab.
>
> Any suggestions on how to make this pattern work in a clip?
>
> Darn - I just realized I forgot all about decimal points. Best
> leave them for later as this clip was just for integers.


Hi Art.
I'm not nearly as good at RegExp at others but I'll give you what I have so far.
I'm unclear  about your data and what you mean by "the selection may be preceded
or followed by any text" since your example started with ^\s[\+-] which means
start at beginning of line...

This may help you start down the right path.
^\s*[\+\-]?\s*\d+(?=\s*$)

Something like ^\s*[\+\-]?\s*\d+(\.?\d+)*(?=\s*$)
may help with decimals as long as you don't have grouping characters.

Joy

At 01-03-2013 23:03 +0000, Joy wrote:
>Hi Art.
>I'm not nearly as good at RegExp at others but I'll give you what I have so
far. I'm unclear about your data and what you mean by "the selection may be
preceded or followed by any text" since your example started with ^\s[\+-] which
means start at beginning of line...

Actually, the "^" means start of selection, if any, start of line if not.

What I was trying to convey was that at this point in my clip a selection
exists, it contains at least one non-white-space character, is restricted to a
single line and that the selection could be anywhere in a line - there could be
text preceding and/or text following the selection. The "^" was necessary to
ensure that the search pattern started from and included the  start of the
selection.


>This may help you start down the right path.
>^\s*[\+\-]?\s*\d+(?=\s*$)

Thank you for the suggestion. However, that pattern will only find valid numeric
strings followed by white space to the EOL. My selections may be followed by any
text, not just white space. And I need to ensure that within the selection, no
non-digit character appears following the first digit. That is what the [\D]
class was supposed to do. Oops! PAUSE. STOP. RETHINK.

Well now, between the two of our misconceptions, I think we've got it.

Writing the above explanation evoked a new line of thought. I had been trying to
test if an invalid character existed in the selection ("\s*\d*?\K[\D]", a
positive negative) and you were going by my stated goal of verifying a valid
field ("\s*\d+", a positive positive). I took my approach as I didn't know of a
way to ensure that the search didn't stop short of the entire selection.
However, that is exactly what the "$" meta character means: End of selection, if
any, EOL if not. I had thought the "$" only meant EOL. Your use of it made me
look it up. Learned something new.

So a working search pattern becomes simply:

^!Find "^\s*[\+-]?\s*\d+?$" HRS

Thanks. You did help.

Now, I wonder if anyone picked up on the different behaviors of Toolbar "Find
Text" between the F3 and mouse invocations.


Art

Seems to work I think ...
^ *(\+|-)? *?([\d\.]+)(?!  )[^\d\r\n]*$

On 1/3/2013 6:03 PM, joy8388608 wrote:
> For example these would all be well formed, valid fields:
>>          |<-test->|
>>    + 123
>>     +123
>>   -  123
>> +      3
>> +      356456 [next line is at EOF]
>> +      3
>>
>> And these would all be ill-formed, invalid fields:
>>
>>          |<-test->|
>>   -+ 123   [multiple operators]
>>     2+23   [embedded operator]
>>   - 1 23   [embedded white space]
>> +  aa  3   [non-digit character]
>>      2     [trailing white space] [next line is at EOF]
>> a+     3
>>

I don't know if this is new or I just didn't notice before:

After Search Disk the options are now transferred to the Find box, so
one can jump to the individual places using <F3>. <All documents> is not
selected though and one has to do it manually through <Ctrl><F>. After a
Search Disk <all documents> will always be the obvious and sensible
option, so would it be possible to select it by default?

Danke
	 Axel

I looked and looked but cannot find any functions to tell how many columns and
rows are visible on the main NT text screen. These values change as the window
is resized, frames are opened (outline, libraries, etc) font is changed...

It can be done in a clip but it's not the prettiest thing and involves creating
a new document, filling it with long lines, and moving around in it a bit to get
the values. I was wondering if anyone knew of a fairly direct way.

Thanks,
Joy

LaTeX has many expressions beginning with a backslash, for example \par.
The follwoing example misinterprets this somehow in a Replace
expression:


^!InsertSelect \begin{letter}^P
^!Replace "\\begin\{(letter)\}$" >>
"\\begin{$1}\{%\n\\\\\n\n\\\\\[.2\\baselineskip\]\n\{\\Large \}
\n\\par\}" HRASTI
^!Continue
^!Jump SELECT_END
^!InsertSelect ^Padd new stuff here

N.B: The Replace expression needs to be very long. Whenever I shorten
it, the selection ends at some other place inside the replaced text,
sometimes even at its end, but I can't reproduce any of that.

Axel

--
             Dipl.-Ing. F. Axel Berger      Tel: +49/ 2174/ 7439 07
             Johann-Häck-Str. 14            Fax: +49/ 2174/ 7439 68
             D-51519 Odenthal-Heide       eMail: Axel-Berger@...
             Deutschland (Germany)         http://berger-odenthal.de

An example line of actual data before and after would be useful. I think the
backslash before the closing bracket is
interpreted as a closing bracket instead of the end of the class, too.

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
Axel Berger
Sent: Friday, January 11, 2013 04:44
To: NoteTab Clips
Subject: [Clip] Bug: \p misinterpreted


LaTeX has many expressions beginning with a backslash, for example \par.
The follwoing example misinterprets this somehow in a Replace
expression:

^!InsertSelect \begin{letter}^P
^!Replace "\\begin\{(letter)\}$ <file:///\\begin\%7b(letter)\%7d$> " >>
"\\begin{$1}\{%\n\\\\\n\n\\\\\[.2\\baselineskip\]\n\{\\Large \}
<file:///\\begin%7b$1%7d\%7b%25\n\n\n\%5b.2\baselineskip\%5d\n\%7b\Large%20\%7d%\
0b\n\par\%7d>
\n\\par\}" HRASTI
^!Continue
^!Jump SELECT_END
^!InsertSelect ^Padd new stuff here

N.B: The Replace expression needs to be very long. Whenever I shorten
it, the selection ends at some other place inside the replaced text,
sometimes even at its end, but I can't reproduce any of that.

Axel

--
Dipl.-Ing. F. Axel Berger Tel: +49/ 2174/ 7439 07
Johann-Häck-Str. 14 Fax: +49/ 2174/ 7439 68
D-51519 Odenthal-Heide eMail: Axel-Berger@...
<mailto:Axel-Berger%40Nexgo.De>
Deutschland (Germany) http://berger-odenthal.de



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

John Shotsky wrote:
> An example line of actual data before and after would be useful.

My trimmed down clip is meant to be run on an empty document.
Rethinking, it is probably not the \p that's the trouble here. It rather
seems that actual backslashes inserted through \\ are not counted and
that's why the selection after the Replace is too short as seen with the
^!Continue.

If the clip was only meant to be run with nothing selected I could use
^& to position the cursor, but that would create other unintended
effects.

I have been having ongoing problems with characters displaying correctly in
NoteTab. I often get text files as an export
from an addon in FireFox, called RecipeFox. It captures recipes off web pages
and exports them to a text file. It is
unpredictable what the original code page or character set of the web page is,
so an attempt is made to export to text
in UTF-8, so that it will display correctly in NoteTab. However, at times, it
does not. I have determined that, at
times, NoteTab chooses the wrong code page or text format when it opens a text
file for the first time, which causes
certain high-order characters to display incorrect – usually, a character
preceded by an 'A' with a carat on top of it,
but there are also other variations. Simple characters, such as copyright
symbols and degree symbols are likewise
incorrectly displayed in this instance, but other times the exported text files
are ok. It apparently is linked to an
analysis of characters found in the text file, since it usually happens when
higher order ASCII characters are found in
the file.

So, I took one of these files which displays incorrectly and tried exporting it
to various formats, including ANSI,
ASCII, UTF-8, and Unicode. They all display correctly, except that the ASCII
version replaces higher order characters
with (two) question marks INCLUDING those copyright and degree symbols that
would otherwise be ok in a plain text file.
(Copyright ?? )

I can forward the original and each of the exported versions if someone wants to
look at the reason why this happens. It
is very frustrating, because it cannot be determined ahead of time when this is
going to happen, and, if the file is
saved one time, it is permanently corrupted and can no longer be exported to any
of the other formats, since it is saved
as plain ASCII by default. I cannot ask my users to always export any text file
to UTF-8 or ANSI before editing and
saving the file, so my real goal is to learn how to avoid this problem, and
possibly get a fix for NoteTab if it is
actually a NoteTab issue alone. Since our group doesn't permit attachments, just
let me know if you want me to forward
my files to you.
Thanks,
John




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

John Shotsky wrote:
> usually, a character preceded by an 'A' with a carat on top of it,
> but there are also other variations.

NoteTab can only work with one 8-bit character set at a time. It can
read and use UTF-8 notation if all characters used can be mapped to one
character page, it can't deal with more than 256 different letters.
So the safe way to go is to load as raw UTF-8 and run a clip to convert
to something compatible like HTML's Ӓ notation.

Axel

Axel Berger wrote:
> backslashes inserted through \\

I just noticed that in this case the Replace need not be Regex, so there
is a simple solution. Still it seems there is a bug here. My guess is,
that in determining the length of the replace string backslashes are not
counted, which is correct except for the one case of "\\".

Axel

As I stated, I can't ask my users to know how to do that. They want to open a
file, edit it a little, save and run my
clips on it. Once they open, edit and save, the damage is done. What I am
looking for is a way to intercept this problem
so it doesn't happen, or a modification to NoteTab, if necessary, to make it
work right. As I said, if I export this
unedited file to either ANSI or UTF-8, it displays correctly, so why doesn't it
just open it in that format to start
with, instead of making bogus characters that aren't correct in *ANY* situation?
(Speķa Pīr�gi)
http://www.saveur.com/article/Recipes/Speka-Piragi-Bacon-Turnovers

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
Axel Berger
Sent: Friday, January 11, 2013 10:00
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Code page/character issues


John Shotsky wrote:
> usually, a character preceded by an 'A' with a carat on top of it,
> but there are also other variations.

NoteTab can only work with one 8-bit character set at a time. It can
read and use UTF-8 notation if all characters used can be mapped to one
character page, it can't deal with more than 256 different letters.
So the safe way to go is to load as raw UTF-8 and run a clip to convert
to something compatible like HTML's ? notation.

Axel



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

John Shotsky wrote:
> What I am looking for is a way to intercept this problem
> so it doesn't happen, or a modification to NoteTab, if necessary,
> to make it work right.

I second that. A general setting turning off all UTF capabilities and
detection would be extremely nice to have. It will then be up to you to
detect and deal with such characters, but for myself I've found that to
be the easy part, stopping NoteTab from interfering is the hard bit.

Axel

Here is another interesting thing about this problem.
If I export the file which creates the condition I'm discussing, and do not even
open the file in NoteTab, then copy the
file to another folder, then open the copy, it reads fine. If I open the
original, it has the problem. That is, the
simple act of copying an original file to another folder using Windows 7 'fixes'
the problem. That is so bizarre, but at
least I can tell my users to copy it to a different work folder before opening
it.

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


-----Original Message-----
From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of
John Shotsky
Sent: Friday, January 11, 2013 10:16
To: ntb-clips@yahoogroups.com
Subject: RE: [Clip] Code page/character issues

As I stated, I can't ask my users to know how to do that. They want to open a
file, edit it a little, save and run my
clips on it. Once they open, edit and save, the damage is done. What I am
looking for is a way to intercept this problem
so it doesn't happen, or a modification to NoteTab, if necessary, to make it
work right. As I said, if I export this
unedited file to either ANSI or UTF-8, it displays correctly, so why doesn't it
just open it in that format to start
with, instead of making bogus characters that aren't correct in *ANY* situation?
(Speķa Pīr�gi)
http://www.saveur.com/article/Recipes/Speka-Piragi-Bacon-Turnovers

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
Axel Berger
Sent: Friday, January 11, 2013 10:00
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Code page/character issues


John Shotsky wrote:
> usually, a character preceded by an 'A' with a carat on top of it,
> but there are also other variations.

NoteTab can only work with one 8-bit character set at a time. It can
read and use UTF-8 notation if all characters used can be mapped to one
character page, it can't deal with more than 256 different letters.
So the safe way to go is to load as raw UTF-8 and run a clip to convert
to something compatible like HTML's ? notation.

Axel



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



------------------------------------

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 Shotsky wrote:
> If I open the original, it has the problem.

Almost certainly not. Your "original" has already been opened and
probably saved by NT at least once before. NT saves info about recent
files in Note*.fpr. When I encounter intractable UTF problems, I rename
the file and open it then, does the same trick.

> at least I can tell my users to copy it to a different work folder
> before opening it.

If they do that before opening it for the first time, they'll achieve
nothing.

But you can include the technique in a clip: Save the file, Rename it
through ^!Dos (wait a second for cacheing), and open the "new" one. Even
better, if you can make your users open NT with the /RawUTF8 parameter,
your problems ought to be solved.

(I should have remembered. When introduced I refrained from using that,
because I wanted to keep the way back to version 5.8 and 6.2 open. By
now I feel quite safe in 7.x and ought to reconsider. Now, where and how
to find each and every place where NT is evoked? Registry, Programs
folder, Links, Commands in dozens of shell-like programs, ... -- looks a
lot like a big fool's errand, and needs to be done on at least three
machines: Eric, a command line parameter is good, a setting would be
much much better.)

Axel

When the text file is exported from Firefox, then opened in NoteTab, it has the
problem I am discussing. Every time, for
the same export.
If I export from FireFox, then reboot my computer, and then open the file with
NoteTab, it has the problem I am
discussing.
If I open the file from FireFox, then save it with another name, it still has
the same problem.
If I open the file from FireFox, copy the contents, then paste into a new file
and save THAT, it still has the same
problem.
If I export from FireFox, then copy the file to another folder, and then open
the copy in NoteTab, it does not have the
problem I am discussing. The original still has the problem.
If I export from FireFox, then rename the file in the original folder using
Windows, then open the file in NoteTab, it
does not have the problem I am discussing. There is no original at this point.
I can show it with screenshots, but if I copy or rename the file, the problem
vanishes. Win7-64.
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
Axel Berger
Sent: Friday, January 11, 2013 13:47
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Code page/character issues


John Shotsky wrote:
> If I open the original, it has the problem.

Almost certainly not. Your "original" has already been opened and
probably saved by NT at least once before. NT saves info about recent
files in Note*.fpr. When I encounter intractable UTF problems, I rename
the file and open it then, does the same trick.

> at least I can tell my users to copy it to a different work folder
> before opening it.

If they do that before opening it for the first time, they'll achieve
nothing.

But you can include the technique in a clip: Save the file, Rename it
through ^!Dos (wait a second for cacheing), and open the "new" one. Even
better, if you can make your users open NT with the /RawUTF8 parameter,
your problems ought to be solved.

(I should have remembered. When introduced I refrained from using that,
because I wanted to keep the way back to version 5.8 and 6.2 open. By
now I feel quite safe in 7.x and ought to reconsider. Now, where and how
to find each and every place where NT is evoked? Registry, Programs
folder, Links, Commands in dozens of shell-like programs, ... -- looks a
lot like a big fool's errand, and needs to be done on at least three
machines: Eric, a command line parameter is good, a setting would be
much much better.)

Axel



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

John Shotsky wrote:
> If I export from FireFox, then copy the file to another folder,
> and then open the copy in NoteTab, it does not have the
> problem I am discussing. The original still has the problem.
> If I export from FireFox, then rename the file in the original
> folder using Windows, then open the file in NoteTab, it
> does not have the problem I am discussing.

This is really, really weird. There is no explanation I can think of
except that Windows itself is saving extra meta-information about files
and NT can access that. You should do a file compare in hex
(Totalcommander can do that). If they are identical, they ought to be
after a simple copy and must be after rename, then it has to be external
meta-information.

Axel

Well, if it was mainstream, I wouldn't have brought it up here. At first, I
thought maybe FireFox wasn't properly
closing the file, which is why I rebooted between, but that didn't help. I've
inspected properties, but that didn't show
anything different between the before and after. The byte count doesn't change.
But somehow, NoteTab is seeing
'something' that I can't find, which is why I asked here. I'll see if I can find
a more robust file metadata analyzer.
FYI – EditPad Pro opens it fine, but it is also a Unicode editor, and I often
use it to see what is 'really' in a text
file.

Now for the even weirder part: EditPad Pro DOES display it correctly in text
view, but in hex/Ascii view, it shows the
same thing as NoteTab!
Text View: Speka Piragi
Hex/Ascii View: Speķa Pīr�gi

NoteTab correctly detects it as utf-8. But when I force it to Windows 1252,  it
displays as in NoteTab – incorrectly.
That means that NoteTab is detecting it as Win1252 before it is renamed, and as
UTF8 afterwards. Further, that means
that either Windows or NoteTab is incorrectly detecting the code page. But,
since EditPad Pro detects it correctly, I
don't think it's Windows. This reminds me that, over time, I have often had
problems with characters in NoteTab, and
have done everything I could think of to resolve those issues. But this one
seems unresolvable. (except for moving the
file)

Recipes, it turns out, can be very difficult, since they come from every
country, and even when Anglicized, they often
retain oddball characters. Web pages can display these characters fine, but text
editors may have problems. I can't even
guess why NoteTab detects the code page differently, but I am pretty certain
that it is a NoteTab problem alone. I do
not know what mechanism editors use to detect code pages.

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
Axel Berger
Sent: Saturday, January 12, 2013 00:39
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Code page/character issues


John Shotsky wrote:
> If I export from FireFox, then copy the file to another folder,
> and then open the copy in NoteTab, it does not have the
> problem I am discussing. The original still has the problem.
> If I export from FireFox, then rename the file in the original
> folder using Windows, then open the file in NoteTab, it
> does not have the problem I am discussing.

This is really, really weird. There is no explanation I can think of
except that Windows itself is saving extra meta-information about files
and NT can access that. You should do a file compare in hex
(Totalcommander can do that). If they are identical, they ought to be
after a simple copy and must be after rename, then it has to be external
meta-information.

Axel



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

One last bit of information about this problem:
When the file has been moved or renamed, it displays correctly in NoteTab,
although it doesn't display the accents. It
displays standard English characters. However, when this same file is viewed in
EditPad Pro, the original accents are
still present. It is only the DISPLAY that is different between these two
instances. So, in one case NoteTab displays
one way, and in the other case a different way.

From what I've read about code page detection, there are commands that search
through a document and report on
characters found. I still have no idea why moving or renaming a file provides
different results to NoteTab. But it is
apparently something about this search or the decision about how to display that
is not working correctly.

In my research, I found this fascinating tale of the history and basis of
characters on computers:
http://www.joelonsoftware.com/printerFriendly/articles/Unicode.html

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


-----Original Message-----
From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of
John Shotsky
Sent: Saturday, January 12, 2013 05:06
To: ntb-clips@yahoogroups.com
Subject: RE: [Clip] Code page/character issues

Well, if it was mainstream, I wouldn't have brought it up here. At first, I
thought maybe FireFox wasn't properly
closing the file, which is why I rebooted between, but that didn't help. I've
inspected properties, but that didn't show
anything different between the before and after. The byte count doesn't change.
But somehow, NoteTab is seeing
'something' that I can't find, which is why I asked here. I'll see if I can find
a more robust file metadata analyzer.
FYI – EditPad Pro opens it fine, but it is also a Unicode editor, and I often
use it to see what is 'really' in a text
file.

Now for the even weirder part: EditPad Pro DOES display it correctly in text
view, but in hex/Ascii view, it shows the
same thing as NoteTab!
Text View: Speka Piragi
Hex/Ascii View: Speķa Pīr�gi

NoteTab correctly detects it as utf-8. But when I force it to Windows 1252,  it
displays as in NoteTab – incorrectly.
That means that NoteTab is detecting it as Win1252 before it is renamed, and as
UTF8 afterwards. Further, that means
that either Windows or NoteTab is incorrectly detecting the code page. But,
since EditPad Pro detects it correctly, I
don't think it's Windows. This reminds me that, over time, I have often had
problems with characters in NoteTab, and
have done everything I could think of to resolve those issues. But this one
seems unresolvable. (except for moving the
file)

Recipes, it turns out, can be very difficult, since they come from every
country, and even when Anglicized, they often
retain oddball characters. Web pages can display these characters fine, but text
editors may have problems. I can't even
guess why NoteTab detects the code page differently, but I am pretty certain
that it is a NoteTab problem alone. I do
not know what mechanism editors use to detect code pages.

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
Axel Berger
Sent: Saturday, January 12, 2013 00:39
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Code page/character issues


John Shotsky wrote:
> If I export from FireFox, then copy the file to another folder,
> and then open the copy in NoteTab, it does not have the
> problem I am discussing. The original still has the problem.
> If I export from FireFox, then rename the file in the original
> folder using Windows, then open the file in NoteTab, it
> does not have the problem I am discussing.

This is really, really weird. There is no explanation I can think of
except that Windows itself is saving extra meta-information about files
and NT can access that. You should do a file compare in hex
(Totalcommander can do that). If they are identical, they ought to be
after a simple copy and must be after rename, then it has to be external
meta-information.

Axel



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



------------------------------------

Fookes Software: http://www.fookes.com/
NoteTab website: http://www.notetab.com/
NoteTab Discussion Lists: http://www.notetab.com/groups.php

***
Yahoo! Groups Links

What would happen if you saved it as a .html file instead of .txt file?


-----Original Message-----
From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of
John Shotsky
Sent: Saturday, January 12, 2013 05:06
To: ntb-clips@yahoogroups.com
Subject: RE: [Clip] Code page/character issues

Well, if it was mainstream, I wouldn't have brought it up here. At first, I
thought maybe FireFox wasn't properly closing the file,
which is why I rebooted between, but that didn't help. I've inspected
properties, but that didn't show anything different between
the before and after. The byte count doesn't change. But somehow, NoteTab is
seeing 'something' that I can't find, which is why I
asked here. I'll see if I can find a more robust file metadata analyzer.
FYI – EditPad Pro opens it fine, but it is also a Unicode editor, and I often
use it to see what is 'really' in a text file.

Now for the even weirder part: EditPad Pro DOES display it correctly in text
view, but in hex/Ascii view, it shows the same thing as
NoteTab!
Text View: Speka Piragi
Hex/Ascii View: Speķa Pīr�gi

NoteTab correctly detects it as utf-8. But when I force it to Windows 1252,  it
displays as in NoteTab – incorrectly.
That means that NoteTab is detecting it as Win1252 before it is renamed, and as
UTF8 afterwards. Further, that means that either
Windows or NoteTab is incorrectly detecting the code page. But, since EditPad
Pro detects it correctly, I don't think it's Windows.
This reminds me that, over time, I have often had problems with characters in
NoteTab, and have done everything I could think of to
resolve those issues. But this one seems unresolvable. (except for moving the
file)

Recipes, it turns out, can be very difficult, since they come from every
country, and even when Anglicized, they often retain
oddball characters. Web pages can display these characters fine, but text
editors may have problems. I can't even guess why NoteTab
detects the code page differently, but I am pretty certain that it is a NoteTab
problem alone. I do not know what mechanism editors
use to detect code pages.

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
Axel Berger
Sent: Saturday, January 12, 2013 00:39
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Code page/character issues


John Shotsky wrote:
> If I export from FireFox, then copy the file to another folder, and
> then open the copy in NoteTab, it does not have the problem I am
> discussing. The original still has the problem.
> If I export from FireFox, then rename the file in the original folder
> using Windows, then open the file in NoteTab, it does not have the
> problem I am discussing.

This is really, really weird. There is no explanation I can think of except that
Windows itself is saving extra meta-information
about files and NT can access that. You should do a file compare in hex
(Totalcommander can do that). If they are identical, they
ought to be after a simple copy and must be after rename, then it has to be
external meta-information.

Axel

John Shotsky wrote:
> Text View: Speka Piragi
> Hex/Ascii View: Speķa Pīr�gi
> NoteTab correctly detects it as utf-8. But when I force it to
> Windows 1252, it displays as in NoteTab – incorrectly.

It has to, those characters are not in CP1252. Converting your sample
and assuming mail transfer has not broken anything I get:

Speķa Pīrāgi

These are from the "extended block A"
http://www.sql-und-xml.de/unicode-database/latin-extended-a.html

NoteTab will never be able to deal with them satisfactorily. What I
don't get at all is how Win7 interferes with them, but then I have so
far refrained from using eXPerimental and stick to Win98. Even that
tries to interfere and impose its preferences over mine, but there I can
more or less control it. Your identical byte count might result from
using UTF-16, don't newer Windoses do that? If so the byte count should
be twice the letter count.

> But, since EditPad Pro detects it correctly, I
> don't think it's Windows.

If editpad is true UTF, as you say, then it need not detect anything.
Notetab is stricly 8-bit and strictly codepage based, all it can do is
read letters from inside that single chosen codepage when encoded as
UTF-8. Letters from more than one codepage inside the same document will
never work.

Axel

EditPad Pro is a Unicode editor, so yes, it displays Unicode and utf-8 and many
other code pages correctly. But that
file is not Unicode, it is 8-bit UTF. When one of these files is moved, NoteTab
not only displays it correctly, but it
also saves it correctly, that is, without the accents. So, that is the
workaround for now. What is not acceptable is the
file as first opened, which does not result in a question mark or any valid
character in any code page. It is just
garbage. Previously, NoteTab displayed a question mark for any character out of
its map. Now, it doesn't.

But that's not actually the point anyway. The file is UTF-8 when it is written,
and after it is copied. Nothing is
different about the file except that there is a copy in another location. The
copy displays correctly in NoteTab, but
the original doesn't. The copy works with my clip library, the original doesn't.
If I export the original in NoteTab to
UTF-8 it displays correctly, but of course just copying it works, as does
renaming it, so I can't say the export
actually does anything. However, if I export it to Ascii, question marks show up
for those characters, as expected. The
clip library can't work with a bunch of question marks either, of course, as
there is no way to guess what the missing
character is except through a very, very complex word map which replaces
question marks with characters if the word is
otherwise recognized. So, for the words you correctly detected below, I would
simply substitute the unaccented
characters for accented ones and that would be fine. But I can't do that with
the original, because it displays EXTRA
characters, as indicated in my 'Hex/Ascii' view below.

So, for now, my instructions will include moving the FireFox-exported file to a
work folder, and we'll go with that as
long as it continues to work. As to the problem, I will leave it in the category
of unresolvable.

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
Axel Berger
Sent: Saturday, January 12, 2013 07:23
To: ntb-clips@yahoogroups.com
Subject: Re: [Clip] Code page/character issues


John Shotsky wrote:
> Text View: Speka Piragi
> Hex/Ascii View: Speķa Pīr�gi
> NoteTab correctly detects it as utf-8. But when I force it to
> Windows 1252, it displays as in NoteTab – incorrectly.

It has to, those characters are not in CP1252. Converting your sample
and assuming mail transfer has not broken anything I get:

Speka Piragi

These are from the "extended block A"
http://www.sql-und-xml.de/unicode-database/latin-extended-a.html

NoteTab will never be able to deal with them satisfactorily. What I
don't get at all is how Win7 interferes with them, but then I have so
far refrained from using eXPerimental and stick to Win98. Even that
tries to interfere and impose its preferences over mine, but there I can
more or less control it. Your identical byte count might result from
using UTF-16, don't newer Windoses do that? If so the byte count should
be twice the letter count.

> But, since EditPad Pro detects it correctly, I
> don't think it's Windows.

If editpad is true UTF, as you say, then it need not detect anything.
Notetab is stricly 8-bit and strictly codepage based, all it can do is
read letters from inside that single chosen codepage when encoded as
UTF-8. Letters from more than one codepage inside the same document will
never work.

Axel



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

John Shotsky wrote:
> But that file is not Unicode, it is 8-bit UTF.

To my understanding UTF-8 as a specific encoding is a subset, or rather
one of several possible versions, of Unicode.

> When one of these files is moved, NoteTab not only displays it
> correctly, but it also saves it correctly, that is, without the
> accents.

Sorry, but if those letters do have accents, then anything without is
INcorrect. It may be an acceptable workaround, like Muller or Mueller
instead of Müller, but never correct.

> So, that is the workaround for now.

Right

> But that's not actually the point anyway.

Agreed. Win7 does something strange here and I'm very happy I need not
concern myself with that.

> As to the problem, I will leave it in the category of unresolvable.

Probably best.

Greetings,
With some email when I reply to, or forward, the text with line breaks
has the breaks stripped out.
This means one must scrollllllll across the window to see the entire
line/sentence.

I poked around the NT menu and clips.
I was hoping to find a way to add line breaks based on the width of the
NT window.
This could then be copied back into the email bland to make it easier to
read.

Ideas?
Thanks,
WV-Mike

Menu/Modify/Lines/"Split Lines"  (shift + Ctrl + J)
This and the inverse "Join Lines" can be put on you toolbar as well.

On 2013-01-14 18:33, Mike Breiding - Morgantown WV wrote:
>
>
> Greetings,
> With some email when I reply to, or forward, the text with line breaks
> has the breaks stripped out.
> This means one must scrollllllll across the window to see the entire
> line/sentence.
>
> I poked around the NT menu and clips.
> I was hoping to find a way to add line breaks based on the width of the
> NT window.
> This could then be copied back into the email bland to make it easier to
> read.
>
>
>
>
--
Regards ... Alec (buralex@gmail & WinLiveMess - alec.m.burgess@skype)


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

Here's a tip to get rows:

^!Keyboard CTRL+PAGEUP
^!Set %top%=^$GetRow$
^!Keyboard CTRL+PAGEDN
^!Set %not%=^$GetRow$
^!Set %numrows%=^$Calc(^%bot%-^%top%)$

gets you the number of rows.

^!Jump LINE_START
^!Set %old%=^$GetRow$
^!InsertText ^$StrFill("x ";200)$^%nl%
^!Jump ^%old%
^!Select EOL
^!Set %numcols%=^$GetSelSize$
^!Menu Edit/Undo

gets you the number of columns

Potential problem: you insert into the middle of a wrapped line. I haven't
tested that.


Cheers,

Eb

--- In ntb-clips@yahoogroups.com, "joy8388608"  wrote:
>
> I looked and looked but cannot find any functions to tell how many columns and
rows are visible on the main NT text screen. These values change as the window
is resized, frames are opened (outline, libraries, etc) font is changed...
>
> It can be done in a clip but it's not the prettiest thing and involves
creating a new document, filling it with long lines, and moving around in it a
bit to get the values. I was wondering if anyone knew of a fairly direct way.
>
> Thanks,
> Joy
>

> Re: Inserting line breaks in unbroken text lines  Mon Jan 14, 2013
> 7:23 pm (PST) . Posted by:
>
>
>      
<mailto:buralex@...?subject=Re%3A%20Inserting%20line%20breaks%20in%20unbro\
ken%20text%20lines>
>
>
> "Alec Burgess" alecb3ca Menu/Modify/
> Lines/"Split Lines" (shift + Ctrl + J)
> This and the inverse "Join Lines" can be put on you toolbar as well.

I tried that before and got no where.
Tried it again - worked.
I did not realize the text needed to highlighted to split it.

Thanks, Alec.
-Mike
======================

On 2013-01-14 18:33, Mike Breiding - Morgantown WV wrote:
  >
  >
  > Greetings,
  > With some email when I reply to, or forward, the text with line breaks
  > has the breaks stripped out.
  > This means one must scrollllllll across the window to see the entire
  > line/sentence.
  >
  > I poked around the NT menu and clips.
  > I was hoping to find a way to add line breaks based on the width of the
  > NT window.
  > This could then be copied back into the email bland to make it easier to
  > read.
  >
  >
  >
  >
--
Regards ... Alec (buralex@gmail & WinLiveMess - alec.m.burgess@skype)

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

Thanks, Eb. This is similar to the clip I wrote except my clip creates a
temporary new doc to work in and fills the screen with text. An issue with your
code is that the number of rows is not correct if there are less than a screen
full of rows since I want the maximum number of rows that can be displayed
(screen size) and not the number actually displayed. In other words, if 20 rows
can fit and there are only 10, your code will report 10 instead of 20.

In other words, I guess there isn't a direct way of doing this.
Another idea for the enhancement list!

Also, for beginners following along, the corrected lines should be
^!Keyboard CTRL+PAGEDOWN
and
^!Set %bot%=^$GetRow$

Thanks!
Joy


--- In ntb-clips@yahoogroups.com, "Eb"  wrote:
>
> Here's a tip to get rows:
>
> ^!Keyboard CTRL+PAGEUP
> ^!Set %top%=^$GetRow$
> ^!Keyboard CTRL+PAGEDN
> ^!Set %not%=^$GetRow$
> ^!Set %numrows%=^$Calc(^%bot%-^%top%)$
>
> gets you the number of rows.
>
> ^!Jump LINE_START
> ^!Set %old%=^$GetRow$
> ^!InsertText ^$StrFill("x ";200)$^%nl%
> ^!Jump ^%old%
> ^!Select EOL
> ^!Set %numcols%=^$GetSelSize$
> ^!Menu Edit/Undo
>
> gets you the number of columns
>
> Potential problem: you insert into the middle of a wrapped line. I haven't
tested that.
>
>
> Cheers,
>
> Eb
>
> --- In ntb-clips@yahoogroups.com, "joy8388608"  wrote:
> >
> > I looked and looked but cannot find any functions to tell how many columns
and rows are visible on the main NT text screen. These values change as the
window is resized, frames are opened (outline, libraries, etc) font is
changed...
> >
> > It can be done in a clip but it's not the prettiest thing and involves
creating a new document, filling it with long lines, and moving around in it a
bit to get the values. I was wondering if anyone knew of a fairly direct way.
> >
> > Thanks,
> > Joy
> >
>

Friends,

I need to work with dates, like:

Today is 050113 but I need to run a clip in 05012 plus 30 days.

How this is possible? There exist any clip for that?

Best regards!

Carlos.

--- In ntb-clips@yahoogroups.com, "C"  wrote:
>
> Friends,
>
> I need to work with dates, like:
>
> Today is 050113 but I need to run a clip in 05012 plus 30 days.
>
> How this is possible? There exist any clip for that?
>
> Best regards!
>
> Carlos.
>



You might get some responses if you explain again what you're trying to do.

Several times I've read what you wrote but I have no idea what you want.

john