Is this okay to close now?

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.

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.

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?

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.

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

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)

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.

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
....