bugGNU Octave - Bugs: bug #60712, Editor : highlight statements that...

 
 

bug #60712: Editor : highlight statements that are not terminated by semicolon

Submitted by:  PIERRE LABRECHE <pierre5018>
Submitted on:  Mon 31 May 2021 08:58:23 PM UTC  
 
Category:  GUI Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  None Assigned to:  None
Originator Name:  PIERRE LABRECHE Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 07 Jun 2021 07:36:21 PM UTC, comment #8: 

Unfortunately I cannot help for the implementation.

I found that Matlab has checkcode and mlint for detecting potentially unintended side-effets.
https://www.mathworks.com/help/matlab/ref/checkcode.html
https://www.mathworks.com/help/matlab/ref/mlint.html

mlint finds warnings such as :
"L 49 (C 17): Terminate statement with semicolon to suppress output (in functions)."

Checkcode example:
L 48 (C 17): Terminate statement with semicolon to suppress output (in functions).

Another interesting environment, Matclipse, is found here:
https://undocumentedmatlab.com/blog_old/matclipse-eclipse-matlab-interface
Its Xtext-based editor might be useful for implementing built-in checks on the fly.

commentaire #7 :

> This regexpr has a lot of false finds, such as statements broken on multiple lines, if and switch statements with their else and case clauses, functions and endfunctions, classdefs and properties, ... and so on !

>
> Maybe this job could be done semi-reliably with some ad-hoc parsing built directly into the editor, I don't know.  But that approach seems like a lot of work and probably unreliable.
>
> My guess is that unless it is hooked into Octave's parser, the editor will have the same problem identifying expressions that are not terminated with semicolons.
>
> If it is hooked into Octave's parser, then how often will the parser have to run?  Does it have to parse the entire text from the beginning of the file each time a character is added to the file?  If there are any syntax errors in the file, the results could be wildly wrong until all the syntax errors are corrected.
>
> As a related issue, Octave's parser currently just fails at the first error.  It doesn't perform error recovery and attempt to find a new good point to resume parsing.  That could probably be fixed, but is no small task.
>
> I'm not disagreeing that this feature would be nice to have, but it seems to me that implementing it well represents a significant amount of work.
>
> We are all volunteers here.  If you are interested in this feature, can you help to implement it?

PIERRE LABRECHE <pierre5018>
Thu 03 Jun 2021 02:42:30 PM UTC, comment #7: 

This regexpr has a lot of false finds, such as statements broken on multiple lines, if and switch statements with their else and case clauses, functions and endfunctions, classdefs and properties, ... and so on !

Maybe this job could be done semi-reliably with some ad-hoc parsing built directly into the editor, I don't know.  But that approach seems like a lot of work and probably unreliable.

My guess is that unless it is hooked into Octave's parser, the editor will have the same problem identifying expressions that are not terminated with semicolons.

If it is hooked into Octave's parser, then how often will the parser have to run?  Does it have to parse the entire text from the beginning of the file each time a character is added to the file?  If there are any syntax errors in the file, the results could be wildly wrong until all the syntax errors are corrected.

As a related issue, Octave's parser currently just fails at the first error.  It doesn't perform error recovery and attempt to find a new good point to resume parsing.  That could probably be fixed, but is no small task.

I'm not disagreeing that this feature would be nice to have, but it seems to me that implementing it well represents a significant amount of work.

We are all volunteers here.  If you are interested in this feature, can you help to implement it?

John W. Eaton <jwe>
Project Administrator
Thu 03 Jun 2021 02:25:58 PM UTC, comment #6: 

Actually there are two problems with this approach:
1. I don't expect a regular user to type a complex regexpr such as this ?  Octave is used a lot in teaching environments for introductory programming.  Even experts have difficulty in remembering the regexpr syntax after a while.

2. This regexpr has a lot of false finds, such as statements broken on multiple lines, if and switch statements with their else and case clauses, functions and endfunctions, classdefs and properties, ... and so on !

An editor feature to visualize statements that produce console output because they are not terminated by a semicolon  would be very useful.

commentaire #5 :

> You might find it useful to use the search tool in the editor (Ctrl+F), and use regular expression matching to find lines with something like "^[^#%].*[^;]$".

PIERRE LABRECHE <pierre5018>
Thu 03 Jun 2021 01:24:04 AM UTC, comment #5: 

You might find it useful to use the search tool in the editor (Ctrl+F), and use regular expression matching to find lines with something like "^[^#%].*[^;]$".

Mike Miller <mtmiller>
Project Administrator
Thu 03 Jun 2021 12:32:16 AM UTC, comment #4: 

Thanks !
commentaire #3 :

> Turn the pager on with
>

> more on

>
> Then you will only get one screenful of output at a time.

PIERRE LABRECHE <pierre5018>
Thu 03 Jun 2021 12:29:12 AM UTC, comment #3: 

Turn the pager on with

more on

Then you will only get one screenful of output at a time.

Rik <rik5>
Project Administrator
Wed 02 Jun 2021 11:55:24 PM UTC, comment #2: 

The purpose is to warn that the statement will produce terminal output. 

It is actually very difficult to locate such omissions when the terminal output starts printing array data like crazy. You have to be very quick to halt the program if possible to locate the name of the variable being output to the terminal, before data output overflows the buffer.  Sometimes Ctrl-C does not even work !

Maybe there is a better way ?

PIERRE LABRECHE <pierre5018>
Wed 02 Jun 2021 11:49:57 PM UTC, comment #1: 

I think this is unlikely to be acted upon.  Statements without a semicolon are completely valid code so it seems unnecessary to highlight them in any particular way that would suggest this is incorrect or an error.

Rik <rik5>
Project Administrator
Mon 31 May 2021 08:58:23 PM UTC, original submission:  

Feature request : new highlighting feature in editor.

If a source statement does not end with semcolon, Octave prints the result. Often the missing semicolon is only noticed when executing the code.

Missing semicolons would easily be seen if such statements were highlighted by the editor.

PIERRE LABRECHE <pierre5018>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pierre5018 (Submitted the item)
  • -email is unavailable- added by pierre5018
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-08 rik5 Carbon-CopyRemoved 72865 => -
    2021-06-08 rik5 Severity3 - Normal => 1 - Wish
        Priority5 - Normal => 3 - Low
        Release6.2.0 => dev
        Operating SystemMicrosoft Windows => Any
    2021-05-31 pierre5018 Carbon-Copy- => Added pierrelabreche@gmail.com

    Back to the top


    Powered by Savane 3.6