Cudatext: Opening relative filename in root of current drive (Windows) is broken

[tmsg-gh]

Let's say I have a file c:\Test.txt and I am in subdirectory c:\Somewhere. If I start Cud with
cudatext c:\Test.txt
or
cudatext ..\Test.txt
the file is loaded.

If I try to load this with
cudatext \Test.txt
I get a query whether C:\Somewhere\\Test.txt should be created. The file is not loaded.

[Alexey-T]

hmmm. Cud uses some resolve-functiion of FPC to resolve any path to full path. maybe it fails on \path. it's not easy to fix. not easy to push the fix to Freepascal too.

[Alexey-T]

we can find, is it Freepascal 3.0.4 bug fixed in FPC 3.2 or not fixed yet. get any old version made with FPC 3.2+ (in the About dialog, you see "fpc 3.2" etc).

[tmsg-gh]

I really don't want "any old version" :smile: and I do think that such considerations should not even bother users of Cud. If it's a bug it's got to be fixed. And it's not hard at all, simply check whether the first character of a filename is a "\" and if so prepend the actual drive (just "X:") taken from the full current working directory. Two or three lines I'd guess.

[JairoMartinezA]

Two or three lines so until you can fix that 😄.

Seriously without jokes 😃 I don't know how many things have @Alexey-T for to do, but some times I think that @Alexey-T is looking more for people that can help with Cud or with FP development instead of testers, but is OK I say it with all respect, I can have an idea because my main work is as developer and I know the time that some times one issue/feature can takes to implement or to fix. In my specific case Cud for me is a challenge in an attempt to learn a new language (FP) and all the project one opportunity to join to the Open Source principles, but as all in the life, everything needs time, effort, etc.

[Alexey-T]

Ok, I will test it by myself, with old Cud version and new one, its not hard

[tmsg-gh]

Seriously without jokes smiley I don't know how many things have @Alexey-T for to do, but some times I think that @Alexey-T is looking more for people that can help with Cud or with FP development instead of testers, but is OK I say it with all respect, I can have an idea because my main work is as developer and I know the time that some times one issue/feature can takes to implement or to fix. In my specific case Cud for me is a challenge in an attempt to learn a new language (FP) and all the project one opportunity to join to the Open Source principles, but as all in the life, everything needs time, effort, etc.

I am developer myself. And I would LOVE to help with the development of Cud... but it's written in FP and I am in no way proficient in Pascal anymore (I was, in another life :smile: ), let alone the intricacies of FP.

If Cud were written in C or C++ I would certainly have created a few patches already, for stuff I think would be good to have. But as it stands, I can't.

EDIT: Actually, the problem isn't even that Cud is written in Pascal. I can cobble together some lines of Pascal and though it would take me a lot more time than it would @Alexey-T I would be able to do it (thanks to Google and stackexchange :smile: ). The real problem for me is setting up the development environment and all the required components etc. That requires a lot of FP know-how which I simply don't have.

[JairoMartinezA]

@tmsg-gh are you follow this topic? How to compile CudaText, I could run CudaText following these steps.

[Alexey-T]

the reason of this bug: I stepped back to FPC 3.0.4 (3.2 has OneDrive bug) and it has this bug in ExpandFileName().
to fix it, I need FPC 3.2 or make copy of this file
https://github.com/graemeg/freepascal/blob/master/rtl/inc/fexpand.inc
it has abt 10 new lines vs 3.0.4.
file is big! so I don't want it.

[tmsg-gh]

to fix it, I need FPC 3.2 or make copy of this file
https://github.com/graemeg/freepascal/blob/master/rtl/inc/fexpand.inc
it has abt 10 new lines vs 3.0.4.
file is big! so I don't want it.

Nope, you don't need to this at all.
It should be sufficient to add something like this (rough pseudo code) before you call ExpandFileName() for the filenames given on the command line:
if filename[1]=='\' then filename=substr(current_working_dir,1,2)+filename
This simply checks whether filename starts with a \ and prepends the first two characters of the CWD. Presumably, the following call to ExpandFileName() will then find an already expanded name and will simply return this name. Problem solved.

[tmsg-gh]

Let me add that I find it rather strange that a development system with such a long time in use still exhibits that sort of basic error. I know it's not at all your responsibility but it still leaves me scratching my head.

[Alexey-T]

Nope, you don't need to this at all.
It should be sufficient to add something like this (rough pseudo code) before you call ExpandFileName()

you were right. fixed like it. beta is here
http://uvviewsoft.com/c/
thanks.

[tmsg-gh]

It works... but only partly. With no Cud loaded and in x:\somewhere, I do:
cudatext \test1.txt
and this loads x:test1.txt. OK.
If I now do this:
cudatext \test2.txt
I get the same messagebox as before telling me that x:\somewhere\test2.txt doesn't exist. 2nd/1st instance communication trouble, I assume.

[Alexey-T]

beta updated. better now?

[tmsg-gh]

A qualified "seems better" but I will have to test further in real life. At least for now it seems OK.

[tmsg-gh]

@tmsg-gh are you follow this topic? How to compile CudaText, I could run CudaText following these steps.

I think in the long run (ie if I am really commited to using Cud as my main editor for years to come) I will have to bite the bullet and follow @Jairo-Martinez advice and install FP to enable me to patch the sources on my own.

Should be interesting, to write some Pascal code after almost 40 years of absence. :sweat_smile:

[Alexey-T]

https://idioms.thefreedictionary.com/bite+the+bullet

Ok