To save some trial and error, can anybody tell me which was the last version of Lazarus (for Linux, if that makes a difference) that doesn't exhibit the problem of an 'm' producing a line feed and an 'i' producing a tab then an 'i'?
Thanks.

Mailing lists / lazarus / 2020-05
39 messages · 8 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
To save some trial and error, can anybody tell me which was the last version of Lazarus (for Linux, if that makes a difference) that doesn't exhibit the problem of an 'm' producing a line feed and an 'i' producing a tab then an 'i'?
Thanks.
Brian wroteTo save some trial and error, can anybody tell me which was the last version of Lazarus (for Linux, if that makes a difference) that doesn't exhibit the problem of an 'm' producing a line feed and an 'i' producing a tab then an 'i'?
check your key map settings in lazarus configuration... it sounds like a macro or you have configured 'm' to line feed and 'i' to tab-'i'...
I will look (again), but this is happening reproducibly on a totally clean build of trunk (via fpcupdeluxe), I have tried rebuilding Lazarus with clean all and *just once* I got things to work again using qt5. I've never managed to get things to work again since. I have changed no key map settings, I have configured no macros. This is using 64-bit Linux Mint 19.3, should anybody feel that makes a difference, and BTW, I have also tried switching keyboards, with absolutely no effect. I had about 6-9 months away from using Lazarus, during that time I changed from using Ubuntu 18.04 LTS to Mint 19.3. I didn't see the problem on my old setup, it has occurred every time except that ONE occasion on the current setup. The same PC, just the operating system changed.
Brian.
I forgot to add - I totally erased fpcup's entire tree and rebuilt from scratch. No change.
Brian.
Just some additional information here. I have a copy of the latest Debian-based version of Linux Mint running in a virtual machine (my main system is the Ubuntu-based Mint) so I installed Lazarus and FPC from the Debian repositories. This gave me FPC 3.0.4 and Lazarus 2.0.0, with some additional versioning which I think indicates that it's been built and packaged by Debian. This combination works perfectly, no trace of the problem.
So, I guess the next thing I do is to try the various SourceForge versions and see how far back I have to go to get rid of the problem under Ubuntu-based Mint. I will report back when I have an answer, but depending on how many regressions are needed, it may take me a day or two. Watch this space...
Brian.
this is good because it eliminates the possibility of a conf file being used that you've not found on the problematic machine...
i would search, first, for the various lazarus related conf files... i'm almost willing to bet there's one/some that you're missing... almost willing ;)
Just some additional information here. I have a copy of the latest Debian-based version…
Just a suggestion:
Get the FPC and Lazarus sources from Subversion (using a releqase tags for both).
I do that all the time on my machines. I have created a script for Raspbian and another for Linux (Ubuntu/Debian).
It works well every time, for example just last week I installed on two notebooks which had Ubuntu 18.04 LTS installed with the Mate desktop.
I have never seen this problem on either Raspbian or Mate installs. Now on FPC 3.0.4 and Lazarus 2.0.8 (64 bit both)
That is what I believe fpcupdeluxe does. I used it to install from trunk, both fpc and lazarus. The software built correctly, and fpcupdeluxe is stated to use its own target directories (which seems to be the case) but I still saw the problem.
Well, I've seen it regularly on this machine, and what puzzles me is that I have never played around with the keyboard mapping nor even defined a macro, which has been suggested as the likely cause.
I tried downloading Lazarus 2.0.0 from SourceForge, and regressing to that, but it still showed the problem.
However, experiment does show that I can do an install into a new virtual machine and not see the problem, so I agree with wkitty that it looks like a configuration problem, irrespective of the fact that I have never used those features he mentions. What I intend to do is to run some searches of my entire tree, looking for anything with lazar or fp in the name. Once I've got that information, I'll work through the lists and delete anything that looks fpc or lazarus related. Then I'll try fpcupdeluxe with another copy of trunk, and see whether it fixes the problem. It will take some time.
Brian.
if you are on linux, something like this would be fairly quick and easy to use...
sudo find / -type d \( -path .git -o -path .svn -o -path .cvs \) -prune -o -type f \( -iname "*.conf" -o -iname "*.cfg" -o -iname "*.cnf" \)
it should find every *.conf, *.cfg, and *.cnf file on the system while skipping all .git, .svn, and .cvs directories... you really don't need to dig through all of those, in most cases, ya know? ;)
once you have the list of matching files, then you can work through it looking for lazarus and fpc related configuration files... remember that not all of them will start with laz or fp...
while testing the above on my system which i've recently removed lazaruz and fpc from for needed drive space, i found a leftover fppkg.cfg in my ~/.config directory... knowing that directory was used for some things then lead me to look at it closer... i found a lazarus directory in there with a reg.xml apparently from the jedi tool(s) along with a lhelp directory with a conf for the lazaruz lhelp tool...
i also found a few left over fpc.cfg files in several project directories but those i kept because they contained only information on the project and nothing specific to lazarus or fpc...
hopefully the above find command will be helpful to you... i keep a copy of it in one of my hint files so i don't lose it from my command history ;)
I tried both methods of generating a list of configuration files, and I worked down both lists looking for anything which seemed fpc/lazarus related, and deleted everything I could find. I then deleted back fpcupdeluxe's target directory, and went through my home directory looking for hidden directories. In short, I deleted every damned thing I could find!
I then reinstalled, via fpcupdeluxe, copies of trunk for both fpc and lazarus. According to fpcupdeluxe, everything compiled and built correctly.
I ran lazarus via the link provided by fpcupdeluxe, and tried typing some text. NO change whatsoever. :( A lower case 'i' still produced tab and 'i', and a lower case 'm' produced a line feed.
At this point, I think I give up. I don't want to switch my main system to LMDE, so I will just run lazarus under LMDE in a virtual machine, where the 'i' and 'm' keys work exactly as expected, and use a shared folder, pointing a logical link to my source tree.
I reiterate that I have NEVER (knowingly, I suppose) remapped a keyboard nor used a macro while using lazarus.
Brian.
I forgot to add - I totally erased fpcup's entire tree and rebuilt from scratch. No…
Brian wroteI forgot to add - I totally erased fpcup's entire tree and rebuilt from scratch. No change.
It's not about recompiling Lazarus. Probably more related to your customised settings in your $HOME/.lazarus/ directory.
Start your lazarus from the command line with the paramater:
./lazarus --pcp=/tmp/lazarus
where "/tmp/lazarus" is a totally empty directory. That should give you Lazarus with 100% default config values. If the problem goes way, then it's a key mapping issue in your ~/.lazarus/ directory.
Regards,
Graeme
I tried that. Now *every* keypress is duplicated. Thanks for the attempt, though!
I now have a working setup by way of using lazarus in a Linux Mint Debian virtual machine and using a shared folder with a link to my source tree. Since I don't want to switch to LMDE totally, it's an acceptable workround. I write the code via the VM and then compile and debug under standard Linux Mint.
I had previously tried deleting both the ~/.lazarus and also a ~/.lazarus64 directory, with no effect on the problem.
Brian.
PM Brian wroteI tried that. Now *every* keypress is duplicated.
It was allegedly fixed in trunk r63089 less than 3 weeks ago. See:
https://bugs.freepascal.org/view.php?id=30863
If nobody gets the duplicate key problem with trunk any more, that issue and all its related issues can finally be resolved. Please test everybody.
Juha
I just updated both trunks (via fpcupdeluxe) and rebuilt, and now the i => tab-i and m => line feed problems have disappeared. :) :)
Starting Lazarus per Graeme's instructions (i.e. with a blank config) no longer produces duplicate keypresses either.
Whoever fixed that, well done and thank you VERY much! :)
Brian.
the link in the above linked bug report tells you that ;)
And the fact that I didn't look up the bug report so that I could name the person in some way invalidates the generalised thank you that I posted?
Brian.
I just updated both trunks (via fpcupdeluxe) and rebuilt, and now the i => tab-i and m…
Regrettably, it appears I spoke too soon. I fired up Lazarus again and the problem is back. I'm compiling trunk for both fpc and lazarus using fpcupdeluxe. To recap, this is under Linux Mint 19.3 64-bit (Ubuntu base). I have absolutely *NOT* done any keyboard remapping nor defined any macros since everything last worked correctly. The setup I have in a LMDE (Linux Mint Debian) virtual machine still works correctly.
I will update both setups, so that I know I am (should be!) running exactly the same versions of trunk, and report back in due course.
Brian.
Perhaps try another version of fpcupdeluxe?
I downloaded the latest as then was for linux on x86_64. I see there has been another release since I wrote my post. I'll give it a try. I guess I could also try the qt5 version.
Brian.
OK, my last word on this subject. I can only conclude that there is some kind of goofy multi-way interaction going on between Lazarus and other programs. I have tried multiple versions of Lazarus, using both the gtk2 and qt5 versions of fpcupdeluxe. In all cases, I saw the i -> tab & i and m -> newline. I do NOT see this on the Debian-based version of Mint running in a virtual machine, and I also set up another VM with the same Ubuntu-based version of Mint (19.3 64-bit) as I have on the host. Neither VM showed the problem with Lazarus!
The final straw is that I just set up a new PC for my wife, again Ubuntu Mint 19.3, and out of curiosity, I installed Lazarus. The keys worked fine.
I have no idea what is going on. I reiterate that I have removed all config files, using the combination of wkitty42's commandline magic *and* my kfinds, and that I have done absolutely no key remapping nor macro defining. Twice, and ONLY twice, I have had the problem go away after a rebuild of FPC and Lazarus, but rebooting the PC brought the problem back again.
I've given up. I have wasted enough time on trying to sort this problem. At least as long as it all works, I will just use Lazarus in a VM, and transfer the completed source files to my host machine for a final compilation.
Brian.
You allways used fpcupdeluxe??
Perhaps these originals are better?
Thanks, but I have also tried various .DEBs from Sourceforge (I think I stated that in an earlier message, but not 100% certain) with no change in the problem.
Brian.
PM Brian wroteThanks, but I have also tried various .DEBs from Sourceforge (I think I stated that in an earlier message, but not 100% certain) with no change in the problem.
The .deb packages provide a released version.
If something is fixed in the development version (trunk), you must use it instead.
fpcupdeluxe is not needed. Just get the sources (svn co ...) and then build with "make". Run it directly ($ ./lazarus). No installation is required.
FPC must be installed obviously before all that. The version from your distro's repository will do.
Juha
Unless you feel that fpcupdeluxe is not installing the trunk version when that is selected, I really can't see how removing it from the equation will change anything. fpcupdeluxe is just a convenience. Nevertheless, I will give it a try, subversion and then building it myself, but more in hope than expectation. Watch this space...
Brian.
I checked out trunk (r63245) via subversion, which reported no errors. I then changed into the subdirectory, and ran
make -B
The following is a cut and paste of the results.
So, I decided to try running an update, in case something had failed to download, and I'd missed it. Again, cut and pasted.
So, nothing to update.
fpcupdeluxe at least seems to build correctly...
Oh, BTW, the fpc I have installed is 3.0.4. I am fairly sure, but not absolutely certain, that this would have been from the .DEBs downloaded from Sourceforge.
Brian.
Brian wroteOn 5/28/20 6:17 PM, Brian via lazarus wrote: > On 5/28/20 3:50 PM, Juha Manninen via lazarus wrote: >> On Thu, May 28, 2020 at 7:38 PM Brian via lazarus >> wrote:
Omission from last post corrected below...
Sorry, I should have added to the last message that a new checkout (deleting the entire target directory tree first) via fpcupdeluxe built correctly, but still showed the same errors with 'i' and 'm'. The only difference in the compilation (that I know of) with fpcupdeluxe is that it's using the trunk version of fpc as well as of lazarus.
Brian.
AM Brian wroteThe only difference in the compilation (that I know of) with fpcupdeluxe is that it's using the trunk version of fpc as well as of lazarus.
Using fpc trunk i.c.m. lazarus trunk is a recipe for problems. Most of them will be fixed on either side, but not always (ATM there is a bug in fpc trunk that makes startlazaus unable to find the lazarus executable on Windows).
Also fpcuddeluxe might (I did not check) built both compiler and lazarus with mor aggressive optimization settings.
Most likely this has no impact on the 'i' and 'm' issue you are experiencing though, since I have seen reports in the bugtracker about that before.
As it stands, nobody knows why this happens.
It is a Lazarus/LCL/WS issue though, since other programs don't have that issue.
Thanks for the input. The build which failed totally was fpc 3.0.4 with lazarus trunk. The two trunks together did at least succeed in building a version of lazarus which runs. I only did the further test in response to Juha's posting. For now, I'm just sticking with my version of lazarus built in a Mint Debian VM, it seems to exhibit no problems, at least none that I have seen so far.
Brian.
On Fri, May 29, 2020 at 12:54 AM Brian via lazarus Using fpc trunk i.c.m. lazarus trunk…
PM Bart wroteIt is a Lazarus/LCL/WS issue though, since other programs don't have that issue.
Yes, let's hope GTK3 bindings will be better. Now it is alpha but already usable for many applications.
For Brian I recommend using QT5 bindings. It has no problem with keys.
Lazarus trunk from fpcupdeluxe or from SVN directly should behave the same. I don't know why the build failed.
Juha
Unless you have some reason to believe that the QT5 version of fpcupdeluxe doesn't build lazarus with QT5 bindings, I have already tried this idea and still seen the same problem. Yes, I deleted back EVERYTHING except for the actual fpcupdeluxe executable - all config files and the entire target directory - from the GTK2 build. Then I downloaded the QT5 version of the executable and ran that. Once again, it built, but I still saw the key mapping etc. problem.
Since I've come this far, though, I guess I'm willing to try building the lazarus code downloaded via subversion with the QT5 bindings. Is there a web page, or some other documentation, that leads me though doing that? I've never previously built the QT5 version except the attempt to build it via fpcupdeluxe.
Brian.
That should be enough?!!
Look at tools/compile IDE, LCL Listbox:
Screenshot:
Unless you have some reason to believe that the QT5 version of fpcupdeluxe doesn't build…
Yes I have a reason to believe so.
The LCL widgetset used for fpcupdeluxe executable does not affect how Lazarus is built.
You can check the current widgetset of Lazarus executable from Help -> About Lazarus.
All this hassle proves that fpcupdeluxe should not be used for the simple task of building native (OS, CPU) version of Lazarus trunk. It only complicates things and confuses.
Getting sources and building Lazarus is so easy when FPC is already installed. Things are different when you want FPC trunk. It is not as trivial. (*) Cross-compilation is another good reason to use fpcupdeluxe. I have understood it shines there.
As John Landmesser showed, Tools -> Configure "Build Lazarus" ...
Juha
(*) I have FPC trunk built and installed automatically from Manjaro
AUR. It was actually trivial. :)OK, my misunderstanding. I thought you were talking about a difference in actually building Lazarus from sources. I will give it a try.
Brian.
Well, I still can't get Lazarus to build from the sources obtained through subversion. Here's the output, with an initial update to make sure I was building the latest version.
So, I switched to the version which I had successfully built using fpcupdeluxe, and followed John's instructions. While the gtk2 version did build correctly, but showed the 'i' and 'm' problems, the qt5 version did not even build. I got an error about an undefined reference in Qtwidgets.pas to QTextEdit_setPlaceholderText.
If there's anything else you need me to try, let me know. For the moment, I'm back to using my LMDE VM, which shows none of this 'i' and 'm' nonsense, even with the gtk2 setting.
Brian.
Fpcupdeluxe maintainer message:
Currently, QT5 Linux Lazarus will not build due to outdated libQT5pas.so that fpcupdeluxe uses.
The same is valid for macOS.
This issue will be solved in next release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20200530/442ff0b2/attachment.html>
Thanks, that solves that question at least!
Brian.
Well, I still can't get Lazarus to build from the sources obtained through subversion.…
setup, not Lazarus. FPC is trying to compile the Lazarus fcllaz package that uses the FPC's db.pp unit, but can't find it.
The "db.pp" unit is part of FPC's fcl-db package. I would double check your ~/.fpc.cfg file and make sure all the paths are correct.
Regards,
Graeme
Well, I guess things are progressing, after a fashion!
Thank you, Graeme, for sorting this one. I took the two fpc debs currently with the latest lazarus on sourceforge, installed them, and now lazarus (from subversion, and I updated this morning, before building) builds without error. So far, so good.
So then I ran up the IDE, and changed to the QT5 widgets, per John's suggestion, and rebuilt the IDE. Nope! Back to this error which Don Alfredo says is due to an outdated libQT5pas.so when fpcupdeluxe is used, so I assume it's the same problem here.
A quick search on the error finds details of building the Qt5 on a previous version of Mint
which seems to be downloading an update of some of the QT5 stuff, so I'll try this lot when I get chance.
In the meantime, my Gtk2 build running under the Debian-based version of Mint in a VirtualBox VM continues to work just fine - so whatever the cause of all this, it seems that EITHER it rests with the Ubuntu version of Mint OR it's a multi-way interaction with some of the software I have installed on the host but not on the VM.
Thanks again for the help, folks, I will report back when I get chance, but that may not be for a few more days. This is now a hobby for me, not a profession, and my wife seems to think that there are more important things for me to do with my time. :(
Brian.
I decided to try the multi-way interaction idea, and I reinstalled Mint Ubuntu, reformatting the root partition. Lazarus now works perfectly using gtk2, no 'i' and 'm' problems. :) I don't have everything installed again, I cut thinks back to the minimum that I must have, so I guess the thing now is to test Lazarus before and after I install anything else, see whether I can find the installation which breaks things, if in fact it still does.
If there was anybody else but me seeing this problem, then that's my recommendation if you can do it, reinstall your OS and you may find it all goes away. It certainly took less time than all the other things I did trying to solve the problem.
Thanks again to everyone who tried to help.
Brian.