bugGNU Octave - Bugs: bug #59916, Embedded tabs are executed when...

 
 

bug #59916: Embedded tabs are executed when code is pasted in to command window

Submitter:  Idar Barstad <idar>
Submitted:  Wed 20 Jan 2021 09:49:32 AM UTC
   
 
Category:  Interpreter Severity:  2 - Minor
Priority:  2 Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.1.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 27 Jan 2021 07:46:15 PM UTC, comment #17: 

Closing as fixed.  If there are other problems, we can reopen or create a new report.

John W. Eaton <jwe>
Group administrator
Wed 27 Jan 2021 04:40:41 PM UTC, comment #16: 

Is this okay to close now?

Rik <rik5>
Group administrator
Wed 27 Jan 2021 02:49:19 PM UTC, comment #15: 

I pushed the following changesets so that the GUI terminal now handles bracketed paste mode and to improve handling of multi-line pasted input:

http://hg.savannah.gnu.org/hgweb/octave/rev/3180f830d396
http://hg.savannah.gnu.org/hgweb/octave/rev/036079c9ee12
http://hg.savannah.gnu.org/hgweb/octave/rev/cabb840fc3f6

Note that I left the conversion of TAB -> SPC, but only if bracketed paste mode is disabled.

John W. Eaton <jwe>
Group administrator
Sun 24 Jan 2021 11:45:10 PM UTC, comment #14: 

I pushed a changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/843b1f794544) that replaces tabs with spaces before passing pasted code to the Octave interpreter.  I used qWarning() to print a warning about this in case this action might disrupt user code.  Unfortunately, qWarning() doesn't seem to print anything, but that is a separate issue from this bug report.

Marking as Ready for Test.

Rik <rik5>
Group administrator
Thu 21 Jan 2021 04:23:33 PM UTC, comment #13: 

Replacing tabs, but issuing a warning, might be the simplest approach.

I agree that this isn't a huge concern, and there are easy workarounds including putting the code in an m-file instead of direct pasting.  For that reason, the priority on this bug report is just a 2.

Rik <rik5>
Group administrator
Thu 21 Jan 2021 01:32:33 AM UTC, comment #12: 

comment #11:

> ... it would be nice to disable tab as a special character when we know we are pasting text.


Totally agree to this.

At the moment I cannot imagine a very concrete scenario of mine and I strive to avoid tabs wherever possible, I just thought of Makefiles which literally need a tab [controllable by ".RECIPEPREFIX" https://www.gnu.org/software/make/manual/html_node/Special-Variables.html].

Is it possible to throw a warning when tabs get replaced by spaces.  Making a check if a string contains literal tabs is on the level of user input not a performance killer I think.  Otherwise debugging potential problems with this becomes very difficult.

Kai Torben Ohlhus <siko1056>
Group Member
Wed 20 Jan 2021 09:07:07 PM UTC, comment #11: 

If we could, it would be nice to disable tab as a special character when we know we are pasting text.

Next best would be to replace tabs with a character that won't trigger completion.  However, it would be nice not to replace tabs within strings.  For example, someone might want to paste text that represents tab-separated values and then use strread, textscan, or sscanf on it.

Less good, but better than the current behavior, would be to replace all tabs with a different character as you suggested with text.replace().


Rik <rik5>
Group administrator
Wed 20 Jan 2021 08:28:01 PM UTC, comment #10: 

There are two locations:

For windows:
libgui/qterminal/libqterminal/win32/QWinTerminalImpl.cpp:1810
void QWinTerminalImpl::pasteClipboard (void)

For Linux/Max:
libgui/qterminal/libqterminal/unix/TerminalView.cpp:2198
void TerminalView::emitSelection(bool useXselection,bool appendReturn)

I can just add


text.replace("\t", "    ");


there for completely avoiding the issue, also for tabs in strings. Or do you think that tabs in strings should not be replaced?



Torsten Lilge <ttl>
Group Member
Wed 20 Jan 2021 07:55:13 PM UTC, comment #9: 

I will have a look where the clipboard contents is finally inserted into the terminal.

From my tests with version 6.1 on Debian even tabs in strings are triggering the autocompletion.

Torsten Lilge <ttl>
Group Member
Wed 20 Jan 2021 07:25:56 PM UTC, comment #8: 

Is there a simple location to add a regular expression to replace tabs with spaces if the tabs are not contained within a string?  I could probably write the regexp if you know where to place it.

Rik <rik5>
Group administrator
Wed 20 Jan 2021 07:20:01 PM UTC, comment #7: 

Good catch.  This works for me in the CLI version of Octave if I add


set enable-bracketed-paste on


to my ~/.inputrc file.

This works fine for me as I don't use the GUI.  But, I gather it might be a problem for GUI users until the terminal widget is re-written.

Rik <rik5>
Group administrator
Wed 20 Jan 2021 07:18:38 PM UTC, comment #6: 

Maybe tabs can be replaced by spaces in the clipboard contents before pasting in the pasteClipboard slot?

Torsten Lilge <ttl>
Group Member
Wed 20 Jan 2021 06:56:26 PM UTC, comment #5: 

May be related to bracketed paste mode?  I don't know of another way to distinguish between typed and pasted input in the terminal.  See also bug #54335.

John W. Eaton <jwe>
Group administrator
Wed 20 Jan 2021 06:48:43 PM UTC, comment #4: 

Re-titling the bug, and lowering the priority.

When code is pasted in to the Command Window that contains tabs, the interpreter/readline attempts to complete matches.  This is not desirable, although there may be no way for the parser to understand whether it is dealing with pasted text versus typed input.

For testing, I attach a file tst_tab.m.  Copy the text in the file and then paste it in to an Octave Command Window.  The result is


octave:1> for t = 1:2
> end
end                 endfor              endmethods          endswitch
endclassdef         endfunction         endparfor           end_try_catch
endenumeration      endgrent            endproperties       end_unwind_protect
endevents           endif               endpwent            endwhile
> end% tab-comment




(file #50757)

Rik <rik5>
Group administrator
Wed 20 Jan 2021 05:53:56 PM UTC, comment #3: 

I agree with your assessment on what is happening, and the question whether or not this is a desired functionality in octave. If it is, then Tab has to be used with some care. 

Putting the code in a file running it through the editor seems to work fine (probably a filter/interpreter making it work fine). Dropping it directly in the window (>> CODE_HERE) seems to be problematic with a Tab involved.

I think this case can be closed.

Idar Barstad <idar>
Wed 20 Jan 2021 05:35:53 PM UTC, comment #2: 

Could you upload an m-file that is not working as expected?

Also, the <Tab> character is used to auto-complete commands (as it does in a command line shell).  Normally you have a few characters typed in and then hit <Tab> to complete the expression or show a small list of the possibilities.  BUT, if you have no characters typed then all Octave functions and variables are a possibility and it is a long list (> 2,000).  It asks if you are sure you want to display that long list, which is what appears to be happening here.

Rik <rik5>
Group administrator
Wed 20 Jan 2021 10:00:11 AM UTC, comment #1: 

Update: it seems like this problem happens when a "Tab" sign is used between the end-statment and % <comment> ".
 

Idar Barstad <idar>
Wed 20 Jan 2021 09:49:32 AM UTC, original submission:  

Octave ver 6.1 (installed in Ubuntu 18.04LTS by flatpak)

Seems to be an issue using % <comment> at the end of line at an end-statement:

 for t = 1:2
 end                   % time-loop

gives this output on monitor:

for t = 1:2
end    
Display all 2899 possibilities? (y or n)
abcd
abs
accumarray
_accumarray_max_
_accumarray_min_
_accumarray_sum_
accumdim
_accumdim_sum_
ACER
acos
acosd
acosh
acot
acotd
....

Idar Barstad <idar>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50757:  tst_tab.m added by rik5 (31B - text/x-matlab)
file #50753:  octave_end_comm_issue.png added by idar (23KiB - image/png - screenshot of screen output)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by idar (Submitted the item)
  • -email is unavailable- added by idar
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-27 jwe StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-01-24 rik5 StatusConfirmed Ready For Test
    2021-01-23 rik5 Severity3 - Normal 2 - Minor
    2021-01-20 rik5 Attached File- Added tst_tab.m, #50757
        CategoryOctave Function Interpreter
        Priority5 - Normal 2
        Item GroupUnexpected Error or Warning Other
        StatusNeed Info Confirmed
        Summaryusing % &lt;comment&gt; after end end-statement Embedded tabs are executed when code is pasted in to command window
    2021-01-20 rik5 StatusNone Need Info
    2021-01-20 idar Attached File- Added octave_end_comm_issue.png, #50753
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code