On 2012-04-13, Jail Bush Cronies <do....@ask.me> wrote:

Uh, yes, duh. All I an saying is to amplify Wingates comments that one
can move a whole buch of files at once, not one at a time. As long as
there is some pattern to the files you want to move, you can glob your
way to moving them all at once.

mv foo bat baz path

Nope. I just feel that if I am replying to a post, I will leave the
context for that reply there. What you consider extraneous the next
person might consider crucial. And I hate it when I get a reply so
trimmed I have no idea what the reply was to.

What charge?
And yes, I use a console-mode, unix newsreader. So what? Have you become
a member of thought gestapo now?

Hey! Hey! Stop that!!! Why do you think I read these things???

--
John Forkosh  ( mailto:  j...@f.com  where j=john and f=forkosh )

On 13/04/2012 12:19 AM, unruh wrote:

And you can move them all at once in a GUI even when there isn't.

If they want to reply to any of that they should reply directly to the
post before yours.

Yes, that's erring too far in the *other* direction.

That you're using a primitive console-mode unix newsreader. Don't you
know how footnotes work? :)

What does your classic erroneous presupposition have to do with TeX, unruh?

Hmm. That sounds *very* familiar ...

--
The "reality TV" craze is as if your local hamburger joint replaced the
burgers on their menus with tins of the cheapest noname dog food they
could find in the pet store aisle of the supermarket, didn't change the
prices, and magically continued to get just as many customers!

On 12/04/2012 11:56 PM, jon wrote:

You do know, don't you, that there tend to be length limits on command
line inputs? What if there are 30 files, or 300?

Also, that it's got to be typed into, in essence, a crummy line editor
that makes it a pain to edit anything longer than one screen-width?

And no doubt if there's a typo in the name of the second file it will
move the first, spit out an error message about the second, and leave
the other 28 just sitting there, and you'll have to do nearly all of
that typing again?

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 13/04/2012 12:10 AM, Robert Heller wrote:

Subject to command length limits and the cruddiness of trying to edit
anything wider than the screen at that prompt ...

Actually yes. What part of "by definition" did you not understand?

And you seem to have the same issues with trimming unused quoted
material as unruh. I take it either TkNews is as horrid for editing in
as slrn is, or else it's some weird cultural thing in comp.text.tex?

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

This thread has digressed so much that it's got nothing to do with comp.text.tex anymore. If you feel you still want to exchange opinion, may I suggest you move this thread to some comp.os group?

Regards,

Marc van Dongen

On 13/04/2012 6:17 AM, Marc van Dongen wrote:

You may *suggest* it ...

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

At Fri, 13 Apr 2012 03:46:49 -0400 "javax.swing.JSnarker" <gharri...@boojum.mit.edu> wrote:

The limit is fairly large.  And as likely as not, there would be some
'pattern' to the names.  Otherwise there is find(1), xargs(1), etc.

Actually not...

Actually not.  Modern shells have command recall.  Also with
auto-completion, I would not be typing all that much.

It is no worse with a GUI.  One would still have to control-click on
each of the file icons and then one can still make mistakes doing that.

--
Robert Heller             -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

On 13/04/12 04:52, Jail Bush Cronies wrote:

What's wrong with mv foo bar baz path/

If the filenames are short, it's probably faster than trying to click
ctl-click ctl-click to accumulate the files, and then try to navigate
the directory sidebar to find the place to drag and drop them to,
without the pointer losing focus.

Actually, the biggest bugbear of computer systems for personal use is
their insistence on giving higher priority to their housekeeping tasks
than on watching the input device buffers. That means that half-way
through some complex edit, the system decides it needs to download
something, or rearrange its swap pointers, or reindex slocate, so it
grabs all the memory it can find, trashes the user's buffers, loses
focus on the mouse, fails to respond to any input, and heads off to do
its own stuff for a few seconds. I find this grossly unacceptable.

This is because the designers considered the system to be more important
than the user (understandably: it's their baby). But on a modern system
the user is the boss, and the clock should be reprogrammed to take that
into account. The system should never start or wake a background process
at a higher priority than user input.

One of the advantages of Unix-based systems is that you can fix that
behaviour (you can even nice a Mac, apparently). I have no idea what you
would do on Windows to stop it spending so much time reindexing the disk
every time want to do something, or spending more cycles doing a small
update than are consumed by an entire from-scratch installation of Linux.

///Peter

On 13/04/12 08:46, javax.swing.JSnarker wrote:

ARG_MAX is denominated in bytes (mine says 2097152) not numbers of
files. Anyway, what's wrong with using xargs?

If you need to do something like that with that many files then you
should find some common denominator and parameterise it in a script, or
treat it as a once-off task and do it by hand.

Mine (Ubuntu) wraps perfectly happily line after line if needed, and
lets me use the arrow keys to edit it.

But yes, if you constantly find yourself worried by the terminal width,
you're either doin' it wrong or you need to seek professional advice.

You really haven't used a modern Linux system, have you?

///Peter

On 2012-04-13, Jail Bush Cronies <do....@ask.me> wrote:

I still do not see a charge. I see a statement, which, except for the
attempted pejorative "primative" is simply a statement of fact, not a
charge.

You don't have to open two windows, you don't have to drag, perhaps you
don't have to scroll the source window because the icons take up so much
real estate you can't see all of them at once, ...

So was I.  Your ignorance of mv is showing.

mv aaa.jpg bbb.png ccc.tiff SillyLongFileName.psd dest_dir

with file names not typed, but selected this way:

BTW, in case you think unruh's response ("mv file? path") to your
example presents only two arguments to mv, it doesn't.  The shell
invokes mv via "mv file1 file2 file3 path" (if those are the only three
files that fit the pattern).

I don't see why seeing a destination window is an advantage.  I grant
that thumbnails can be useful if the files have unhelpful names; e.g.,
PICT0001.JPG ... PICT0567.JPG.

Er, before you start defining things and presenting examples based on
your limited view, you should investigate the capabilities and
limitations of the X11 selection service.  It's a different way of doing
things, with its own advantages and disadvantages.  It has other uses than
manipulating blocks of text.

Incidentally, if you want to use clipboards in the way you are used to,
you can save selections to and retrieve them from any of several (eight,
maybe more) cut buffers.

Nope. Typically, no selection any more, so nothing to paste.  If notepad
(X11 version :) ) and the target program behaved like xterm (and also used a
cut buffer) it would work as I think you would want.

Please stop criticizing what you don't seem to know very well on the basis
of what you think is the one true way of doing things.

--
John Wingate                        Mathematics is the art which teaches
joh...@tds.net                      one how not to make calculations.
                                                         --Oscar Chisini

    javax> Now, if you ask me, the ideal UI would be an Explorer-like window with
    javax> a little minibuffer added at the bottom that acts like a command
    javax> prompt with that window's location in the filesystem as its current
    javax> directory. (The cwd command there would, of course, make the whole
    javax> window and not just the prompt go to the new directory.) Best of both
    javax> worlds, then, as it would obviate the need to copy and paste the
    javax> pathname in some instances, or to start a separate command interpreter
    javax> window.

This - and a lot more - you could have on the Lisp Machine in the
Listener.
Those were the times.

'Andreas
--
ceterum censeo redmondinem esse delendam.

    elzbet> On Thu, 12 Apr 2012 22:07:37 -0400, javax.swing.JSnarker wrote:
    >> On 12/04/2012 12:07 PM, unruh wrote:
    >>> On 2012-04-12, javax.swing.JSnarker<gharri...@boojum.mit.edu>  wrote:
    >>>> On 11/04/2012 11:27 PM, Robert Heller wrote:
    >>>>> They are.  Have you tried them on a modern Linux system?
    >>>
    >>> And what follows is a wonderful example of [implied insult deleted].
    >>
    >> What does your classic unsubstantiated and erroneous claim have to do
    >> with TeX, unruh?

    elzbet> Hmm. That sounds *very* familiar ...

Indeed, it does! And we are not even in comp.lang.lisp :-)

'Andreas
--
ceterum censeo redmondinem esse delendam.

On 13/04/2012 11:29 AM, unruh wrote:

In other words, except for some little thing, it's not a charge. In
other words, it *is* a charge. Gotcha.

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 2012-04-13, javax.swing.JSnarker <gharri...@boojum.mit.edu> wrote:

?? insults are not charges. They are just insults, especially when they
are lame insults. So, to parse it again. You made a statement of fact
into which you also threw in an attempted insult (primative). Except for
that attempted insult, the rest of your statement is simply a statement
of fact. With the insult it is a statement of fact plus and  a lame insult. It
is still not a charge.

On 13/04/2012 9:04 AM, Peter Flynn wrote:

I doubt it, unless they're one or two letter names, and there are
possible length limits to the command line to consider. Also, you can
typo a filename (and the longer the total length of the command line the
proportionately more likely there'll be at least one typo) and the
command will abort half-finished, whereas if you miss with a control
click, you might move a file you wanted to keep and miss a file you
wanted to move, but that's quick to correct and doesn't require redoing
half the *rest* of the files. Just two.

Just don't let your finger slip off the ctrl key. :)

And then there's the case where you want to move, say, all the pictures
of Tom's face. It's easy to pick those out with a thumbnail view in
Windows Explorer or something similar, and just control-click them as
you see them and then move them. Contrast Unix:

* ls
* my-previewer foo.jpg
* my-previewer foo2.jpg
* my-previewer bar.jpg
* Aha, Tom's face!
* mv bar.jpg dest/
* my-previewer quux.jpg
* my-previewer mumble.jpg
* mv mumble.jpg dest/
* my-previewer frotz.jpg
* Uh oh, next name after frotz.jpg scrolled off the top of the screen
* ls
* my-previewer quuuux.jpg
...

Most GUIs do seem to have issues in that area. They also don't seem to
queue up keyboard and mouse events in a common buffer, so if the system
gets slow, you can shift-click and it will act like you clicked and then
tapped shift, or similarly.

This is not an inherent problem with the GUI concept, though; just a
problem of shoddy implementation of the concept.

But there are ways to tame the beast -- at least on Windows.

Macs these days run a disguised version of BSD Unix so that's hardly
surprising.

Disable indexing service.

Disable other unnecessary services and startup items. (There are Web
sites that can guide you regarding what's junk, what's needed only for
XYZ so is junk if you don't need XYZ, and what's important and/or not
prone to being a pain.)

Disable automatic updating so it just notifies you, and then install
updates at *your* convenience after said notification.

Get Sysinternals ProcessExplorer (it's free, though not libre) and use
it to lower the priority of anything that shows as gobbling excess CPU
when you notice the interface get slow or jerky.

Unfortunately, there are some ill-behaved things that seem able to
bypass the priority controls in Windows. Usually these aren't Microsoft
programs but third-party ones. The file-sharing software Shareaza is a
known instance -- it can occasionally slow the system down even when
given the lowest priority, but this only tends to happen if you have a
giant library of over 30k files or so and a new one downloads. Whatever
it does is also quadratic in the size of the entire library, so it's
obvious they used bubblesort somewhere and on a thread with high
priority compared to the application. No easy way to fix thread
priorities even with ProcessExplorer.

Another pain is that, while ProcessExplorer will tell you which of the
fifty svchost.exes suddenly started eating a full core and will tell you
via tooltip what services are in a svchost container, it won't tell you
which service is the one responsible for the CPU spike. Sometimes
there's only one; Windows Defender has a svchost.exe all to itself and
randomly grabs a full core for a few minutes every few hours for no
discernible reason. Other times it's a svchost with a dozen or more
hosted services and it's anybody's guess which one's the culprit.

That said, it's not exactly all sweetness and light on the Unix side
either. Beside the much more cumbersome interface (CLI "top", then "ps",
then "nice", copying and pasting long opaque numeric processIDs all the
way, vs. a neat list of processes you can keep sorted by CPU% and just
right-click "priority Idle" the topmost item from) there's also the
minor matter that, again, the system can start whole new processes with
high priorities. You can nice them, but next time it comes back it will
have the original high priority again. This can happen on both systems,
of course, but starting whole new processes to do everything instead of
having long-running mostly-idle processes is much more a Unix thing than
a Windows thing.

Well, except for one area: installs involving .NET. If you install a
.NET app or framework update, and watch in ProcessExplorer, you'll see a
ton of short-lived processes starting up -- TrustedInstallers and a
bunch of other things with more obscure names. If you poke and prod them
you'll discover they're a compiler and related tools. In other words,
when it installs something .NET does something rather reminiscent of tar
-xf foo, make, make install as far as the system processes are concerned.

Fortunately, it only does this when you tell it to install something --
given that you have disabled fully-automatic installs, of course.

On 13/04/2012 8:23 AM, Robert Heller wrote:

More annoying extra commands to learn just to work around the fact that
something scales poorly. Vs. open destination folder alongside source
folder and drag, drag, drag, which is faster than typing random long
names and scales linearly in the total number of files (and NOT in the
lengths of their names). Or, when there is a pattern, using search or
sort order to get those files in a solid batch and then click,
shift-click, drag.

Actually yes. Anything longer than 80 characters = horizontal scrolling.
Without even the mitigation of a horizontal scrollbar being available.
To go left and change something you have to hold down <- for ages; you
can't just zip rapidly to the left and click at the site of your
intended edit.

And you're not even guaranteed that basic editing functions will work.
I've seen all kinds of misbehavior in these circumstances:

* Hitting left-arrow rapidly spams the command line with repetitions of
   some bit of nonsense text like ^]]D^]]D^]]D.
* It works, but one or both of bksp, del does not DTRT.
* Typing overtypes rather than inserts and INS doesn't fix it, etc., so
   if you need to replace a shorter item with a longer one you're
   attached to something by an inclined plane wrapped helically around
   an axis, so to speak.
* In the worst case the line is not editable at all; left arrow, bksp,
   del, right arrow ALL fail. If you flub something, at best you can hit
   enter and start over. And if you go to type "rm *.o" and suddenly
   notice that you've accidentally gotten "rm *>o" instead, the only
   way to save yourself is to *disconnect* or (if you're at the machine
   in person) *hit the goddamn power switch*! Unbefuckinglievable!

Worse, this seems to be highly dependent on the particular Unix and even
the particular installation of that particular Unix. Two machines both
running the same version of Solaris that you sometimes have occasion to
telnet to might differ, one supporting all the normal editing keys at
its command prompt and the other not supporting left-arrow.

The one thing you *can* rely on in that area is that nothing in the way
of editing keys will work correctly at the unix login prompt. ^]]D, etc.
If you typo your username, you need to hit enter, hit enter, stare at
the "Login incorrect" message for the several seconds' delay that's
there to limit the rate at which anyone can attempt to brute-force an
account's password, and then start over.

If the system you're using is lucky enough to have a modern shell. And
working editing keys, without which command recall isn't very helpful.
And even then you have roughly as many left-arrow keypresses to make as
you would have had filename characters to retype anyway.

Unless you made a non-ctrl click by mistake, you can correct it easily
by control-clicking the same item again, and then the intended item. You
can also avoid building up a big, complex, delicate selection in any of
three ways:

* Do the moves/etc. one by one. You'll need to anyway if you want to
   give them all ad hoc new names at the same time, and it's not much
   slower if you position the destination side by side with the source.

* Sort the files, if there's a characteristic that groups them in one
   batch, and click shift-click to select a range. The intended files
   may have a characteristic in common, such as all being 42 bytes in
   size, all having names starting with "foob", all being modified
   on June 17, 2002, or even all being 1024x768 jpegs, and Explorer
   sort options can bunch them together.

* If there's a more complex naming pattern than a common prefix you
   may be able to use search to generate a results window with exactly
   the desired files, and then use that as the source of the drag
   operation. Now you can even just hit ctrl-A to select all.

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 13/04/2012 9:14 AM, Peter Flynn wrote:

Not every system has it that large. Lots I've seen balk at a command
line of over 256 characters -- easily exceeded by a *single* filename
with a deeply-nested path.

More typing. Another command to learn. More complexity. Vs. simply
control-clicking one more file.

Which would you prefer, a car like typical ones now or one where, when
you go past 40mph, you suddenly need to use the wheel, pedals, and stick
completely differently to do the same things as you did below 40?

And for "doing it by hand" a GUI is ideal.

Oh, that's even *worse*! It sets up the expectation that if you want to
change something directly above the cursor you can just hit up-arrow and
change it, and then you hit up-arrow and the whole thing disappears,
replaced with the previous command, and then you hit down-arrow and get
either a blank prompt or the command you had been editing -- but with
your edits undone.

Yeah, you're doin' it wrong, alright, and the error you're making is
called "not using a GUI"! That's a sure sign that your best option is to
use a GUI to hands-on *grab* those files and *haul* them from place to
place instead of trying to order the brain-dead butler called "the
shell" to do it for you. Unless it's an oft-repeated task, where you
might want to consider programming something to do it for you instead
that has a simple way of executing it, like

% tar-up-new-image-files

instead of "ls -whatever-bloody-option-sorts-by-modification-date"
<enter>, tab to other term window, "tar -xf ", and then lots of tabbing
back and forth copying and pasting file names.

Most mere mortals do NOT have a Unix guru on call 24/7, so that's simply
not an option for any system you're trying to put forward as
"user-friendly".

I already answered that question (in the negative) in an earlier post.
That one had command history on up-arrow and the editing keys worked in
the command line, but as I mentioned it had lots of other problems,
ranging from documentation to lack of a driver for the 56K modem (no
broadband in my area then) and thus no network access(!) to a lot of
things not working out of the box (after reboot to Windows, search for
rpms online, download, reboot to Linux, run command to mount NTFS
volume, cd to download directory, run rpm...), to the way the system
seemed to suffer bitrot on any unplanned shutdown-and-reboot (and this
area gets electrical storms a lot in the summer, so there are a lot of
2-sec power outages with occasional longer ones).

The latter two were particular nuisances. An rpm for a given application
would typically complain about missing dependencies. So I had to copy
these, paste into editor, save into file on NTFS volume, reboot, pick
Windows from boot menu, go to rpm archive sites searching for the
dependencies in the list, download them, once they'd all downloaded (at
56K!) reboot, pick Linux from boot menu, try to install dependencies
with rpm, get lists of *their* dependencies ... At the end of the
process, there was maybe a 50/50 chance the thing worked OOTB. If it
didn't, it often complained that files weren't in some place it was
expecting them, but sometimes was less clear why it wasn't working.
Files in wrong places could generally be fixed by finding them, moving
them if they weren't used by anything else, or copying them or making
symlinks if they were. I think there was another 50/50 chance or so
there, so there was a 50% chance the application would work OOTB, a 50%
chance it could be made to work with some extra manual steps
post-install, and a 50% chance it was just plain broken, or at least had
undocumented extra install steps that I'd have needed that 24/7 on-call
Linux guru to discover and perform.

As for the power-failure bit-rot, the cause of *that* (but not the fix,
short of lighting a fire under the dev-team's ass and then waiting years
for an upgrade to ship) was obvious: OS misdesign, to wit, caching disk
writes and not flushing the cache at all quickly even when the system
was idle. No doubt born of Unix's heritage as something run on
mission-critical servers and mainframes that would a) pretty much never
be idle during production and b) all have big expensive battery backed
up power supplies in their big expensive corporate or university machine
rooms.

Someone ported Unix to the desktop without *thinking*. Gah.

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 13/04/2012 11:50 AM, John Wingate wrote:

If the file selection is ad-hoc, you need to have more information than
just the name for each one, typically, when choosing them, AND the time
to decide, for each file, whether to move it typically dominates the
time taken to do one more control-click or even full click-drag operation.

When the computer's automation a) lets you do the job faster than you
can think about each item and b) doing so involves a hairy syntax full
of punctuation characters and case-sensitive text, massive and
catastrophic errors that happen too fast for you to stop them become
likely in the long run. :)

If the file selection isn't ad-hoc, the GUI, the CLI, or both usually
offers some alternative method, such as wildcards or search results or
sort order, for grabbing the desired files as a unit.

As for opening two windows:

a) It's not very difficult or slow.
b) It only takes about as much work as specifying each subdirectory of
    its path at the CLI does.
c) You can see what you're doing, so if you go astray you realize it
    immediately. GUI: double-click "foo", double-click "bar", see
    "local" and "locals" folders, double-click "local", don't see
    "baz", so back button, double-click "locals", and move on. CLI:
    % mv file1 file2 file3 /foo/bar/local/baz/quux/and-so-on
    no such path /foo/bar/local/baz
    % *$&@!!!!
d) You can see the full context of your command, to wit, the contents
    of both directories and not only the source (if even that). In
    particular, before copying you can see if you already did it earlier
    and forgot; you can see if you're in the wrong directory (from an
    unexpected set of visible files) despite the path looking, at first
    glance, correct. (Maybe both local and locals have the baz/quux/and-
    so-on subpath in the example above.)

So, there are benefits, in the form of additional opportunities to spot
and avoid or recover from errors, and no real costs, to that
opening-another-window bit.

In particular, in the example above with "local" and "locals", you can
detect the error instantly and fix it with two clicks and keep going. After

% mv file1 file2 file3 /foo/bar/local/baz/quux/and-so-on
no such path /foo/bar/local/baz

your best bet is up-arrow and then a whole lotta left-arrows to the end
of "local", then type the "s". That's slower than two mouse clicks if
there's very many left-arrows needed at all, AND it depends on command
history being a feature of that shell, which in my experience is by no
means guaranteed.

What does your classic unsubstantiated and erroneous claim have to do
with TeX, Wingate?

59 input gestures. Some command prompts have a command length limit as
low as 256 characters, so quadruple the number of files or give them
longer names and you have a problem.

Versus control-clicking scaling and requiring just five input gestures:
click aaa.jpg, control-click bbb.png, control-click, control-click, drag
and drop on dest_dir which is presumably a subdirectory of the current dir.

If it's not, then getting at it takes another input gesture per
subdirectory to expand from its deepest common superdirectory with the
current one, versus many more at the CLI for all the path elements from
root or else a whole bunch of ../../s.

Completion, *if* supported at that shell, *might* reduce that to triple
or quadruple the work of control-clicking as you can then just type
enough of a prefix to uniquely specify a file or directory and then hit
tab for each of the GUI way's mouse clicks.

Copy and paste reduces it to six times the work of the GUI solution, to
wit, for each GUI control click you have a GUI/CLI click, shift-click,
copy, click, paste, space. If words select on double-click (de rigueur
in any decent text editor; I wouldn't think it could be relied on in a
terminal whose GUI is a bolted-on afterthought) then it's a mere five
times as much work: double-click, copy, click, paste, space instead of
control-click.

(The extra work involved in scrolling, if the source directory's
contents won't fit on one screen, is one wheel flick for every N
selected files, so it's lost in the noise. Besides, an ls output you're
copying from and a "list" view in Explorer will be about equally
compact, and the ls output *can't* be scrolled, you have to rerun ls
with a pattern to exclude the first part of the alphabet.)

See above. Even seeing the stops along the way in navigating *to* the
destination in a window can be an advantage.

Guess how files tend to be named by digital cameras and/or the tools
that import them via USB onto your computer's disk.

Files acquired from P2P or Usenet are prone to long and/or awkward
and/or just plain incorrect naming.

Files that are normally created and dealt with by automation, ditto.
Node301845.dat, anyone? And if you don't think the need occasionally
arises to fix something or back something up manually with such files,
dream on. Sure, those won't be helped by thumbnails, but they *sure*
won't be helped by shell wildcards either. Control-click or
sort-by-modified-date or similar it is, then, and the GUI shines in this
case.

What does your classic erroneous presupposition have to do with TeX,
Wingate?

We can define "the contents of the clipboard" to be "whatever will be
inserted here if I hit the paste key". If doing something changes that,
then it clobbers the clipboard. It *doesn't matter*, for this purpose,
whether the real storage model is just a pointer and a length. If
selecting something else changes what will get pasted, then you've lost
what you intended to paste and need to go copy it again, even though
"only" a pointer and length got overwritten in memory.

Or to put it more simply: if you select "foo" and cut it, then select
"bar", and then paste pastes "bar" instead of overwriting the selected
"bar" with "foo", you've just lost "foo". No amount of quibbling about
definitions and semantics will change that blunt fact.

And if "foo" was really six paragraphs of your thesis you'd just typed
and hadn't saved before cutting it, you are now attached to something by
an inclined plane wrapped helically around an axis. Again.

Are you on crack? The X clipboard ONLY does text, UNLIKE the Windows one
which can also do chunks of bitmap and any application-defined data
structures you care to name, and which can also store multiple
representations, so you can select from a web page, paste in Word and
get text with at least some of the italics and other formatting
preserved, and paste again in Notepad and get plain text without garbage
control characters from Word's .doc format *or* HTML markup (but, no
formatting). (And if you *want* the HTML markup, you can select and copy
from the browser's "View Source" window instead of the rendered page.)

Sounds like a bunch of extra work, equivalent to the workaround I'd use
on such a broken system anyway, to wit, keep a notepad open and always
paste promptly to that and then use it again to copy and paste to the
destination later.

Well, that's even sillier, if anything. Albeit safer. Except if you did
something like capture the output of a command in a terminal buffer,
select, copy, close terminal window, paste, and oops, nothing!, now need
to start ALL OVER AGAIN and this time make sure after the copy to click
to the other window rather than close the terminal window, paste, then
click BACK to the terminal window, and THEN close it ... notice the
extra work needed vs. just closing the terminal window and ...

read more »

On 13/04/2012 5:29 PM, unruh wrote:

What does your classic erroneous presupposition have to do with TeX, unruh?

The proper role of a CLI is as a kind of REPL for testing and developing
scripts, unruh. Using a CLI as the primary manual user interface to the
system for other tasks is primitive, unruh. We've had better user
interfaces since the sixties, unruh, particularly the Xerox PARC
research and the Lisp/Lisp Machine research.

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

At Fri, 13 Apr 2012 17:37:21 -0400 Jail Bush Cronies <do....@ask.me> wrote:

Dumb.  A sane image viewer will take multiple image file names on its
command line:

xv *.jpg &

Then, you just need to build one command line, as you scroll through the
images:

mv bar.jpg mumble.jpg ... dest/

Not disguised, just a different GUI front end.  Under the hood it is in
fact BSD.

--
Robert Heller             -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

On 13/04/2012 7:34 PM, Robert Heller wrote:

That's CLIs for you! Dumb!

Even if you managed to do this, that's a lot of typing and alt-tabbing,
or at least copying, pasting, and alt-tabbing, compared to an Explorer
large-icons or filmstrip view and control-clicking.

Or this little trick, if you have disk space to spare: Copy all the
images to a temporary directory and then open the first image in the
previewer. Delete it from there if it's not Tom's face or else
right-arrow to get to the next image. Repeat until it cycles back to the
first image you kept. Then move the remaining files to the real
destination. This works if you intended a copy rather than a move from
the outset. If you really want a move, you can either do this in place,
move the survivors to the destination, and then open the recycle bin,
sort by date-deleted, and drag everything you deleted back to where it
had been (yes, the recycle bin is that safe and reliable if nothing else
is concurrently filling that disk).

And the word for having replaced the face of something while keeping
what it is under the hood unchanged is ... "disguised"!

Nothing, of course.  You were already far off-topic when I entered this
thread.

Only if typing each character.  You snipped my explanation of another way
to construct the line with the help of the mouse.

Which CLIs have a 256-character limit?  The last one I used that had
anything near that was MS-DOS.  (I think its limit was 128 characters.)

No copy step. And the click is the paste--but now we are getting to
picking nits.

Not so sure about the compactness of Explorer list view vs the ls view.
And a long ls output scrolls very nicely with a wheel flick in my xterm.

Guess where I got my example.

That's true of the cut buffers, which predate the selection service.

The X selection service likewise does source and destination
context-sensitive C&P.

If you know it very well indeed, please show us that you do.  Mostly
you have done quite otherwise.

--
John Wingate                        Mathematics is the art which teaches
joh...@tds.net                      one how not to make calculations.
                                                         --Oscar Chisini