Re: [lmi] konsole clipboard stopped working (fixed)

[Vadim Zeitlin]

On Thu, 2 Nov 2017 12:40:19 +0000 Greg Chicares <address@hidden> wrote:

GC> Yesterday, copying from konsole to the clipboard stopped working.
GC> Nothing copied from konsole could be pasted anywhere: not into
GC> thunderbird, nor into vim (neither "+P or "*P), nor into konsole
GC> itself. One (only one) of my (many) konsole sessions said:
GC>   QXcbClipboard: SelectionRequest too old
GC>   QXcbClipboard::setMimeData: Cannot set X11 selection owner
GC> A web search for these error messages found many problem reports
GC> over several years, but the most plausible suggestion I saw was
GC> to reboot. (Reboot? Linux??)

 This is indeed distasteful.

GC> Instead of taking that advice, I closed every konsole session,
GC> then opened new ones. The problem disappeared. I guess this
GC> resolution is as good as can realistically be hoped for.

 If konsole were a wxWidgets program, I'd be worried that there is a
resource leak in wxClipboard. It isn't, of course, and I don't care about
Qt bugs nearly as much, but it does look like a QXcbClipboard bug...

GC> I'm really glad I took the time to port and document the
GC> scripts in
GC>   http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs

 I couldn't help looking at those scripts and I wonder about the use of
"git remote update" at
http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs/1/startup_script#n6
What is it for?

 And while I was writing this, I received the email about your commit
3df3e622be691da20f5a38dcd19700b0f62998f3 ("Synchronize more than one recent
commit to local mirror") which addresses my other question. However I still
question the use of HEAD~5 in the script, might you really want to use
address@hidden, i.e. the previous value of the HEAD pointer before it was 
changed
by the subsequent command (git pull) instead?

GC> These scripts are clunky, but tiny and comprehensible, so I prefer them
GC> to tmux or gnu screen.

 FWIW screen is pretty similar, you just list the commands you'd like to
execute in your ~/.screenrc and that's it. Of course, you can get fancier
if needed, e.g. my own ~/.screenrc is split in host-independent and
host-specific parts, but you don't have to do it like this. And it allows
you to give specific numbers and titles to the different windows, which is
not the case of your scripts AFAICS.

 BTW, I don't want to disparage tmux, it's supposed to be better than
screen, it's just that I've never used it because I'm too used to screen.


GC> There is one question I'd like to ask, though. My habit is to
GC> run schroot with identical parameters in each of approximately
GC> five terminal tabs. That seems to work perfectly well, but is
GC> it distasteful for some reason that I'm not perceiving?

 No, I don't think so. There is no real overhead in using chroot, i.e.
launching N chroot'ed processes shouldn't be materially different from
launching N processes inside a chroot.

 I probably still would use a single chroot and just launch a screen inside
it because I absolutely always use screen anyhow (if only not to lose my
session in case of disconnection/closing the window/anything else short of
reboot -- but this should never happen, of course, see above). And using a
single screen inside a chroot just seems more logical as it ensures that
all windows inside it have the same filesystem view while it could be
possible to accidentally mix up chrooted and not-chrooted processes
otherwise. But it's just a subjective preference, really, there is nothing
wrong with doing it in the way you do.

 Regards,
VZ