Re: [Lazarus] TMask revisited

El 27/10/2021 a las 20:57, Bart via lazarus escribió: Exception_InvalidCharMask(fMask[fMaskInd],fMaskInd); end; Applied in #63847a62. FWIW: having a proper patchfile makes this a lot easier. Do you have git installed or TortoiseGit? Hello, I know, I'm using it, but

Re: [Lazarus] TMask revisited

On Wed, Oct 27, 2021 at 6:42 PM José Mejuto via lazarus wrote: > Line 780, current: > >Add(TMaskParsedCode.OptionalChar); >Add(fCPLength,@fMask[fMaskInd]); >fLastOC:=TMaskParsedCode.OptionalChar; > > Line 780, new: > >if (mocSet in fMaskOpcodesAllowed) then begin

Re: [Lazarus] TMask revisited

El 27/10/2021 a las 13:35, Bart via lazarus escribió: On Wed, Oct 27, 2021 at 1:28 PM José Mejuto via lazarus wrote: "]" must be escaped in all cases, with ranges and with sets or it will be interpreted as a premature closing (ranges). Actually I did not think of that. Could you possibly

Re: [Lazarus] TMask revisited

El 27/10/2021 a las 13:38, Bart via lazarus escribió: On Wed, Oct 27, 2021 at 1:28 PM José Mejuto via lazarus wrote: This is a side effect of the found bug, in ranges the only valid syntax (without sets enabled) is "char-char". So, without [mocSet] [a-dqx] would be invalid? Hello, With

Re: [Lazarus] TMask revisited

On Wed, Oct 27, 2021 at 1:28 PM José Mejuto via lazarus wrote: > This is a side effect of the found bug, in ranges the only valid syntax > (without sets enabled) is "char-char". So, without [mocSet] [a-dqx] would be invalid? -- Bart -- ___ lazarus

Re: [Lazarus] TMask revisited

On Wed, Oct 27, 2021 at 1:28 PM José Mejuto via lazarus wrote: > "]" must be escaped in all cases, with ranges and with sets or it will > be interpreted as a premature closing (ranges). Actually I did not think of that. Could you possibly provide a patch against main and post it on GitLab (or

Re: [Lazarus] TMask revisited

El 26/10/2021 a las 19:01, Bart via lazarus escribió: On Tue, Oct 26, 2021 at 6:48 PM Bart wrote: Point 2 would need (probably a minor) change to the CompileRange method. Attached diff might do what I intended. @José: does it in fact allow ? in a range as a literal, without side effects. I

Re: [Lazarus] TMask revisited

El 26/10/2021 a las 18:48, Bart via lazarus escribió: On Tue, Oct 26, 2021 at 1:38 PM José Mejuto via lazarus wrote: You found a bug, 3. '-' if it is NOT the first char (or the first after the negating !), it is then the indicator for a range Hello, This is a side effect of the found

Re: [Lazarus] TMask revisited

On Tue, Oct 26, 2021 at 6:48 PM Bart wrote: > Point 2 would need (probably a minor) change to the CompileRange method. Attached diff might do what I intended. @José: does it in fact allow ? in a range as a literal, without side effects. I don't really understand the matching algorithm. --

Re: [Lazarus] TMask revisited

On Tue, Oct 26, 2021 at 1:38 PM José Mejuto via lazarus wrote: > You found a bug, I thought about it some more. Inside a range everything is treated as a literal, the only exceptions are: 1. [?] 2. '!' as the first char in a range when [mocNegateGroup] is enabled. 3. '-' if it is NOT the first

Re: [Lazarus] TMask revisited

El 24/10/2021 a las 15:48, Bart via lazarus escribió: It looks like escaping does not work as advertised? Seems like escaping is NOT supported in ranges or sets, but only outside them? If that is the case (and by design) then, with [mocRange] enabled, you can only have '-' in a range if the

Re: [Lazarus] TMask revisited

On Mon, Oct 25, 2021 at 7:20 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > As I see it now, we are planning to remove all the old TMask stuff (in > the future) and replace it with the new and improved TMask. > > Shouldn't that mean that we should also deprecate the CreateLegacy

Re: [Lazarus] TMask revisited

On Wed, Oct 20, 2021 at 11:42 AM Bart wrote: > > The Create in TMaskBase is never called directly by a user. He will get a > > deprecated message from elsewhere. As I see it now, we are planning to remove all the old TMask stuff (in the future) and replace it with the new and improved TMask.

Re: [Lazarus] TMask revisited

On Sun, Oct 24, 2021 at 4:26 PM José Mejuto via lazarus wrote: > > @José: is this indeed as intended? > No, in fact escaping was introduced to allow "[a\-]" to be interpreted > as literal set "a-". I must check my test cases, maybe a simple missing > if. Please let me check it tomorrow, monday.

Re: [Lazarus] TMask revisited

El 24/10/2021 a las 15:48, Bart via lazarus escribió: It looks like escaping does not work as advertised? Seems like escaping is NOT supported in ranges or sets, but only outside them? If that is the case (and by design) then, with [mocRange] enabled, you can only have '-' in a range if the

Re: [Lazarus] TMask revisited

On Sun, Oct 24, 2021 at 3:26 PM Bart wrote: > It looks like escaping does not work as advertised? Seems like escaping is NOT supported in ranges or sets, but only outside them? If that is the case (and by design) then, with [mocRange] enabled, you can only have '-' in a range if the range

Re: [Lazarus] TMask revisited

On Sat, Oct 23, 2021 at 11:33 PM Bart wrote: > I renamed mocOptionaChar to mocSet and added some comments in the code. > > @José: are these comments correct? I'm still strugling with the difference between mocRange and mocSet (previously mocOptionalChar). Consider the following mask: [a-c]

Re: [Lazarus] TMask revisited

On Sat, Oct 23, 2021 at 10:39 PM Juha Manninen via lazarus wrote: > In 964d5f4d69 I changed most names as you suggested. > The original TMaskOpCode is now TMaskParsedCode because it is not related to > the other enums directly. > I did the changes before reading your last mail. I renamed

Re: [Lazarus] TMask revisited

On Tue, Oct 19, 2021 at 10:44 AM José Mejuto via lazarus wrote: > With "eMaskOpcodeRange" and "eMaskOpcodeOptionalChar" enabled to match > "a" or "-" or "z" the "-" must be escaped (something like regex) using > the escapechar, by default "\", in this way "[a\-z]". That does not seem to work

Re: [Lazarus] TMask revisited

El 23/10/2021 a las 22:18, Bart via lazarus escribió: Q2: @José: the TMaskOpCode enums are indexed, and there is a gap in the index. Is the index necessary for the code to work? Is the gap necessary? In the Add() method, the enum is cast to a byte, this should also work if no indices are used

Re: [Lazarus] TMask revisited

On Sat, Oct 23, 2021 at 11:21 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > AFAICS the TMaskOpCode and TMaskOpcodesEnum types are not related at all. > TMaskOpCode is some kind of internal identifier in the internal mask > representation, whereas TMaskOpcodesEnum are options for

Re: [Lazarus] TMask revisited

On Sat, Oct 23, 2021 at 12:22 PM Bart wrote: > Then we have TMaskOpcode and TMaskOpcodesEnum types. > The first one is more or less an internal type. > The latter one is for common user interface. > Since TMaskOpCode is used in the interface part of TMask, we must have > it in the interface part

Re: [Lazarus] TMask revisited

On Sat, Oct 23, 2021 at 6:16 PM José Mejuto via lazarus wrote: > Because in the code each syntax piece can be enabled and disabled, even > "*" and "?" can be disabled to not be interpreted as a mask char, so to > allow granularity a name to that "feature" must be given. Yep, OK. -- Bart --

Re: [Lazarus] TMask revisited

El 23/10/2021 a las 12:02, Bart via lazarus escribió: I can understand why having [a-e] is good (and better than [abcde]). I was just confused by the fact that these had different names. Hello, Because in the code each syntax piece can be enabled and disabled, even "*" and "?" can be

Re: [Lazarus] TMask revisited

El 23/10/2021 a las 12:22, Bart via lazarus escribió: On Sat, Oct 23, 2021 at 12:02 PM Bart wrote: since we are still looking for a better (?) name for the eMaskOpcodeOptionalChar enum: This brings me to another point, and please, please, please don't see this as criticism of feel offended

Re: [Lazarus] TMask revisited

On Sat, Oct 23, 2021 at 12:22 PM Bart wrote: > So: > TInternalMaskOpcode (integers) > TMaskOpcode (the enums) > TMaskOpcodes: set of TMaskOpcode > Enum names: moXXX Maybe better make that mopXXX, as not to confuse them with old moXXX TMaskOption enums. -- Bart --

Re: [Lazarus] TMask revisited

23.10.2021 13:22, Bart via lazarus пишет: On Sat, Oct 23, 2021 at 12:02 PM Bart wrote: since we are still looking for a better (?) name for the eMaskOpcodeOptionalChar enum: This brings me to another point, and please, please, please don't see this as criticism of feel offended by me.

Re: [Lazarus] TMask revisited

On Sat, Oct 23, 2021 at 12:22 PM Bart wrote: > Naming conventions. Also: we typically have the convention of nameing fileds in a class Fxxx Here we have cXXX and eXXX. Again: not meant as crtitcism. -- Bart -- ___ lazarus mailing list

Re: [Lazarus] TMask revisited

On Sat, Oct 23, 2021 at 12:02 PM Bart wrote: > since we are still looking for a better (?) name for the > eMaskOpcodeOptionalChar enum: This brings me to another point, and please, please, please don't see this as criticism of feel offended by me. Naming conventions. Typically we don't have

Re: [Lazarus] TMask revisited

On Thu, Oct 21, 2021 at 10:29 AM José Mejuto via lazarus wrote: > So the question is, why sets if ranges can be used ? Because sometimes > you need to exclude strings that starts with number 1: > > "[0234567989][a-z]" > > > Naming them different just confuses me (which probably is my fault). > >

Re: [Lazarus] TMask revisited

On Thu, Oct 21, 2021 at 11:30 AM José Mejuto via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Now you need to match a string that starts with a number and the second > char must be a letter, with a set it will be too large and unclear: > > "[0123456789][abcdefghijklmnopqrstuvwxyz]*" > With

Re: [Lazarus] TMask revisited

El 20/10/2021 a las 22:59, Bart via lazarus escribió: Range syntax: [a-z] Set syntax: [abcdefghijklmnopqrstuvwxyz] What would be the effective difference between [a-e] and [abcde] then? I did understand that both meant: a single charcter being either 'a', 'b', 'c', 'd', or 'e'? Hello,

Re: [Lazarus] TMask revisited

On Wed, Oct 20, 2021 at 9:37 PM José Mejuto via lazarus wrote: > >> There are IMHO two front lines, one is the "replace" of TMask in > >> internal LCL functions, exposed or not to the user, and in this case all > >> options that allow mimic the old behaviour should be disabled. The other > >>

Re: [Lazarus] TMask revisited

On Wed, Oct 20, 2021 at 9:37 PM José Mejuto via lazarus wrote: > In the "masks" world sets are a group of chars inside "[]", optional > chars, option chars, or other fancy name. > > Range syntax: [a-z] > Set syntax: [abcdefghijklmnopqrstuvwxyz] What would be the effective difference between

Re: [Lazarus] TMask revisited

El 20/10/2021 a las 11:34, Bart via lazarus escribió: There are IMHO two front lines, one is the "replace" of TMask in internal LCL functions, exposed or not to the user, and in this case all options that allow mimic the old behaviour should be disabled. The other one is the TMask itself which

Re: [Lazarus] TMask revisited

On Tue, Oct 19, 2021 at 7:11 PM Juha Manninen via lazarus wrote: > The Create in TMaskBase is never called directly by a user. He will get a > deprecated message from elsewhere. But it is part of the interface. Some poor soul might implement it's own dereive control from TMaskBase and rely on

Re: [Lazarus] TMask revisited

On Wed, Oct 20, 2021 at 11:00 AM José Mejuto via lazarus wrote: > There are IMHO two front lines, one is the "replace" of TMask in > internal LCL functions, exposed or not to the user, and in this case all > options that allow mimic the old behaviour should be disabled. The other > one is the

Re: [Lazarus] TMask revisited

El 19/10/2021 a las 16:32, Bart via lazarus escribió: Thanks for explaining that. Sounds to me like you should not enable both of them, unless you want something to match 'a'..'f' or '+' or '-' [a-f+\-] ? Hello, There are IMHO two front lines, one is the "replace" of TMask in internal LCL

Re: [Lazarus] TMask revisited

On Tue, Oct 19, 2021 at 5:34 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > With only eMaskOpcodeOptionalChar enabled [a-z] would match 'a', '-' or > 'z'? > (This would be the old behaviour of TMask) > There is now a constant MaskOpCodesNoEscape which leaves out

Re: [Lazarus] TMask revisited

On Tue, Oct 19, 2021 at 10:44 AM José Mejuto via lazarus wrote: > Yes, at least it should. To completely disable the "[" syntax three > options must be removed from default, "eMaskOpcodeOptionalChar", > "eMaskOpcodeRange" and "eMaskOpcodeAnyCharOrNone". > > eMaskOpcodeAnyCharOrNone = [???]

Re: [Lazarus] TMask revisited

El 18/10/2021 a las 22:39, Bart via lazarus escribió: Most people are familiar with ranges "[a-z]", optional chars use the same "[" syntax but without the dash "-", so "[abcde]" matches one position with any of those chars or if you negate the set "[!abcde]" it will match any char *except* any

Re: [Lazarus] TMask revisited

On Sun, Oct 17, 2021 at 7:37 PM José Mejuto via lazarus wrote: > OpcodeOptionalChar (maybe the name should be OptionChar) works in the > compiled stream as CheckMatch and if match go to next char; if not match > continue checking without advance in the target string. > > Most people are familiar

Re: [Lazarus] TMask revisited

16.10.2021 15:13, Maxim Ganetsky via lazarus пишет: 16.10.2021 11:54, Juha Manninen via lazarus пишет: On Sat, Oct 16, 2021 at 11:20 AM Juha Manninen mailto:juha.mannine...@gmail.com>> wrote:     Yes, the TMaskWindows indeed behaves wrong. '**.pas*' matches with     '*abc.pas.bak*'. Fixed

Re: [Lazarus] TMask revisited

El 17/10/2021 a las 9:08, Juha Manninen via lazarus escribió: What does eMaskOpcodeOptionalChar do? It's not very clear to me from the comments in the code. Good question. It is the one syntax I don't fully understand yet. Below is an explanation from José himself. I will study this

Re: [Lazarus] TMask revisited

On Sun, Oct 17, 2021 at 1:10 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I see you implemented the "old" constructors with the TMaskOptions > parameter and deprecated them as suggested. > Thanks for that. > Maybe add: 'Will be removed in 2.4' or similar to the deprecated

Re: [Lazarus] TMask revisited

On Sat, Oct 16, 2021 at 11:20 PM Juha Manninen via lazarus wrote: > Ideas? Comments? I see you implemented the "old" constructors with the TMaskOptions parameter and deprecated them as suggested. Thanks for that. Maybe add: 'Will be removed in 2.4' or similar to the deprecated message? The

Re: [Lazarus] TMask revisited

I turned the define RANGES_AUTOREVERSE into a run time option in 67111d9a30. A boolean RangeAutoReverse is True by default. I don't really know when somebody would want to turn it off. I also added constructors and functions for legacy syntax, which means [?] represents a literal '?' and

Re: [Lazarus] TMask revisited

On Sat, Oct 16, 2021 at 3:19 PM Maxim Ganetsky via lazarus wrote: > > So far, this has not been reporduced by others in this thread. > > Juha already reproduced it. Happens in `Find in Files` dialog. That's GMail for you. When I wrote that, it was a reply to the only new message in this thread

Re: [Lazarus] TMask revisited

16.10.2021 16:11, Bart via lazarus пишет: On Sat, Oct 16, 2021 at 12:14 AM DougC via lazarus wrote: Shouldn't the mask "*.pas*" be used to match file.pas.bak ? If so, the old code and new code are ok. You miss the point. It was said that the mask '*.pas;*.pp;*.inc' now also matched the

Re: [Lazarus] TMask revisited

On Sat, Oct 16, 2021 at 12:14 AM DougC via lazarus wrote: > Shouldn't the mask "*.pas*" be used to match file.pas.bak ? If so, the old > code and new code are ok. You miss the point. It was said that the mask '*.pas;*.pp;*.inc' now also matched the file foo.pas.bak, which would be a bug. So

Re: [Lazarus] TMask revisited

16.10.2021 13:00, Juha Manninen via lazarus пишет: P.S. Not related to the Mask code but I installed TortoiseGit on Windows. It works OK but still does not offer anything as good as *gitk*. The "Show log" view shows commits and their messages, and names of changed files but no diffs. Getting

Re: [Lazarus] TMask revisited

16.10.2021 11:54, Juha Manninen via lazarus пишет: On Sat, Oct 16, 2021 at 11:20 AM Juha Manninen mailto:juha.mannine...@gmail.com>> wrote: Yes, the TMaskWindows indeed behaves wrong. '**.pas*' matches with '*abc.pas.bak*'. Fixed in a111270ed0. Please test. No code changes were

Re: [Lazarus] TMask revisited

On Sat, Oct 16, 2021 at 12:23 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Yes, there should be an option for backwards compatible syntax, like > "[?]" . However the small changes in the syntax can be seen as improvements. > > There already is a define for converting "[z-a]" to

Re: [Lazarus] TMask revisited

On Sat, Oct 16, 2021 at 11:20 AM Juha Manninen wrote: > Yes, the TMaskWindows indeed behaves wrong. '**.pas*' matches with ' > *abc.pas.bak*'. > Fixed in a111270ed0. Please test. No code changes were needed. I only disabled one of the Windows quirks, namely eWindowsQuirk_Extension3More. Please

Re: [Lazarus] TMask revisited

On Fri, Oct 15, 2021 at 3:38 PM Maxim Ganetsky via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Please try with, for example bla.pas and bla.pas.bak files. > I got another mail from Maxim. It was also sent to this list but didn't appear. I also configured my Windows under Virtualbox for

Re: [Lazarus] TMask revisited

Shouldn't the mask "*.pas*" be used to match file.pas.bak ? If so, the old code and new code are ok. Doug C. On Fri, 15 Oct 2021 17:09:03 -0400 Bart via lazarus wrote On Fri, Oct 15, 2021 at 2:38 PM Maxim Ganetsky via lazarus wrote: >

Re: [Lazarus] TMask revisited

On Fri, Oct 15, 2021 at 1:55 AM Juha Manninen via lazarus wrote: > > On Thu, Oct 14, 2021 at 7:57 PM Bart via lazarus > wrote: >> >> You have changed the existing interface for both TMask and the >> Matches(Windows)Mask(List) functions. >> TMaskOptions has been removed. > > > It can be added

Re: [Lazarus] TMask revisited

On Fri, Oct 15, 2021 at 2:38 PM Maxim Ganetsky via lazarus wrote: > Please try with, for example bla.pas and bla.pas.bak files. Mask: *.pas;*.pp;*.inc Filename: file.pas.bak Result: does not match, both in the old code and the new code. -- Bart --

Re: [Lazarus] TMask revisited

On Fri, Oct 15, 2021 at 3:38 PM Maxim Ganetsky via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Please try with, for example bla.pas and bla.pas.bak files. > I did basically that. I copied a .pas file to .pas.bak. Find in Files does not find extra entries with File mask

Re: [Lazarus] TMask revisited

On Fri, Oct 15, 2021 at 3:10 PM Sven Barth via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Non-static class methods *do* have a Self parameter, but it's the class > type and not the class instance. They can also be virtual, which is a > really great feature of the Object Pascal language (I

Re: [Lazarus] TMask revisited

15.10.2021 02:07, Juha Manninen via lazarus пишет: On Thu, Oct 14, 2021 at 12:53 AM Maxim Ganetsky via lazarus mailto:lazarus@lists.lazarus-ide.org>> wrote: Don't know if it is related but just noticed that `Find in files` dialog now "ignores" file masks. E. g. I have the

Re: [Lazarus] TMask revisited

Juha Manninen via lazarus schrieb am Fr., 15. Okt. 2021, 14:03: > This may be a dummy question but what does "static" do for a class > procedure? > José's mask code has for example: > > class procedure Exception_IncompleteMask(); static; > > I thought class procedures are kind of static

Re: [Lazarus] TMask revisited

This may be a dummy question but what does "static" do for a class procedure? José's mask code has for example: class procedure Exception_IncompleteMask(); static; I thought class procedures are kind of static anyways, meaning they don't have a Self pointer. Juha --

Re: [Lazarus] TMask revisited

I restored the backwards compatible TMaskOptions in 04b0a04a45. Please test. When ranges (sets) are disabled, [] is interpreted as literal []. Works perfectly. Next I will study the little syntax differences. There should be a backwards compatible option for those, too. Juha --

Re: [Lazarus] TMask revisited

On Fri, Oct 15, 2021 at 2:54 AM Juha Manninen wrote: > Noticable the ability to NOT interpret [] as a set in the mask has now >> disappeared. >> > > How should a range / set [] be interpreted? > Ok, forget that question. I will study this more tomorrow. Juha --

Re: [Lazarus] TMask revisited

On Thu, Oct 14, 2021 at 7:57 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > You have changed the existing interface for both TMask and the > Matches(Windows)Mask(List) functions. > TMaskOptions has been removed. > It can be added for compatibility. Noticable the ability to NOT

Re: [Lazarus] TMask revisited

On Thu, Oct 14, 2021 at 12:53 AM Maxim Ganetsky via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Don't know if it is related but just noticed that `Find in files` dialog > now "ignores" file masks. > > E. g. I have the following file mask: `*.pas;*.pp;*.inc;*.lpr;*.lfm`, > but it also finds

Re: [Lazarus] TMask revisited

On Thu, Oct 14, 2021 at 6:54 PM Bart wrote: > This was discussed at length in february. From the discussion in february: Feb 24 11:22 AM > And also define if a compatibility break is a bug in the new code or in > the old code. In example my mask supports (there is a define to disable) >

Re: [Lazarus] TMask revisited

On Wed, Oct 13, 2021 at 5:16 PM Juha Manninen via lazarus wrote: > Please test everybody. I will read the old posts more carefully later. You have changed the existing interface for both TMask and the Matches(Windows)Mask(List) functions. TMaskOptions has been removed. Noticable the ability to

Re: [Lazarus] TMask revisited

13.10.2021 18:16, Juha Manninen via lazarus пишет: I restored the great TMask implementation by José Mejuto in our development branch. I also fixed a few issues that hindered the transition last time. It was discussed at least in this mailing list with title  "unit Masks vs. unit FPMasks" in

Re: [Lazarus] TMask revisited

Hi, Am 13.10.21 um 18:28 schrieb Juha Manninen via lazarus: On Wed, Oct 13, 2021 at 7:03 PM Marcus Sackrow via lazarus mailto:lazarus@lists.lazarus-ide.org>> wrote: it breaks "make all" for x86_64-linux LazBuild, yes. Again I forgot to test compiling it. Now it is fixed. Please test.

Re: [Lazarus] TMask revisited

On Wed, Oct 13, 2021 at 7:03 PM Marcus Sackrow via lazarus < lazarus@lists.lazarus-ide.org> wrote: > it breaks "make all" for x86_64-linux > LazBuild, yes. Again I forgot to test compiling it. Now it is fixed. Please test. Regards, Juha -- ___

Re: [Lazarus] TMask revisited

Hi, Am 13.10.21 um 17:16 schrieb Juha Manninen via lazarus: I restored the great TMask implementation by José Mejuto in our development branch. I also fixed a few issues that hindered the transition last time. It was discussed at least in this mailing list with title  "unit Masks vs. unit

[Lazarus] TMask revisited

I restored the great TMask implementation by José Mejuto in our development branch. I also fixed a few issues that hindered the transition last time. It was discussed at least in this mailing list with title "unit Masks vs. unit FPMasks" in 23 February this year. The logic in ShellCtrls unit is