Hi,

Has anybody implemented a synedit (or other edit component) based general text editor (something like Syn on SourceForge - but it doesn't need to have that much functionality). I would like to get a replacement "general" text editor for gEdit and Kate. Preferably something light weight and fast, that can do search and replace and font customisation. I could put one together myself, but if somebody already done this, that would save me some time.

And no, please don't recommend VIM - I hate the vi interface. Also a GUI text editor would be preferred, so something like mcedit (included with Midnight Commander) is also out.

Many thanks in advance for any recommendations.

Graeme Geldenhuys wrote

Hi, Has anybody implemented a synedit (or other edit component) basedgeneral text editor (something like Syn on SourceForge - but itdoesn't need to have that much functionality). I would like to get areplacement "general" text editor for gEdit and Kate. Preferablysomething light weight and fast, that can do search and replace andfont customisation. I could put one together myself, but if somebodyalready done this, that would save me some time. And no, please don't recommend VIM - I hate the vi interface. Also aGUI text editor would be preferred, so something like mcedit (includedwith Midnight Commander) is also out. Many thanks in advance for any recommendations.

I've done it, but it's not pretty and has more bugs that a bag of supermarket economy rice. You might find that the variant of Emacs that has an X wrapper will do what you want, otherwise there's probably a programmer's editor with whatever desktop you use e.g. Kate for KDE.

What's wrong with using a TMemo?

Text search and replacement can be added to every control containing text. Also the keyboard handling is configurable in almost every control.

More critical are text attributes, which must be supported by the control itself, but you didn't mention such a requirement.

Syntax highlighting were another topic, which should be supported by the control - but it also can be implemented by OwnerDraw.

DoDi

2012/2/13 Graeme Geldenhuys :

I would like to get a replacement "general" text editor for gEdit and Kate. Preferably something light weight and fast, that can do search and replace and font customisation.

I have always used SciTE. Its lightweight and highly customizable and it runs on Windows and Linux. The configuration is only done via its config files, there are no huge and convoluted settings dialogs like in Kate but there are equally powerful possibilities hiding beneath the surface, all it requires is some time to understand the config files.

Many thanks in advance for any recommendations.

I like Geany as a programmers text editor. It provides synthax highlighting for many languages and you can set custom build commands. Very useful for my C needs, but of course it can be used for many other languages and tasks.

R.

http://sourceforge.net/projects/letterpress/ ?

But it might be windows only....

Graeme Geldenhuys wrote

Hi, Has anybody implemented a synedit (or other edit component) based general text editor (something like Syn on SourceForge - but it

Yes I have, sort of.
It's main purpose is html text editing, but I use it as a notepad replacement. The UI is in Dutch however.
It uses a Tadded Document Interface like Lazarus IDE and has highlight support for html, xml, js, pascal, perl, php, pyhton, unix shell script, batch, ini, po-language files.
Sources are LGPL 2.0.

See: http://home.tiscali.nl/~knmg0017/software.htm#eplus "Download de broncode " has link to sources.
You also need all units under "Afhankelijkheden ".

Bart

Bart wrote

See: http://home.tiscali.nl/~knmg0017/software.htm#eplus "Download de broncode " has link to sources. You also need all units under "Afhankelijkheden ".

It looks pretty good, but as always it has some non-standard dependencies which are always a problem. I managed to remove them all and I would like to place my modified code in the Lazarus-CCR. Maybe a more descriptive name would be good too, something like fpedit. Also less attachment to the flying sheep. Then it can be added to:

http://wiki.lazarus.freepascal.org/Free_Pascal_Application_Suite

What do you think?

Bart wrote

The UI is in Dutch however.

That's no problem.

See: http://home.tiscali.nl/~knmg0017/software.htm#eplus "Download de broncode " has link to sources. You also need all units under "Afhankelijkheden ".

Thanks, but after trying for 30 minutes to resolve the many dependency issues, and many compiler errors (missing units) I gave up. And yes, I did download the many extra zip files, but there was still missing units. I tried Lazarus 0.9.30.x (stable) and Lazarus Trunk using FPC 2.6.0 under 64-bit Linux.

I guess I'll just have to knock together a basic fpGUI editor from scratch in my lunchtime. It should be 40 minutes well spent. Thanks anyway for the suggestion.

Felipe Monteiro de Carvalho wrote

Maybe a more descriptive name would be good too, something like fpedit.

Actually my favorite name now would be: lazedit

Felipe Monteiro de Carvalho wrote

Actually my favorite name now would be: lazedit

The address book application too could use the same process:

1->Remove non-standard dependencies
2->Rename to lazContacts
3->Add to FP Application Suite

Felipe Monteiro de Carvalho wrote

The address book application too could use the same process: 3->Add to FP Application Suite

I've got a few apps that could be contenders in the FP Application Suite list - or can only LCL based apps play there?

Graeme Geldenhuys wrote

I've got a few apps that could be contenders in the FP Application Suite list - or can only LCL based apps play there?

To clarify the list I have....all obviously implemented in FPC + fpGUI.

* A file manager (yet another Total Commander clone)
* Globe (a toy style app where you can spin and zoom the earth)
* Bug Tracker (uses tiOPF and any database backend tiOPF supports)
* Address Book (uses tiOPF and any database backend tiOPF supports)
* Calculator (simple, advance and programmer interfaces). RPN should be supported soon.
* Installer program - for use with FPC based applications. This is a reimplementation of the
Loki Installer which was originally written in C for games like SimCity and products like Borland Kylix.
* Image Viewer with thumbnail extraction support
* Since a few minutes ago, a Notepad style editor, with tab interface and syntax highlighting for pascal.
* ...probably a few more tools and utilities lying around somewhere on my hard drive.

Graeme Geldenhuys wrote

I've got a few apps that could be contenders in the FP Application Suite list - or can only LCL based apps play there?

Any Pascal app can join. Cross-platform and free software apps are preferred.

Hi Graeme,

I'll go straight to the point without any shame: may I have your calculator and, eventually, the installer program?
Unfortunately I've little to share, because I'm an hw engineer and my sw has very little or no "public" utility.
The only one vaguely useful (http://sourceforge.net/projects/ardp/) has been downloaded 3 or 4 times in total.

Thanks anyway, especially for the efforts in fpGUI !!!

R#

Il giorno 14 febbraio 2012 12:48, Graeme Geldenhuys <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120214/88893377/attachment.html>

Be my guest ;-)

Bart

Graeme Geldenhuys wrote

* Since a few minutes ago, a Notepad style editor, with tab interface and syntax highlighting for pascal.

My god, you work fast.
I spent several months on my app (before releasing).

Bart

Bart wrote

My god, you work fast. I spent several months on my app (before releasing).

The right toolkit makes things easier. ;-)

Jokes aside... I actually copied and pasted a lot of support code I wrote for the Maximus IDE (an experimental fpGUI IDE), and reused the editor component I created for Maximus IDE too. A bit of cheating I know, but it got the job done in a lunch break. :-)

On a side note:
I have to agree with you though, writing a functional editor with reasonable features is everything but a quick job. There is such a lot in an editor we take for granted.

Bart wrote

Be my guest ;-)

Great! It is now in the lazarusccr in applications/lazedit

Felipe

On Tue, Feb 14, 2012 at 11:32 AM, Graeme Geldenhuys <

Oh, 40 minutes, i bet you, it is get more than pure 40 hours :D (that what i said when started my editor).

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120215/bd3a5959/attachment.html>

Zaher Dirkey wrote

Oh, 40 minutes, i bet you, it is get more than pure 40 hours :D (that what i said when started my editor).

Like I said in my reply to Bart, I decided in the end to use an editor component I already created for another application. So I reused lots of existing code, just restructured it with a simple "notepad style app but with tab interface". Works a treat!

If I had to write it from scratch, there is no ways it would have been done in 40 minutes. :)

Bart wrote

Be my guest ;-)

Done: http://wiki.lazarus.freepascal.org/LazEdit

I wrote a system to manage translations, added an english translation while keeping the dutch one, made the toolbars configurable, removed all dependencies and I concentrated all HTML tools in one menu to make it more a general text editor.

A win32 release is available there too and the installer will install a "Open with LazEdit" explorer context menu =) Now it can already replace Notepad++ for me and should be a strong contenter in Linux.

Nice work to both Bart and Felipe.

@Felipe
I just grabbed the latest code from SourceForge (as directed in the wiki page). I couldn't compile the project (even with the latest Lazarus Trunk), until I removed all references to a non-existing "EPlus_Commons" unit in a few uses clauses. I attached a patch to this email, which fixes this problem.

Felipe Monteiro de Carvalho wrote

Done: http://wiki.lazarus.freepascal.org/LazEdit

Not sure where to report bugs, so I am emailing them here.

The "Info" menu item in the main menu must be clicked twice (under Linux with GTK2 widgetset) before the dialog appears. The toolbar icon on the other hand only requires a single click. Not sure if the "having to click twice" is a LCL-GTK2 bug or a LazEdit bug.

Felipe Monteiro de Carvalho wrote

Done: http://wiki.lazarus.freepascal.org/LazEdit

More bugs...

1) when you activate the HTML toolbar and click on the "insert image" button, that dialog is still in Dutch, even though the rest of the UI of LazEdit is in English.

2) Same as (1), but for the "insert hyperlink" dialog.

Felipe Monteiro de Carvalho wrote

Done: http://wiki.lazarus.freepascal.org/LazEdit

And more...

1) "View > Lettertype" must probably be translated to "View > Font selection" or something like that.

2) The current "Lettertype" menu item does nothing. I doesn't change the editor font.

3) "View > Highlighter > PO xxx" text is still in Dutch, even though I have a English UI for the rest of LazEdit.

Still using LCL-GTK2 under Linux.

Graeme Geldenhuys wrote

The "Info" menu item in the main menu must be clicked twice (under Linux with GTK2 widgetset) before the dialog appears.

Probably a gtk2 bug or "feature", works correctly here in Windows.

2012/2/16 Graeme Geldenhuys :

Thanks, applied. I still had the old .o files, so I didn't catch this error.

As for the rest: Yes, there are still some missing stuff to translate.

Felipe Monteiro de Carvalho wrote

Done: http://wiki.lazarus.freepascal.org/LazEdit

Sorry, and some more....

1) The menu "HTML Tools > Layout" has 5 items that are still in Dutch

2) Searching in the backwards direction doesn't work. Searching forward does though.
See attached image.

On 16 February 2012 14:54, Felipe Monteiro de Carvalho

Done: http://wiki.lazarus.freepascal.org/LazEdit

1) The "File > Open" and the "File > Open Template" dialogs have Dutch text in the file filter comboboxes.

2) The File menu has 6 empty menu items. I presume they are place holders for "most recently used files". Normally you wouldn't display them, if they have never been used. Also clicking on them gives an "Index out of bounds" error and crashed out the application. See attached screenshot of these menu items.

Felipe Monteiro de Carvalho wrote

On Tue, Feb 14, 2012 at 6:47 PM, Bart wrote: > Be my guest ;-) Done: http://wiki.lazarus.freepascal.org/LazEdit

Cool.

Bart

Graeme Geldenhuys wrote

The "Info" menu item in the main menu must be clicked twice (under Linux with GTK2 widgetset) before the dialog appears.

Probably GTK issue?
It works (in the original program) on Windows.

1) "View > Lettertype" must probably be translated to "View > Font selection" or something like that.

FWIW.
The entries in View (after translating to English) should read: Font...
Fontsize
Highlighter

2) The current "Lettertype" menu item does nothing. I doesn't change the editor font.

Strange, it does in my original program...

3) "View > Highlighter > PO xxx" text is still in Dutch, even though I have a English UI for the rest of LazEdit.

Bart

Graeme Geldenhuys wrote

1) The "File > Open" and the "File > Open Template" dialogs have Dutch text in the file filter comboboxes.

Post a list of remaining Dutch strings and I'll translate them for you.

2) The File menu has 6 empty menu items. I presume they are place holders for "most recently used files".

Yes, they are.

Normally you wouldn't display them, if they have never been used.

The OnMruListChange event handler should take care of that (and does in my app). These menu-items are made (in)visible at runtime, depending on the Count of the MRU-list.

In procedure SetUpAndConfigureEPlus (the original name), which is called in FormCreate, there is/should be a call to OnMruListChange to ensure it is properly initilized.

I can see that my MruList has been replaced by a TStringList, and that will cause other errors in the program too.

Why not simply use my MruList unit
(http://home.tiscali.nl/~knmg0017/software/fpc_laz/mrulists.zip) as well?
There is a reason for it's existence.
For instance you cannot add the same file twice, but if you try the second time, it will be moved to be the first entry. If you want you can strip all the unneeded code from that unit.

Bart

Bart wrote

Why not simply use my MruList unit (http://home.tiscali.nl/~knmg0017/software/fpc_laz/mrulists.zip) as well?

If it is portable it should be fine, just add to the project svn, dont make people download it separately. I killed all dependencies because a lot of people use non-standard stuff which don't work for example in Mac and bring all sords of problems to build and modify the program. For me the best would be giving you commit rights to the ccr if you don't have already and you commit directly what you see fit.

Felipe

It should be, this is the uses clause:

uses
  SysUtils, Classes, Controls, Registry, IniFiles, FileUtil;

just add to the project svn,

How?

I killed all dependencies because a lot of people use non-standard stuff which don't work for example in Mac and bring all sords of problems to build and modify the program.

I tend to use only standard LCL stuff...

For me the best would be giving you commit rights to the ccr if you don't have already and you commit directly what you see fit.

I'm unfamiliar with committing via svn (or any other tool like that). Is there a wiki-entry about how to do that?
Do I need more then my svn client?

Bart

It won't be. Registry is windows only. Why not implement something yourself based on an XML file? Should be trivial. Here's some inspiration: http://www.angusj.com/delphi/mruunit.html

Just search the wiki;

http://wiki.lazarus.freepascal.org/Using_the_Lazarus-ccr_SVN_repository http://wiki.lazarus.freepascal.org/Lazarus_git-svn http://wiki.lazarus.freepascal.org/Creating_A_Patch

If you're on windows, chances are you're using tortoisesvn. Just read the documentation of that app. There are plenty of quick guides online. And of course, if you have specific questions either ask on IRC or on the ML.

Regards, Darius

Darius Blaszyk wrote

Why not implement something yourself based on an XML file? Should be trivial. Here's some inspiration: http://www.angusj.com/delphi/mruunit.html

Or simply use a INI file - which seems to be used already in that app.

PS:
Doesn't LCL come with a MRU component? I thought I saw it once on my component palette. Just looked again, and can't find it now though.

>> just add to the project svn, > > How?

Or read the SVN documentation. It is called the SVN Red Book, and it is well written, with lots of examples.

http://svnbook.red-bean.com/

Another more versatile option is to use git-svn. That means you work with a SVN repository but managed by Git. Git has lots of benefits over SVN (local commits, local branch, local history, better merging support etc), and with git-svn you can use git, but collaborate with other users in a SVN repository. Well worth a look.

http://wiki.lazarus.freepascal.org/Lazarus_git-svn

You are wrong. The Registry unit of FPC is implemented in a Cross Plattform way. On non-Windows plattforms it uses a XML file to store the values. As long as you don't need security related stuff (access control, etc) or need to access Registry keys of the OS or other applications this should be sufficient.

Regards,
Sven

Still, I would say that using the Registry unit like that is a *very bad* practice. Where will it keep the xml files?

It is also very bad practice that the application already has .ini configuration file and suddenly the recently opened files manager would use a different file in a different place to store that info...

I fully agree with Felipe on both counts. The Registry unit is a "hack" under non-Windows systems.

Am 18.02.2012 07:37 schrieb "Felipe Monteiro de Carvalho" <

: On Fri, Feb 17, 2012 at 9:49 PM, Sven Barth

> You are wrong. The Registry unit of FPC is implemented in a Cross

Plattform

> way. On non-Windows plattforms it uses a XML file to store the values.

As

> long as you don't need security related stuff (access control, etc) or

need

In the end the XML registry is conceptually similar to XMLConfig (or however it's called ^^). But everyone must decide for oneself whether that unit is suitable or not. Just shouting "It's a hack" is not helpful.

Regarding the location: the Registry files are placed in the directory returned by GetAppConfigDir. A global variable controls whether this path should be a global one or not (yes, THIS is a detail I personally don't consider as a beautiful solution, but I don't have a better solution right now)

It is also very bad practice that the application already has .ini configuration file and suddenly the recently opened files manager would use a different file in a different place to store that info...

Here I definitely agree with you as I've already written to Graeme.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120218/4f5ed6df/attachment.html>

I as well agree that it's not good if an application suddenly uses different storage formats (without reason). But regarding the usage of the XML registry I don't have any real opinion as I never used it outside of Windows yet.

I simply wanted to correct the statement that the Registry unit is not cross plattform. Whether it's suitable or not on non-Windows platforms needs to be decided by everyone him- or herself in the end.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120218/885736de/attachment.html>

No, the registry unit is not Windows only.
Anyway the editor does not use the functionality to use the registry. I can stripp all this (and more unused things) from the unit.

The whole program uses a ini file so it makes no sense to rewrite the MeuLists unit to use xml.

Bart

I have read it, but it confuses me.
If I understand correclty when you want to commit, you must always be working on the latest revision of that particular file. For a small project like this, I can see that happening. But most of the time when I'm solving Lazarus bugs, when I'm done Lazarus is many revisions ahead.

I prefer submitting patches to the bugtracker and let someone who actually knows what he is doing (with regards to svn/committing) do the actual commit.

Another more versatile option is to use git-svn. That means you work with a SVN repository but managed by Git.

Need a new computer for that.
But basically see my previous remark.

Bart

This is rather simple: you try to commit your changes, SVN will tell you that your file is out of date. Then you do a "svn up" and either the changes can be merged successfully or you need to resolve the conflicts manually. After you've done this you should be able to commit.

Regards,
Sven

That's why you should do svn update before creating the patch.

I prefer submitting patches to the bugtracker and let someone who actually knows what he is doing (with regards to svn/committing) do the actual commit.

The one has to apply your patch to the head revision.

Mattias

Mattias Gaertner wrote

On Sun, 19 Feb 2012 12:53:24 +0100 That's why you should do svn update before creating the patch.

OK, consider me stupid.
I update before trying to fix.
Since I do that on my spare time, this may take several weeks, fixing things step by step.
Then my copy of the files in question is out of date.

Now I have to update again and somehow resolve the conflicts. Reading the "manual" still leaves me confused on that.

Preferably I would like to end up with a file in which alterations made (not by me) are somehow marked in that file, so I can easily detect them and see if they interfere with my patch.

The one has to apply your patch to the head revision.

Exactly, I leave the things I do not understand to someone who does.

Is there some experimentation room available to practice the do's and don'nt's of commiting via svn (or git, or yet another tool)?

Bart

Bart wrote

But most of the time when I'm solving Lazarus bugs, when I'm done Lazarus is many revisions ahead.

That doesn't matter. The repository will warn you about that, and the chances of somebody else making changes on the exact same lines of code in a project is very small.

I prefer submitting patches to the bugtracker and let someone who

svn, git, hg etc are all tools a developer should know well. I can't imagine any software project without a repository of some sorts. I only use git, and I don't even write a test app without initialising a git repository. And while developing even a test app, I commit often. This gives me unlimited undo functionality. Oh, and in case you didn't know, git doesn't require a public repository or a repository server.

> Another more versatile option is to use git-svn. That means you work > with a SVN repository but managed by Git. Need a new computer for that.

I got no idea why you think that?
I can say that on average projects a full history git repository takes up much less space than a single revision checkout in SVN. So from a hard drive space point of view, git uses less space. Just so you know, when I develop from home, it is on a 8 year old Dell laptop. It is definitely not the fastest computer on the block (compared to today's standards), but it still works perfectly for Free Pascal based development work.

Bart wrote

Preferably I would like to end up with a file in which alterations made (not by me) are somehow marked in that file, so I can easily detect them and see if they interfere with my patch.

Git works perfectly in that case. Making your changes in a local branch. When you do an update, the master branch (svn calls this Trunk) is updated, not your local branch. You can then easily compare changes manually, or simply tell git to rebase your local branch against master - meaning it will bring you local branch up to date WHEN IT SUITES YOU. Git resolves merges very well, and it will report on conflicts if it couldn't resolve them automatically. If you are not ready to fix them immediately, stash them for later, or roll back the rebase action.

This might all sound complicated, but it fact it isn't. It's just three simple commands: git pull, git rebase and git reset.

Anyway, it's obviously up to you to decide what you want to do, or how you interact with a public project. But I would highly recommend you get familiar with code repositories - they are vital in software development projects.

svn tries to merge changes. It needs only help if two persons have worked on the same lines.

Now I have to update again and somehow resolve the conflicts.

Yes, svn update asks on conflicts what to do.

Reading the "manual" still leaves me confused on that.

Maybe you can help to improve the svn plugin for the IDE.

Preferably I would like to end up with a file in which alterations made (not by me) are somehow marked in that file, so I can easily detect them and see if they interfere with my patch.

Well, you could use two repositories. Work in one, create a patch from that. Update the other. Apply the patch. Conflicts are saved to rej files.

What about the many svn tutorials?

Mattias

Mattias Gaertner wrote

What about the many svn tutorials?

I'll just have to learn then.
Thanks for all the feedback.

If all goes well I'll commit my changes for the LazEdit project.

Bart

2012/2/19, Bart :

Bart, at some point you should tell if you want to do the same thing for PoChecker package.

About a revision control system in general, it is a very essential tool in any open source project, as Graeme mentioned. Conflicts do not happen often, you should not be worried of them. Typically people work in different areas of a project. Even if they change other parts, it is unlikely that 2 people edit the same lines at the same time.
When a conflict happens after all, then you are the right person to solve it because you know your own code.

Juha