Recent

Author Topic: Guess Misplaced IFDEF/ENDIF  (Read 1435 times)

howardpc

  • Hero Member
  • *****
  • Posts: 3446
Guess Misplaced IFDEF/ENDIF
« on: December 18, 2019, 07:52:08 pm »
There is an IDE menu item    Source->Guess Misplaced IFDEF/ENDIF
Does this work for anyone? If so, what does it do?
I have tried selecting various combinations of {$IFDEF xxx} conditionals and running Guess Misplaced IFDEF/ENDIF.
As far as I can see it does nothing. The cursor does not move, nothing appears in the Messages window, and no dialog is shown, either for correct or for incorrect $IFDEFs.
Am I just thick, or is this an unimplemented feature?

winni

  • Hero Member
  • *****
  • Posts: 1447
Re: Guess Misplaced IFDEF/ENDIF
« Reply #1 on: December 18, 2019, 08:05:23 pm »
Hi!

Just tested - Guess Misplaced IFDEF/ENDIF does nothing. Not on selected text, not on correct or incorrect DEFS.

In opposite to Guess Unclosed Block. It happy jumps from one correct record definition to the next.  Is this British humor or a bug?

Winni

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3775
  • I like bugs.
Re: Guess Misplaced IFDEF/ENDIF
« Reply #2 on: December 18, 2019, 10:48:49 pm »
It is implemented and probably did something useful back then but now it is broken.
There is:
 procedure TMainIDE.DoJumpToGuessedMisplacedIFDEF
which calls
 CodeToolBoss.GuessMisplacedIfdefEndif
which is a wrapper for
 function TStandardCodeTool.GuessMisplacedIfdefEndif
which calls
 function TLinkScanner.GuessMisplacedIfdefEndif
which has many subfunctions and lots of code. It does the real job, whatever it is.
Somebody should study it and fix if possible.

howardpc

  • Hero Member
  • *****
  • Posts: 3446
Re: Guess Misplaced IFDEF/ENDIF
« Reply #3 on: December 19, 2019, 12:12:51 am »
Meantime perhaps the useless menu could be disabled (or removed).
The IDE interface already risks being overloaded. Several main menus have over 20 items. If you install a few IDE extension packages the menus can become too busy to readily find things. The KISS principle has not been applied very vigorously.
I have sometimes thought about an IDE extension that would allow you to customise the menus to show by default only the functions you regularly use, with a normally hidden section for the more abstruse stuff.
For how many months (years?), I wonder, has this particular functionality been broken, and no one noticed, because no one actually uses it or really needs it. Or perhaps they would use it if they knew it existed and worked well...
« Last Edit: December 19, 2019, 12:16:37 am by howardpc »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6368
    • wiki
Re: Guess Misplaced IFDEF/ENDIF
« Reply #4 on: December 19, 2019, 12:23:17 am »
I have sometimes thought about an IDE extension that would allow you to customise the menus to show by default only the functions you regularly use, with a normally hidden section for the more abstruse stuff.

package EducationLaz ? IIRC

winni

  • Hero Member
  • *****
  • Posts: 1447
Re: Guess Misplaced IFDEF/ENDIF
« Reply #5 on: December 19, 2019, 12:32:46 am »
Hi!

Another solution might be the heavy use of submenus like it is done only sometimes now like "Search --> Jump to". This woiuld give a clearer and quicker overview of the menus.

Winni

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3775
  • I like bugs.
Re: Guess Misplaced IFDEF/ENDIF
« Reply #6 on: December 21, 2019, 09:22:25 am »
Meantime perhaps the useless menu could be disabled (or removed).
I disabled the "Guess Misplaced IFDEF/ENDIF" feature in r62427. It can still be enabled by defining GuessMisplacedIfdef.
How about the "Guess Unclosed Block" feature? Does it work? I don't know how to use it really.

howardpc

  • Hero Member
  • *****
  • Posts: 3446
Re: Guess Misplaced IFDEF/ENDIF
« Reply #7 on: December 21, 2019, 10:50:31 am »
Thank you.
I think Guess Unclosed block works OK, though it is not that outstanding, or even consistently correct.
For instance, in my limited testing, there were cases of unclosed blocks that it did not find, declaring erroneously that "all blocks look OK".
Pascal has several constructs that are structured as code ‘blocks’ such as

Code: Pascal  [Select][+][-]
  1. someclass = class()
  2.   private
  3.     ...
  4.   public
  5.     ...
  6. end;

or the simpler:

Code: Pascal  [Select][+][-]
  1. begin
  2.   ...
  3. end;

Some blocks can be nested inside other blocks. On occasions a moderately complex block structure is incorrect and will not compile because it is missing a closing element. If this happens you may not always notice what is wrong, because it can be hard to spot your own mistakes. In such a case if you select the type declaration or routine enclosing the lines where the compiler message indicates the problem lies, and invoke Guess Unclosed Block, Codetools then looks for any missing element. If it finds something missing, the cursor will be placed at the start of the offending block. There is no other indication that Codetools has found the problem.

You can then usually see exactly where the appropriate missing block ending should be inserted to match the block start (now marked by the cursor).

Otherwise, if Codetools finds nothing wrong with the block structure, it pops up a reassuring Success dialog telling you that the blocks all look OK. Then you know the syntax error preventing successful compilation lies elsewhere than in faulty block syntax.
If Codetools can spot a missing block ending, I am not sure why it cannot just point this out straight away with a suggested remedy, since I suspect very few people would know to invoke Guess Unclosed block, or even be bothered to do so if they knew the functionality existed.
« Last Edit: December 21, 2019, 11:01:50 am by howardpc »

 

TinyPortal © 2005-2018