Forum > Editor
Feature request/suggestion about file saving
440bx:
--- Quote from: lainz on August 01, 2024, 12:46:12 am ---There's AutoSave plugin in OPM.
https://github.com/lainz/LazAutoSave
--- End quote ---
What I need is not just automatic saving. What I need is automatic saving when Lazarus loses focus, that's when I want automatic saving to be triggered. I don't care to have automatic saving in any other situation.
Does that package you linked to save files when Lazarus loses focus ?
lainz:
--- Quote from: 440bx on August 01, 2024, 01:31:51 am ---
--- Quote from: lainz on August 01, 2024, 12:46:12 am ---There's AutoSave plugin in OPM.
https://github.com/lainz/LazAutoSave
--- End quote ---
What I need is not just automatic saving. What I need is automatic saving when Lazarus loses focus, that's when I want automatic saving to be triggered. I don't care to have automatic saving in any other situation.
Does that package you linked to save files when Lazarus loses focus ?
--- End quote ---
It saves always, not just when you switch tabs.
But try to adapt it to your needs.
Regards.
Martin_fr:
--- Quote from: 440bx on August 01, 2024, 01:27:13 am ---I'm going to take this on just for fun... :)
--- End quote ---
Yep, just fun and games :)
1) That assumes there are
- no optional param / param with default value
- overloads
- () are mandatory for functions
2) "if b is a record" => does not exclude the other cases, if we consider operator overloads (as then a record + some_other_type would be possible)
3) Yes a semicolon could make that correct, if the following "c" is a function (since the result does not need to be consumed, it would be a statement)
4) Yes the "extra space" wasn't serious / so is the missing comment-start
So for the given
if true then A := b c
consider
b and c are functions
b is overloaded (or has a default param)
b returns a structure
there is an overloaded + for that structure type
Ok, yes: not the average case....
However, on the more serious note, if trying to narrow it down... I uphold an unspecific error ("semicolon missing" is not unspecific) is better that the wrong specific.
Some of your suggestion on finding the error assume that the error is in the next token. But if "b" was already wrong, then any specific error found will sent the user on the wrong path. And for a user, especially a not-so-expert it does not matter what rules the compiler used to determine the error, if he mistyped the b.
E.g.
A := no b; /
- meant to be "not b"
- "no" may be a defined identifier
No error, whatsoever would help the user here. And any attempt to get a specific error will make it worse.
Well ChatGpt actually includes this
"The no operator is not valid in Pascal. Pascal uses not for logical negation." and even an example on the correct usage of "not".
440bx:
The driving force behind emitting an error messages is for the message to provide a remedy that makes the statement correct. That said, if the statement has multiple problems, such as a missing operator between two identifiers and a semicolon missing separating the last identifier from the next statement, then the compiler would be wise to emit a single error message and once that error is corrected then concern itself with any errors that may have followed that one.
Personally, I think Borland made the right choice when they decided to stop compilation upon finding an error. Error recovery is fraught with problems stemming from possible ambiguities caused by syntactic errors. For the most part, FPC seems to behave the same way.
My personal choice is: give me the fastest possible compiler that emits a _single_ precise, accurate error message.
The deficiencies, in the form of omissions, you pointed out in the possibilities I mentioned are completely valid but, the compiler can take those omissions into account and, in most cases, resolve to a precise error message.
IOW, the compiler knows (or, at the very least, should know), if a function has optional parameters, if an operator has been overloaded or whatever else may apply and take those things into consideration when determining what action makes the syntactically incorrect statement, correct.
Joanna from IRC:
On the topic of errors, what is with those runtime error messages that give an error number that you have to look up or have memorized instead of saying what the error is? Wouldn’t it be just as easy to say what it is in text ?
Also some error messages don’t really take you to where the error is and you still need to put in breakpoints and trace to where the error happens manually... I wish there could be better runtime error messages.
Navigation
[0] Message Index
[#] Next page
[*] Previous page