Feature request/suggestion about file saving

[440bx]

Yes, there are a number of subtleties involved in scrolling (horizontal and vertical)

The Lazarus editor does a reasonably good job in that area, better than most editors.

[Martin_fr]

One thing that highly disrupts scrolling (especially vertical) are highlight changes.

You may consider disabling them, if you have them on, don't need them, and maybe scrolling improves (little bit)

E.g. "Markup and Matches": "Keyword brackets". Highlight Begin/End pairs etc.
If you scroll up/down, and go through a begin/end (or other word that has a match), then the other word is highlighted, causing invalidation in the middle of the editor.
So instead of just painting the one (or few) scrolled in lines, the invalidation forces a repaint of all lines from the border to the keyword.
The probably should have a timer (at least if the key is kept down, or if scrolling)....

Brackets can do that too, if they are multiline.... Though that is rare (you have to also hit the bracket while scrolling).

Oh, and disable the scroll hint: That small bubble with the linenumber when using the scrollbar.... It overlaps the editor, and causes invalidations that lead to extra painting.
 
Worse, the latest addition (though IIRC by default off). A 2nd color for the fold gutter, to indicate the fold containing the caret. As you keep moving up/down to scroll, the caret changes, and that line needs to be repainted. Again causing a lot of extra painting.
I don't know if that gets "used" by people while scrolling, or if a delay (remove, and restore after scrolling ends) would be acceptable.
But then its a very special feature, and if it is not enabled, it does not interfere.

[MarkMLl]

Multi-Edit was one of the earliest full-screen editors in the DOS era, and one of the earliest to be designed around drop-down menus etc. rather than having them be a visually-convenient wrapper around underlying control key combinations. It's competitors were Brief, Epsilon, Point (from Logitech), Turbo (Pascal etc.), and of course MS Quick-Basic.

The Windows variant somehow wasn't quite as good, and was up against MS Visual (Basic etc.) and Delphi which in combination elbowed practically everything else out of their way.

I mention the two variants (which co-existed fairly comfortably in the early 1990s) intentionally, since at this point I think we have to wonder what would happen if somebody (440bx, I'm looking pointedly at you) did a side-by-side comparison of the Lazarus editor on Windows and Linux, and then possibly on Linux+X11 vs Linux+Wayland: performance differences might be platform specific and if they could be highlighted they might turn out to be fixable.

MarkMLl

[440bx]

@Martin,

Thank you for all those tips.  The only setting I have set that may impact scrolling speed is highlighting open and close parentheses and brackets.  Since it is somewhat rare for the cursor to be on one of those, it probably doesn't make a perceptible difference.

Everything else you mentioned is turned off.

@MarkMLI,

Since I do not use Linux, I cannot compare the Lazarus editor in Windows and Linux.


general comment(s):

One of the things that is often a topic in the forum is how to make FPC/Pascal more popular.  That always reminds me of how I got initially hooked on Multi-Edit.  At the time (MS-DOS) Multi-Edit was the _only_ editor that when you pressed the shift or ctrl (which used to be located above the shift key, not below as it is now) or alt key, small labels (8 of them) at the bottom of the screen would appear showing what action pressing the given function key in combination with that key would do.

For someone learning how to use the editor, that "training wheel" was incredibly useful.  It gave you "instant help" on what ctrl/alt/shift F1..F8 did.  That combined with the fact that ME was programmable in a language that was quite similar to Pascal was another big plus, not to mention that the editor itself is coded in that language.  The executable is basically/mostly an interpreter for that language.  It was/is like having the editor's source code and customizing it on the fly. 

When I see the compiler emit an "illegal expression" message which is about as unhelpful a message can get or, "semicolon expected" when a semicolon is the last thing you need in that location, it makes me think about the frustration someone trying to learn Pascal using FPC (or Delphi) may experience.   This is true of most compilers, their error messages _very often_ leave a great deal to be desired.  I believe that if someone designed a capable language (FPC qualifies) that emitted precise and accurate error messages, that would go a long ways into making that language popular.

I've been programming for 48 years now and there are still occasions when I read an FPC error message and look at the code and do not see what it is the compiler is complaining about because the message is as informative about the situation as finding a newspaper ad in a Mongolian desert.  Then I think, a beginner faces a tough learning curve because the message(s) is often of little to no help in solving the problem.  All that said, at least it's an indication there is a problem (early C compilers would simply assume there is an integer there and keep compiling... and they have the gall of calling a binary disgrace like that a "compiler"... sure... that's a compiler like the Pope is a Victoria Secret lingerie model.)

Time for me to get off my soap box... <chuckle>

[MarkMLl]

Since I do not use Linux, I cannot compare the Lazarus editor in Windows and Linux.

Since you're the one commenting on performance issues, it's time for you to do so for the sake of comparison.

MarkMLl

[440bx]

Since you're the one commenting on performance issues, it's time for you to do so for the sake of comparison.

MarkMLl

I could and can do so for Windows editors but not for Linux editors. (though I have used vi, emacs and other editors that are available in both unix and Windows.)

That said, it isn't my intention nor desire to prove something.  IOW, I have no incentive whatsoever to make the comparison and, much less to spend any time performing a task that is of no interest to me.  In addition to that ME is now a defunct product, even if I demonstrated it is better than sliced bread, it is no longer being sold, therefore it has become irrelevant to anyone who isn't using already using it.

The reason I requested the feature in this thread is because if I forget to save the file edited in Lazarus then any edits made in ME will not be seen by Lazarus. Lazarus doesn't attempt to reload a file that it hasn't saved, i.e, has edits pending, that has caused me to occasionally lose some edits.  I seldom forget to save the files (usually simply by doing a recompile which causes all files to be saved) but, it has happened and it is something that I have to always keep in the back of my mind.

Now, with the package from Domingo (thank you again Domingo), the only thing I have to keep in mind is to switch to ME using the taskbar, small thing and easily remedied (without any loss of edits) if I forget.

 

[JuhaManninen]

... such as function definition hints and code navigation, I completely agree that those are great but, the problem I face is they stop working as the code gets more complex.  Codetools doesn't seem to handle the way I structure code.  In the project I'm working on currently I cannot get function definition hints, jumping to function definitions/implementation does not work, code completion does not work,

That sounds bad, especially because when a problem cannot be reproduced with a small code snippet, it will be very difficult to fix.
Known issues with Codetools happen with lots of conditional compilation, complex generics syntax and maybe other new Pascal syntax like type helpers.
Code for the Lazarus IDE itself can be navigated quite nicely.

hints (if and when they appear, which is unusual) are sometimes yellow and sometimes grey, they grey ones are a pain because it's not possible to scroll them causing them to rarely show the information that is of interest.

Yes, that is a strange bug. You have reported it here :
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41008
Somebody should debug it.

[440bx]

That sounds bad, especially because when a problem cannot be reproduced with a small code snippet, it will be very difficult to fix.

I agree.  I'll try to come up with a small code snippet at some point. 

[MarkMLl]

I'm reminded of the situation 15 or so years ago, where Lazarus- and a number of other apps including Mozilla- was virtually unusable remotely over X11 but worked fine over VNC. Now this sort of thing is clearly a platform problem: in that particular case I believe it turned out to be because GTK was doing a wildly excessive amount of input device polling.

The problems currently being discussed could similarly turn out to be platform-specific, but the only person who stands a chance of making sensible decisions about them is somebody who can distinguish between "nothing wrong" and "I can still see it but it's not as bad".

MarkMLl

[PascalDragon]

When I see the compiler emit an "illegal expression" message which is about as unhelpful a message can get or, "semicolon expected" when a semicolon is the last thing you need in that location, it makes me think about the frustration someone trying to learn Pascal using FPC (or Delphi) may experience.   This is true of most compilers, their error messages _very often_ leave a great deal to be desired.  I believe that if someone designed a capable language (FPC qualifies) that emitted precise and accurate error messages, that would go a long ways into making that language popular.

The problem is that in the majority of these situations the compiler really has no better idea what to complain about instead. Especially “semicolon expected” is usually a last resort message when it can't safely do an error recovery and continue on.

[MarkMLl]

The problem is that in the majority of these situations the compiler really has no better idea what to complain about instead. Especially “semicolon expected” is usually a last resort message when it can't safely do an error recovery and continue on.

Having cut my teeth on punched-card FORTRAN where just about every error message was MISMATCHED PARENTHESES, I assure you that I sympathise :-)

MarkMLl

[440bx]

Having cut my teeth on punched-card FORTRAN where just about every error message was MISMATCHED PARENTHESES, I assure you that I sympathise :-)

MarkMLl

That's one of the problems created by the lack of a formal grammar definition that is strictly adhered to.  When there is a formal grammar, emitting good, precise, accurate error messages is quite often easy.  Of course, there are errors that can create ambiguities that prevent emitting a precise and accurate message but, "semicolon expected" or "illegal expression" would _never_ be necessary, not even in ambiguous situations.

The absence of a formal grammar is the reason the compiler doesn't know what the appropriate message to emit is.

[Martin_fr]

The absence of a formal grammar is the reason the compiler doesn't know what the appropriate message to emit is.

Well even then...
The expected grammar for the following should be clear (not sure if it is formalized, but that could be done, and the ambiguity would remain):

if true then A := b c

What is the error?

Is there a semicolon missing, and c is a function that can be called (next statement)?
Or is there an operator missing? b + c
Or a dot b.c ?
Or a parenthesis? b is a function and should take c as argument? b(c ...)
Or a begin of comment? "// c" and the expression continues on the next line?
Or a space that shouldn't be bc is an identifier?
Or an "else"?

Yes there are simple cases, where more distinct errors could be given.

But the more specific an error gets, the more misleading will it be, if it was incorrectly given.

And in that light, I actually agree "semicolon expected" is bad. It is to specific.

As it can (in most cases) not be known what is expected (or it is to long a list), it shouldn't state something to be expected. It should just say, that something unexpected was found.

In the above example: "Unexpected identifier c was found". Or "Identifier 'b' can not directly be followed by another identifier."

Though, I don't know how much more that would help.

And other than this, many other errors are helpful, at least to me. Like type mismatches, missing/extra parameters....

[lainz]

There's AutoSave plugin in OPM.
https://github.com/lainz/LazAutoSave

[440bx]

The expected grammar for the following should be clear (not sure if it is formalized, but that could be done, and the ambiguity would remain):

if true then A := b c

What is the error?

Is there a semicolon missing, and c is a function that can be called (next statement)?
Or is there an operator missing? b + c
Or a dot b.c ?
Or a parenthesis? b is a function and should take c as argument? b(c ...)
Or a begin of comment? "// c" and the expression continues on the next line?
Or a space that shouldn't be bc is an identifier?
Or an "else"?

I'm going to take this on just for fun...

Before anything, I have and still acknowledge that some errors can lead to syntactic ambiguities that will make issuing an accurate error message very difficult and, in a few cases, even impossible.

In the example you provided and given a formal grammar, the compiler can unambiguously resolve most of your questions.  Here is how:

1.  The compiler should know whether or not "b" is a function, if "b" is a function that takes parameters (the compiler should know that too) then a parenthesis is missing.

2. if "b" is a record (something the compiler should know) then, if there is a field in the record named "c" then the compiler emit an error stating that a dot is missing.  if "b" is not a record and not a function and "b" and "c" are compatible types then the compiler can presume an operator is missing an emit a message to that effect.

3. The compiler requesting a semicolon after "b" is _always_ incorrect because adding a semicolon after "b" does _not_ make the statement correct (unlike requesting a dot or parenthesis or operator)

4. Complaining about an additional space would be incorrect because if that was the error then "b c" should be followed by one of: a semicolon, an "end" or "else" and it is not, therefore that is ruled out.

The compiler should know, at all times, no exception _ever_,  where it is standing in the grammar.  It also knows the type of every identifier (an unknown identifier has an unknown type, therefore it knows it's an unknown identifier, therefore an unknown type.)

In the great majority of cases, in the presence of a formal grammar, the compiler has all the information it needs to emit a crystal clear, unambiguous error message.

That said, yes, there are times when a syntactic error can create ambiguities that are not decidable.  In that case the compiler should emit a message stating a couple of possible alternatives (yes, it should be able to do that too.)