File URIs are wrongly entered when a file is pasted about mate-terminal HOT 9 CLOSED

I' ve been seeing this for years, assumed it was intended behavior and simply edited out the file:// when dropping a file into the terminal. Note that mate-terminal is but a wrapper around VTE, so while I can confirm this is occurring it is probably something that has to be fixed in VTE (or marked WONTFIX if this is intended behavior) rather than by us

from mate-terminal.

I tested other terminals (e.g. GNOME Terminal), that are also based on VTE, and they do not show this behavior.

(I, too, have been manually dropping the URI schema for years. Specially annoying when the filepath has spaces.)

from mate-terminal.

Note that drag and drop between two programs is an interaction between them. Here we have caja as the source, VTE as the destination, and maybe or maybe not (I don't know) mate-terminal in between.
Problem might be in Caja: I fired up Nemo, dragged some directories to it and got the proper path names. Afterwards I was unable to duplicate this issue anymore within the same session at least even from caja

from mate-terminal.

It goes down to what MIME data the source application inserts in the clipboard. A quick peek shows that, when a file is copied in Caja (select file; press Ctrl+C), the following MIME formats are made available in the clipboard:

• text/plain
• text/plain;charset=utf-8
• text/uri-list
• x-special/mate-copied-files

In my tests, I used Caja as source for all the VTE-based terminals I could find (MATE Terminal, GNOME Terminal, Terminator, and sakura), but the unexpected behavior is only seen in MATE Terminal.

I think Caja does a sensible thing making text/uri-list available, as the user may paste it on an application that would welcome the file URI version (e.g. a web browser). However, it seems MATE Terminal (but not the others) wrongly picks up the text/uri-list data over the text/plain data.

I'm not sure if the same MIME data is put in the clipboard during a drag & drop operation, or how Nemo manages it, but all it's needed to trip MATE Terminal up is a source application that inserts both MIME formats (text/uri-list and text/plain) in the clipboard. For example, this minimal application can be used to populate the clipboard:

from PySide6 import QtCore, QtWidgets

app = QtWidgets.QApplication()

def set_mime_data():
    mimedata = QtCore.QMimeData()
    mimedata.setData('text/plain', b'/tmp/foobar')           # GNOME Terminal (and all other VTE-based terminals I've tried) pick this one up
    mimedata.setData('text/uri-list', b'file://tmp/foobar')  # MATE Terminal picks this one up
    app.clipboard().setMimeData(mimedata)

QtCore.QTimer.singleShot(100, set_mime_data)
QtCore.QTimer.singleShot(1000, app.quit)

app.exec()

When I say the behavior is "unexpected" (or "wrong") it's because I can't think of a general use case in which a user would want a file URI in the terminal instead of the natural filepath in the filesystem, but I can't be sure whether it's unintended behavior.

from mate-terminal.

the only logical thing for mate-terminal would be to autoconvert text/uri-list to text/plain when pasting

from mate-terminal.

current workaround: I use middle click to paste. there its replaced correctly

from mate-terminal.

Do we know if anyone considersfile:///the expected behavior?

from mate-terminal.

the only logical thing for mate-terminal would be to autoconvert text/uri-list to text/plain when pasting

Only if text/plain is not available, though.

from mate-terminal.

9d043b4 is merged.

from mate-terminal.