Hello all,

I've created a small list of features that I really like to see in a text editor<http://idkn.wordpress.com/2011/02/03/features-i-wish-to-see-in-a-text-editoride/>(and Lazarus in specific).
They are just ideas, no obligation for any of them at all, but I would really like to hear what you think on them regardless of the implementation part.

Thanks,
Ido

LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110203/3c53c713/attachment.html>

1. highlight:
About "load the actual style from an external file" That was already implemented by Martin.

4. Error and warning indicator in a side bar.
Already started.

7. Inline documentation view.
Already started.

10. The ability to see the directory structure of the project. Already started. Maybe also: filebrowser.lpk

11. Inline SCM information
Not yet started, but useful.

Mattias

from the page:

*Source preview of the entire content near the scrollbar*. *Error and warning indicator in a side bar.*

Your picture is almost black on black, even if I view it outside the page (full size) => I can not see anything

Anyway try to compile with -dWithSynOverviewGutter It gives an overview of some elements:
- implementation vs interface
- the yellow/green changed line indications
- position of bookmarks
- position of breakpoints

=> It is meant to one day indicate the locations of errors and warnings.....

*Tab grouping of source files (and also tab coloring as part of it)*.

Not the same, but:
using docked ide, you can use several source-edit windows, docking all in the same window.
Instead of docking them next to each other, dock them so they each have the full space, and a tab.
Then you have one row of tabs with the source-edit-windows; and in each of them your selected editors.

Tab drag/drop may not work that way, but you can use the context menu to sort the editors...

That's all for now (it does not look like much, but it's a lot of work)

oh, yes, it is / will be.
some ideas where already on the list....

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

not exactly: I implemented loading the colors for an existing style => but not an entire new grammar

4. Error and warning indicator in a side bar. Already started.

see other mail

Can we add it as Addon/Plugins for Lazarus?

This is what has been implemented:
http://lazarus-dev.blogspot.com/2010/06/user-defined-color-schemes.html

That is, for an existing grammar (e.g. pas or html) you can save and load the color settings to external files (and the IDE will offer them for selection)

----
As for creating a new grammar (e.g. "css" highlighting) that is not yet done => there is SynUniSyn (separate package), which I *believe* may be an I have no idea if it works, or how much work it does still need (never looked at it in detail)

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

Nice, but many of your options don't work properly or don't make sense with multiple editor windows. At least I prefer multiple editor windows, instead of the simple all-in-one approach of other development systems.

IMO we should get the LCL and IDE work first, before adding features from other tools.

OTOH it would be nice to allow everybody to add such features, based on a documentation of the current IDE implementation - and that's the crux, the implementation will change every now and then :-(

DoDi

Op 2011-02-03 13:55, Hans-Peter Diettrich het geskryf:

with multiple editor windows. At least I prefer multiple editor windows, instead of the simple all-in-one approach of other development systems.

I haven?t tried the multiple-editor-window feature yet, neither have I tried the ide-docking feature. But I guess, if the latter is working correctly, then Ido can simply dock his multiple editor windows in the layout he prefers. Just a thought.

Regards,
- Graeme -

Hi All,

I'll answer here for everything instead of several emails.

First of all thank you for your comments, it's really amazing to see how many things exists without knowing about them at all (for example I still do not understand how the new build system and macro's work, but that's a whole new email :))

Regarding the Syntax highlight coloring, now I fully understand the new feature of Martin, and I should place my style in a specific directory. Now we need to add support for external syntax highlight rules (not coloring) and we can expand it instead of having new pascal unit to be registered as a syntax highlight.

Error and warning indicator in a side bar:
I've used the compiler define that Martin suggested and it's looks great, found at the moment one bug logical bug though, it's overlap symbols of Breakpoint over bookmark if they both on the same line.

*Error and warning indicator in a side bar.
*Your picture is almost black on black, even if I view it outside the page (full size) => I can not see anything

I tried to show the structure idea more then the code itself at my screen at least you still can notice the structure itself including the line numbers ... I guess it's too dark though :(

Nice, but many of your options don't work properly or don't make sense with

multiple editor windows. At least I prefer multiple editor windows, instead of the simple all-in-one approach of other development systems.

Well for me at least it's easier to work with one view and many splits of windows rather then many windows.
Even people at mozilla tried to implement such approach by making search and "pop up" messages to be inline on the view that makes them, and many copied it to their browsers and other UI's as well, and it seems very logical thing imho.

But I'm not sure that I fully understand what will not work on multiple windows as well ?

IMO we should get the LCL and IDE work first, before adding features from

other tools.

The LCL and IDE works, not 100% (at least the LCL) but they do work, and If you read the whole post, I talked about implementing it after v1 .

The multiple window editor is not very convenient for me. I'm using 15" screen so there is not a lot of room for placing it side by side or one bellow the other without seeing very little. if you want to place them like so, you need to tell the window manager to remove the titles and borders for that, but "split" does exactly that, remove everything that is not required and make the editor itself viewable with split options to change the view dimensions.

I have not yet tried the docking feature of the IDE, but I will try it .

Again, thank you all for your comments and mostly highlights of the ideas

Ido
LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110204/7ce78837/attachment-0001.html>

As i said there is SynUniSyn, but I have no idea, how close or far from working it is.

Well it is a beta, that is why it is ifdefed.

And yes there is much missing.
If 2 or more item are close together,only one (with the highest priority) will be painted; a valid way, but not always desirable.

- Making them thinner, or one pixel line, would defer but not solve the issue. However since one day they should be click-able, they need some height
- Putting them side by side, is another idea
- mixing colors...
- or of course, as long as space exists, push them up/down, so they both are visible (even so slightly off position)

and much much more...

Well I did not get the idea from the picture at all...

splitting is on the list anyway, but all in god time...

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

Hi.

Really great ideas.

2011/2/3 ik

2011/2/4 Martin

Something like this:
http://www.sublimetext.com/blog/articles/sublime-text-2-public-alpha

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

2011/2/3 Martin

I compiled with and without this option and didn't notice a difference. When a line is changed I get a yellow mark, and it changes to green when saved -- but this happens with and without the compile option. Bookmarks and breakpoints show the same. However, I don't notice anything in the gutter for implementation vs compiled with "make clean all OPT="-dWithSynOverviewGutter""

Am I missing something?

BTW, I cannot find this option mentioned anywhere. Are there others that perhaps aren't documented, that might be useful?

The multiple window editor is not very convenient for me.? I'm using 15" screen so there is not a lot of room for placing it side by side or one bellow the other without seeing very little. if you want to place them like so, you need to tell the window manager to remove the titles and borders for that, but "split" does exactly that, remove everything that is not required and make the editor itself viewable with split options to change the view dimensions. ?I have not yet tried the docking feature of the IDE, but I will try it .

Another option:
I have recently added a second monitor to my work system. Now running two 19" LCD monitors side by side. This is the best upgrade a developer can wish for!! No more windows behind others. Run the app on one monitor while befitting on the other etc. Just awesome!

Something to consider.

Still not sure...

Is that small bit that full and entire unit/text (and always the full)? Or a selection of it by some restraints (e.g. +/1 2pages of the current page)? Or current function, Or ...?

If it is full, why does it not stretch along the full scrollbar? how does the scrollbar relate to it?
If it is full, what if there are more lines than pixel rows?

p.s:
I do overquote myself some time. But embedd a single line answer in the middle of 60 lines? That is not only an awful amount of unrequited context, It also makes the one single new line of text quite hard to find... -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110204/6af23965/attachment-0001.html>

With the option, SynEdit presents an overview column, next to the vertical scrollbar (or on the right side of the edit). This column represents the entire file, not just the current screen.

BTW, I cannot find this option mentioned anywhere. Are there others that perhaps aren't documented, that might be useful?

No it is not documented. That is, because the feature is still developed. The API for it (for people using Synedit in their own code) may still change).

The other options (for SynEdit) that I am aware of, are all either for debugging (enable various console output), or enable asserts in the code: SynDebug
SynCaretDebug
SynTrimDebug
SynFoldDebug
SynFoldSaveDebug
SynCheckPaintLock
SynClipboardExceptions
AssertSynMemIndex

None of them are guaranteed to stay as they are.

You may find other IFDEF in the SynEdit code, some of them are left overs from a time long gone. Using those old ones will likely not even compile....

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110204/0e4ffeed/attachment.html>

2011/2/4 Martin

Well, it turns out this may be a bug in the OS X implementation. It seems that it only displays if the editor is resized, which I just happened to do by accident. BUT, it must be resized for each file (resizing it once doesn't fix it for any other open files) -- and this must be done every time lazarus is run (it doesn't show upon restart, you've still got to resize the editor to display the gutter again). It does show if the file is very short and there is no vertical scroll bar, but not for any file that's long enough to need the v-scrollbar.

Very cool, thanks!

Op 2011-02-04 21:20, Graeme Geldenhuys het geskryf:

one monitor while befitting on the other etc. Just awesome!

Stupid iPad word-completion! It should have read...

"...one monitor while debugging on the other..."

Regards,
- Graeme -