On Tue, Jan 7, 2020 at 2:01 AM Bruno Haible <br...@clisp.org> wrote: > José and I are asking for (C) and (D). (C) is a major feature for GNU > poke,
An application which I haven't heard of before, and is not shipped by latest Ubuntu or Fedora. > and (D) will be a major feature for GNU gettext. For translators and QA of translations of terminal-based apps, i.e. a tiny user base. Mind you, this: > - An interactive program has a 'help' command that prints > a set of available commands. When the user selects one of these > command, the command gets added to the prompt. This reduces > the amount of necessary typing. can already be achieved by your application handling mouse events, and it works even in terminals without support for explicit hyperlinks. Or, if the app doesn't manage its full screen but rather "just prints" stuff and lets it scroll out, as e.g. the shell, then your proposal doesn't say a word what would happen when the link is still visible (maybe the user even scrolled back) but the application is no longer running, no longer listening on the given port. Or a different application started to listen there. Or can be done currently by selecting the word with double-clicking, and pasting with middle-click or Shift+insert or alike. However, those who want real efficiency would probably ask for TAB autocompletion or other keyboard-based approach, rather than having to reach out to the mouse. The things you propose here might be great for in-house hacks where security and robustness don't matter; but are nowhere near to, and conceptually start in the wrong direction to become standardizable, shippable and widely usable. I'm not sure if you'll require any buy-in from either the hyperlink specification, or from its implementations in terminals. Maybe you don't, because an app can already register an appfoo:// URL-handler in e.g. GNOME, and another app might emit these in the terminal, and then gnome-terminal will automagically open these for you. If that's the case, I personally couldn't care less what protocols you invent for yourself. But if you require any buy-in from the hyperlink spec or from vte/gnome-terminal, you definitely won't get mine in this current direction. What you propose suffers from so many conceptual problems, including but not limited to the utter lack of security that you haven't responded to, that it just can't be taken seriously. I'd love to hear how much of your problems would the line number feature (if done correctly) solve, and whether you're interested in implementing that according to the approach I outlined (involving convincing the desktop spec to add a new field, apps to start shipping desktop files that use that feature, and new convenience methods implemented by GTK and friends). e. _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg