Editing filenames with spaces 
Author Message
 Editing filenames with spaces

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Some time ago (1993 I think) a decision was taken to make ved treat an
argument with spaces as a request to read in multiple files.

So,

   ENTER ved my report

makes Ved attempt to read in a file called "my" and a file called
"report".

However since then it has become increasingly common for file stores for
use on unix and on windows/NT to be integrated. E.g. in this school
all users get the same login directory whether they are using PCs
running NT or using machines running solaris, linux, etc. Thus files
created on any of the systems are accessible on the others.

This makes the current behaviour of Ved intolerable, and as far
as I can tell there is no facility for turning it off.

Has anyone found a way to disable this?

Does anyone ever use the ability to give Ved an argument with spaces?
(I have known about it for a long time, but have never found it
of any use.)

I am inclined to find and comment out the code that breaks up
vedargument if it contains spaces, or control it with a new
global variable, e.g.

    ved_multi_edit

with default value false.

Comments? Suggestions?

There may be other utilities in pop-11 that will not work if file or
directory names contain spaces. I have not checked sys_file_match
for instance.

Aaron
====
Aaron Sloman, ( http://www.*-*-*.com/ ~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.*-*-*.com/
FREE TOOLS: http://www.*-*-*.com/



Sun, 26 Oct 2003 18:24:32 GMT  
 Editing filenames with spaces

Quote:
>    ENTER ved my report

> makes Ved attempt to read in a file called "my" and a file called
> "report".

> However since then it has become increasingly common for file stores for
> use on unix and on windows/NT to be integrated. E.g. in this school
> all users get the same login directory whether they are using PCs
> running NT or using machines running solaris, linux, etc. Thus files
> created on any of the systems are accessible on the others.

> This makes the current behaviour of Ved intolerable, and as far
> as I can tell there is no facility for turning it off.

I don't know how to turn it off, but there seems to be a different
itemiser for the command line, because ENTER ved 'junk 1' looks for
files 'junk and 1' (i.e., with quote marks as part of the names), rather
than treating 'junk 1' as a string.

I think the most natural thing would be to require the user to quote
names containing spaces (or other abnormal characters) in the way that
shells do.  The procedure vedfilecomplete (bound to ESC 3 on my solaris
xved) could be made to assist the user by inserting quotes around words
that need them in the way that file completion in the bash shell does.
At the moment, if I have a file named 'junk 1', and ask ved to complete
a filename beginning with 'junk', it offers me 'junk 1' as a choice, but
then behaves as Aaron describes if I accept that choice.

Steve



Sun, 26 Oct 2003 20:13:57 GMT  
 Editing filenames with spaces

Quote:
-----Original Message-----


Date: 09 May 2001 13:18
Subject: Re: Editing filenames with spaces


>>    ENTER ved my report

>> makes Ved attempt to read in a file called "my" and a file called
>> "report".

(snip)
>I think the most natural thing would be to require the user to quote
>names containing spaces (or other abnormal characters) in the way that
>shells do.  The procedure vedfilecomplete (bound to ESC 3 on my solaris
>xved) could be made to assist the user by inserting quotes around words
>that need them in the way that file completion in the bash shell does.
>At the moment, if I have a file named 'junk 1', and ask ved to complete
>a filename beginning with 'junk', it offers me 'junk 1' as a choice, but
>then behaves as Aaron describes if I accept that choice.

I don't know if the following is of interest, but it might be :-),

In Windows, if you drag files onto the icon for an executable program (or
shortcut [== symbolic link] to a program) it runs it with command line
arguments consisting of the filenames. (Presumably it ought to be
possible to edit a file by dragging it onto a VED icon ... does that
work? But I digress.) E.g. dragging (the icon for) file "rhubarb.txt"
onto (the icon for) file "myprog.exe" runs myprog with a command
line of 'MYPROG.EXE RHUBARB.TXT'. Actually, that's not true, it uses
the full pathname, e.g.
    'C:\\PROGRA~1\\MYPROG.EXE C:\\MYDOCU~1\\RHUBARB.TXT'

As far as I can tell, up until Windows ME, the command-line used the
old 8.3 DOS filenames, even though the GUI shows longer filenames. In
Windows ME and Windows 2000 this has changed, so that
the new "command line" the very same program receives would be,
    '"C:\\Program Files\\myprog.exe" "C:\\My Documents\\rhubarb.txt"'

i.e. it gets quoted pathnames (in double quotes). (The single quotes
are pop string quotes which I've inserted in the faint hope of making
my post to popforum clearer.)

Anyway, the point of all this, is that you might just conceivably
want to parse the ved command line in a similar way, at least as an
option.

I suppose it is too late to swap the roles of single and double
quotes in the pop11 language, but if we were designing it now, I
suspect we would use double quotes as string quotes.

How about this, as a new lexical syntax proposal (somewhat tongue-in
cheek, since no one will take it seriously):

OLD
'this is a string'
"word"
'c' ;;; a character

NEW
"this is a string"
'word
'c' ;;; a character

Note that word quote is an *un* matched single quote. The single quote
for quoting words is, of course, lisp-like. And quite unambiguous, I
think.

Some more examples of the putative new syntax,
  'this\ is\ a\ word
  'this\ is\ two\ words'.
  "this\ is\ a\ string". ;;; followed by a dot
  'c'-> foo; assigning a character to foo
  'c' -> foo; assigning a character to foo
  'c '-> foo; a syntax error
  'c-> foo; assigning a word to foo
  '+ -> foo; assigning a word to foo
  '+-> foo; a syntax error
  '+'-> foo; assigning a character to foo
  '+-> ->foo; assigning a word to foo

Jonathan



Sun, 26 Oct 2003 21:27:11 GMT  
 Editing filenames with spaces


Quote:
> I suppose it is too late to swap the roles of single and double
> quotes in the pop11 language, but if we were designing it now, I
> suspect we would use double quotes as string quotes.

In my descended-from-Pop language Pepper I did indeed eventually
swop the quotes round. (An interesting rebootstrapping problem it was,
too.)

Quote:
> How about this, as a new lexical syntax proposal (somewhat tongue-in
> cheek, since no one will take it seriously):

> OLD
> 'this is a string'
> "word"
> 'c' ;;; a character

> NEW
> "this is a string"
> 'word
> 'c' ;;; a character

I chose double-quotes for "strings", single-quotes for 'a' character,
and back-quotes for `words`.

Quote:
> Note that word quote is an *un* matched single quote. The single quote
> for quoting words is, of course, lisp-like. And quite unambiguous, I
> think.

Is ['c'd] a List(Char, Char) or a List(Word,Word)?

Actually I lied about the back-quotes. Pepper back-quotes enclose *any
number* of words, eg 'two words' or 'three little boys'.

Actually that was still a lie. PBQs quote [] lists and {} vectors too
(which are not self-quoting in Pepper).  

Jonathan's examples become:

Quote:
>  'this\ is\ a\ word

    `\"this is a word"`

(strings are self-quoting in backquotes; backslashing them converts
them into words).

Quote:
>  'this\ is\ two\ words'.

`\"this is two words" .`  ;;; I think that's what you meant.

Quote:
>  "this\ is\ a\ string". ;;; followed by a dot

"this is a string".

Quote:
>  'c'-> foo; assigning a character to foo

No change.

Quote:
>  'c '-> foo; a syntax error

No change (but see below).

Quote:
>  'c-> foo; assigning a word to foo

`c` -> foo;

Quote:
>  '+ -> foo; assigning a word to foo

`+` -> foo;

Quote:
>  '+-> foo; a syntax error

Ditto. Note that

    `+- -> foo;

is an unterminated quote context, which will eat tokens until the matching
backquote or end-of-file. This is a design decision I'm not entirely happy
with.

Quote:
>  '+'-> foo; assigning a character to foo

Ditto.

Quote:
>  '+-> ->foo; assigning a word to foo

`+->` -> foo;

In Spice (a language Steve and I have co-developed and Whose Status Is
Under Review), character quotes may quote *arbitrarily many* characters,
and evaluate to all of those characters in sequence, ie

    'burble'
is
    'b', 'u', 'r', 'b', 'l', 'e'

(Thus the difference between double quotes and single quotes is that the
double quotes are "stronger" and force all the characters together into
a single lump. We did seriously consider abandoning the distinction
between strings and words, in both Pepper and Spice, but decided that
it's pragmatically useful. The current Pepper implementation is such that
a Word looks just like a String to all String operations; I mean, it
*really* looks like a String, not that there's code which says, oh, it's
a word, get the string part. The next-in-dictionary link comes *before*
the key-and-length, not after).

--
Chris "designer ... jeans? no, *languages*." Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Sun, 26 Oct 2003 22:10:20 GMT  
 Editing filenames with spaces

Quote:


>> I suppose it is too late to swap the roles of single and double
>> quotes in the pop11 language, but if we were designing it now, I
>> suspect we would use double quotes as string quotes.

>In my descended-from-Pop language Pepper I did indeed eventually
>swop the quotes round. (An interesting rebootstrapping problem it was,
>too.)

I won't address all the points you raise (lack of time) but I'll reply
to some of them.

Quote:
>> How about this, as a new lexical syntax proposal (somewhat tongue-in
>> cheek, since no one will take it seriously):

(snip)

Quote:
>> "this is a string"
>> 'word
>> 'c' ;;; a character
>Is ['c'd] a List(Char, Char) or a List(Word,Word)?

An interesting question. You are right that it is necessary to think
about the effect of such a change on all parts of the language.

If, as I'd assumed, the change only applied to tokenisation (as
done by -incharitem-) then ['c'd] would be lexically parsed into
four tokens, bra, char, word, ket, i.e. the above would be the
same as in the existing pop11: [`c`d], which is the same as
putting, "[", `c`, "d", "]" on the front of proglist (uing
existing syntax).

So the answer to your question would be: neither, it's
 List(Char, Word).

Or, since there isn't a Char type in pop11, it would actually
be the same as [99 d]. (Since 99 is the ascii code for lowercase c.)

This might not be what we would want.

The effect of ['c 'd] would be similar to what happens now if we
have unwanted double quotes, e.g. what does
  ["c"d]=>
print? It's actually a list of length four. Similarly ['c 'd] would
(with no other changes) be a list of length four, because "[" and "]"
implicitly quote tokens which are words, but not other tokens.

With a single character mark for quoting words, it might make sense
to *not* have lists quoted in this way, i.e. we no longer need
decorated brackets "[%" and "%]" for unquoting.

But all the commas that are necessary are ugly. Is there a middle
ground?

  if line matches [== i think i ??text you] then
      [perhaps you think we ^^text each other?]=>

is nicer than

  [% "perhaps", "you", "think", "we", text.dl, "each", "other" %]=>

but

  ['perhaps 'you 'think 'we text.dl 'each 'other '?]=>

is almost bearable. All that makes it different from a [% ... %] list
is that I'm assuming commas are not necssary. After all, in a
stack-based language, why ever have missing separator errors?

How would the semantics of pop11 be changed if, whenever there would
have been a missing separator error, we assume a comma? We do not
need to do away with commas, they may be useful to disambiguate some
situations, but why *require* separators? Are they useful for
anything?

Quote:
>Actually I lied about the back-quotes. Pepper back-quotes enclose *any
>number* of words, eg 'two words' or 'three little boys'.

Seems a reasonable extension. Is it useful?

Quote:
>Actually that was still a lie. PBQs quote [] lists and {} vectors too
>(which are not self-quoting in Pepper).  

If they are not self-quoting, what does it mean if they are
not quoted? Do you mean the default is like [% ... %]?

(snip)

Quote:
>>  'this\ is\ two\ words'.

>`\"this is two words" .`  ;;; I think that's what you meant.

Yes, that's what I meant.

(snip)

Quote:
>In Spice (a language Steve and I have co-developed and Whose Status Is
>Under Review), character quotes may quote *arbitrarily many* characters,
>and evaluate to all of those characters in sequence, ie

>    'burble'
>is
>    'b', 'u', 'r', 'b', 'l', 'e'

If you have separate character quotes, it is more usual (isn't it?) to
treat a multi-character sequence as packing the characters into a
single variable, e.g. in existing pop11 (not Spice or Pepper) I would
expect,
  'foo'
to be a 3 character string, I would expect
  `foo`
if it made sense, to be the same as
  16:666F6F
or maybe
  16:6F6F66

(for anyone who hasn't guessed, the characters `f` and `o` are
represented by their ascii codes of 102 and 111, which in hexadecimal
are 66 and 6F.)

So, although this is not (yet?) allowed in pop11,
  `foo`=>
ought to print
  ** 6713199
or to print
  ** 7303014

[Digression: why doesn't pop11 allow lower case letters in hexadecimal
constants?]

If we want all the characters of 'teardrop' on the stack, we can do
  'teardrop'.explode
or
  explode('teardrop')

and if you don't like "explode" and want something short, define "^^"
as an explode operator:
  ^^'teardrop'

then (excuse the rapid switching between pop11 and neopop syntax),
  ['perhaps 'you 'think 'we ^^text 'each 'other]=>

would also work.

(snip)

Quote:
>it's pragmatically useful. The current Pepper implementation is such that
>a Word looks just like a String to all String operations; I mean, it
>*really* looks like a String, not that there's code which says, oh, it's
>a word, get the string part. The next-in-dictionary link comes *before*
>the key-and-length, not after).

This is sensible. I wonder how much code would break in poplog if this
change were made? Presumably only fast access procedures of the wrong
type? (I.e. if you used fast_subscrv to access a string, it would
break, but fast string or word accessing system procedures would be
updated along with the change in internal representation, and would
not break.)

Making such a change in poplog cannot be impossibly difficult. John
Gibson made bigger representational changes at various stages in the
evolution of poplog, for example when he implemented sections. But
how much (if any?) existing code would actually break?

And are there any disadvantages?

Jonathan

--
(Trying a new news server) Jonathan L Cunningham



Tue, 28 Oct 2003 00:29:22 GMT  
 Editing filenames with spaces


Quote:



>>> I suppose it is too late to swap the roles of single and double
>>> quotes in the pop11 language, but if we were designing it now, I
>>> suspect we would use double quotes as string quotes.

>>In my descended-from-Pop language Pepper I did indeed eventually
>>swop the quotes round. (An interesting rebootstrapping problem it was,
>>too.)

> I won't address all the points you raise (lack of time) but I'll reply
> to some of them.

OK.

Quote:
>>Is ['c'd] a List(Char, Char) or a List(Word,Word)?

> An interesting question. You are right that it is necessary to think
> about the effect of such a change on all parts of the language.

> If, as I'd assumed, the change only applied to tokenisation (as
> done by -incharitem-) then ['c'd] would be lexically parsed into
> four tokens, bra, char, word, ket, i.e. the above would be the
> same as in the existing pop11: [`c`d], which is the same as
> putting, "[", `c`, "d", "]" on the front of proglist (uing
> existing syntax).

Aha. I'd assumed that the 'c' would be recognised by the lexer; now
I see that you've make ' a piece of syntax. OK, I don't think I like
it, but it looks like a consistent revision.

Quote:
> So the answer to your question would be: neither, it's
>  List(Char, Word).

> Or, since there isn't a Char type in pop11, it would actually
> be the same as [99 d]. (Since 99 is the ascii code for lowercase c.)

Er ... I forgot that (too much Spice), but please interpret Char as
"integer type representing characters"!

Quote:

> This might not be what we would want.
> With a single character mark for quoting words, it might make sense
> to *not* have lists quoted in this way, i.e. we no longer need
> decorated brackets "[%" and "%]" for unquoting.

(as in Pepper)

Quote:
> But all the commas that are necessary are ugly. Is there a middle
> ground?

I distinguished quoted and unquoted lists/vectors in Pepper; the quoted
ones don't need commas. Originally I was much more purist, but *writing*
Pepper code cured me of this, at least with respect to list/vector syntax.

Quote:
>   if line matches [== i think i ??text you] then
>       [perhaps you think we ^^text each other?]=>

Leaving aside for the moment that current Pepper doesn't have matches,
nor such free use of `valof`,

    `[== i think i ??text you]`
    `[perhaps you think we ^^text each other?]`

are the equivalent lists. (Yes, ^^ does list splicing. Also in unquoted
context you can do thinks like [x, y, z | somelist] to precatenate x,
y, and z onto somelist.)

Quote:
> is almost bearable. All that makes it different from a [% ... %] list
> is that I'm assuming commas are not necssary. After all, in a
> stack-based language, why ever have missing separator errors?

Defence.

Quote:
>>Actually I lied about the back-quotes. Pepper back-quotes enclose *any
>>number* of words, eg 'two words' or 'three little boys'.

> Seems a reasonable extension. Is it useful?

Oh yes ... because of the following revealed lie.

Quote:
>>Actually that was still a lie. PBQs quote [] lists and {} vectors too
>>(which are not self-quoting in Pepper).  

> If they are not self-quoting, what does it mean if they are
> not quoted? Do you mean the default is like [% ... %]?

Yes. It seems to work well in "practice" (ie the Pepper compiler and the
various bits of code that I write in Pepper to do sundry data hacking
and HTML generation).

Quote:
>>In Spice (a language Steve and I have co-developed and Whose Status Is
>>Under Review), character quotes may quote *arbitrarily many* characters,
>>and evaluate to all of those characters in sequence, ie

>>    'burble'
>>is
>>    'b', 'u', 'r', 'b', 'l', 'e'

> If you have separate character quotes, it is more usual (isn't it?) to
> treat a multi-character sequence as packing the characters into a
> single variable, e.g. in existing pop11 (not Spice or Pepper) I would
> expect,
>   'foo'
> to be a 3 character string, I would expect
>   `foo`
> if it made sense, to be the same as
>   16:666F6F
> or maybe
>   16:6F6F66

Ulgh. How ... unpleasant. I can see that being the case in C extensions,
but the "multiple values" approach seems much more in the Pop spirit.
(Incidentally, Spice characters are supposed to be 16-bit Unicode, not
ascii).

Quote:
> [Digression: why doesn't pop11 allow lower case letters in hexadecimal
> constants?]

Yes. Stupid, isn't it. I fixed *that* one in Pepper.

Quote:
> If we want all the characters of 'teardrop' on the stack, we can do
>   'teardrop'.explode
> or
>   explode('teardrop')

> and if you don't like "explode" and want something short, define "^^"
> as an explode operator:
>   ^^'teardrop'

The Spice operator for this is "...", so you can write

    "a string"...

to explode the string "at run-time". 'a string' does this at compile-time
(and, of course, in quoted contexts: contrast

    `[some '-=09506!!' characters]`
and
    `[some % "-=09506!!".explode % characters]`
or
    [`some`, "-=9506!!".explode, `characters`]

Quote:
>>it's pragmatically useful. The current Pepper implementation is such that
>>a Word looks just like a String to all String operations; I mean, it
>>*really* looks like a String, not that there's code which says, oh, it's
>>a word, get the string part. The next-in-dictionary link comes *before*
>>the key-and-length, not after).

> This is sensible. I wonder how much code would break in poplog if this
> change were made?

I suspect lots of it, in obscure places.

Quote:
> And are there any disadvantages?

Yes.

It makes garbage collection more difficult. For example, a Cheney-style
GC needs to be able to do a linear sweep along moved objects, and to be
able to identify the type of the object given its start. This will cause
problems in the current Pepper implementation when I write the GC (ahem).
It causes problems in the Spice GC because my Spice implementation plays
the same trick with procedures: the "external reference table" comes
before the key. The Spice implementation handles this by planting a
special "skip forward N slots" value in front of moved procedures.

So words pay a hidden extra slot overhead, or you arrange that all strings
have an unused slot so that they're store-compatible.

--
Chris "thought about this lots" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Tue, 28 Oct 2003 15:33:15 GMT  
 Editing filenames with spaces

--------------12A04B55EAED5774523FF7CE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Two comments on Aaron's suggestion:

1) I don't use <enter> ved file1 file2, but I do find multiple files on the
shell command line useful , such as
        % ved *.pl
I don't know whether this uses the same mechanism, but if it does, any
change should take account.

2) More seriously, I refer you to ref vedprocs, line 134ff. Ved's treatment
of filenames with spaces in them is to create a pseudo-buffer instead of
opening a real file.  There doesn't appear to be any way to disable this
(since someone seems to think 'sensible' filenames would never have spaces
in them :-) ), so it would rather scupper Aaron's plan. Personally I'd be
very happy to see this 'feature' removed or at least made controllable.
Apart from the general principle of not making unnecessary arbitrary
assumptions about filenames, it is a real pain for poplog under windows (Ok
so I appear to be the *only* windows user on this list, since no-one
responded to my earlier message :-) ). It  makes it awkward to install
poplog in the 'standard' windows place for applications (C:\Program Files\),
because it means you can't edit files in the poplog tree (such as
$popsys/init.p, or the whole of poplocal if you want to put it in the same
area).  Argh!

Roger


Quote:
> [To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

> Some time ago (1993 I think) a decision was taken to make ved treat an
> argument with spaces as a request to read in multiple files.

> So,

>    ENTER ved my report

> makes Ved attempt to read in a file called "my" and a file called
> "report".

> However since then it has become increasingly common for file stores for
> use on unix and on windows/NT to be integrated. E.g. in this school
> all users get the same login directory whether they are using PCs
> running NT or using machines running solaris, linux, etc. Thus files
> created on any of the systems are accessible on the others.

> This makes the current behaviour of Ved intolerable, and as far
> as I can tell there is no facility for turning it off.

> Has anyone found a way to disable this?

> Does anyone ever use the ability to give Ved an argument with spaces?
> (I have known about it for a long time, but have never found it
> of any use.)

> I am inclined to find and comment out the code that breaks up
> vedargument if it contains spaces, or control it with a new
> global variable, e.g.

>     ved_multi_edit

> with default value false.

> Comments? Suggestions?

> There may be other utilities in pop-11 that will not work if file or
> directory names contain spaces. I have not checked sys_file_match
> for instance.

> Aaron
> ====
> Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
> School of Computer Science, The University of Birmingham, B15 2TT, UK

> PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
> FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html

--------------12A04B55EAED5774523FF7CE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Two</tt> comments on Aaron's suggestion:
<p>1) I don't use &lt;enter> ved file1 file2, but I do find multiple files
on the shell command line useful , such as
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; % ved *.pl
<br>I don't know whether this uses the same mechanism, but if it does,
any change should take account.
<p>2) More seriously, I refer you to ref vedprocs, line 134ff. Ved's treatment
of filenames with spaces in them is to create a pseudo-buffer instead of
opening a real file.&nbsp; There doesn't appear to be any way to disable
this (since someone seems to think 'sensible' filenames would never have
spaces in them :-) ), so it would rather scupper Aaron's plan. Personally
I'd be very happy to see this 'feature' removed or at least made controllable.
Apart from the general principle of not making unnecessary arbitrary assumptions
about filenames, it is a real pain for poplog under windows (Ok so I appear
to be the *only* windows user on this list, since no-one responded to my
earlier message :-) ). It&nbsp; makes it awkward to install poplog in the
'standard' windows place for applications (C:\Program Files\), because
it means you can't edit files in the poplog tree (such as $popsys/init.p,
or the whole of poplocal if you want to put it in the same area).&nbsp;
Argh!
<p>Roger
<br>&nbsp;

<blockquote TYPE=CITE>[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
<p>Some time ago (1993 I think) a decision was taken to make ved treat
an
<br>argument with spaces as a request to read in multiple files.
<p>So,
<p>&nbsp;&nbsp; ENTER ved my report
<p>makes Ved attempt to read in a file called "my" and a file called
<br>"report".
<p>However since then it has become increasingly common for file stores
for
<br>use on unix and on windows/NT to be integrated. E.g. in this school
<br>all users get the same login directory whether they are using PCs
<br>running NT or using machines running solaris, linux, etc. Thus files
<br>created on any of the systems are accessible on the others.
<p>This makes the current behaviour of Ved intolerable, and as far
<br>as I can tell there is no facility for turning it off.
<p>Has anyone found a way to disable this?
<p>Does anyone ever use the ability to give Ved an argument with spaces?
<br>(I have known about it for a long time, but have never found it
<br>of any use.)
<p>I am inclined to find and comment out the code that breaks up
<br>vedargument if it contains spaces, or control it with a new
<br>global variable, e.g.
<p>&nbsp;&nbsp;&nbsp; ved_multi_edit
<p>with default value false.
<p>Comments? Suggestions?
<p>There may be other utilities in pop-11 that will not work if file or
<br>directory names contain spaces. I have not checked sys_file_match
<br>for instance.
<p>Aaron
<br>====
<br>Aaron Sloman, ( <a href="http://www.cs.bham.ac.uk/~axs/">http://www.cs.bham.ac.uk/~axs/</a>
)
<br>School of Computer Science, The University of Birmingham, B15 2TT,
UK

<br>PAPERS: <a href="http://www.cs.bham.ac.uk/research/cogaff/">http://www.cs.bham.ac.uk/research/cogaff/</a>
<br>FREE TOOLS: <a href="http://www.cs.bham.ac.uk/research/poplog/freepoplog.html">http://www.cs.bham.ac.uk/research/poplog/freepoplog.html</a></blockquote>
</html>

--------------12A04B55EAED5774523FF7CE--



Tue, 28 Oct 2003 17:28:27 GMT  
 Editing filenames with spaces
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

I have been reading (skimming) the recent discussion with interest,
knowing well that anything written by Jonathan or Chris is likely to be
interesting and useful.

However I have a few meta-comments on the discussion.

(a) If the suggestions currently being discussed were implemented, so
much would break both in the system and in user libraries that I think
it is better to think of them as proposals for a new language (spice?),
not proposals for changes to Pop-11, especially as I believe it would be
very difficult to write programs to convert *automatically* all existing
code that depends on the old syntax into the new syntax. (In part that's
because of the power of Pop-11 to use macros and syntax words whose
operation cannot be statically inferred, since they can depend on
previous run-time events.)

(b) [For information only] Pop-11 already has mechanisms for dealing
with two types of representations for characters.

    1. There's the standard ASCII representation as an 8-bit integer
       as described in HELP ASCII and REF DATA (see line 182ff).
       Pop-11 strings by default are packed 8-bit vectors. Word
       records include strings as their representation of the
       corresponding character sequence.
        (See subscrw, word_string, etc. in REF WORDS

    2. There are also "display strings", which are used in Ved/Xved
       to implement a wider variety of visible formats for characters,
       e.g. bold, italic, underlined. These are "dstrings".
       These use 24 bit integers where the bottom 8 bits represent ascii
       values and the top 8 bits represent the display format.
       The other bits are not used yet (I think).
       See REF DATA/dstring and REF STRINGS/dstring

      [REF STRINGS also mentions vedstrings, which can be used to
       associate arbitrary pop-11 items with a location in a string.
       (This is used for the very dangerous mechanism that allows a
        mouse click or keyboard action in any location in an XVed text
        buffer to activate an arbitrary procedure. This should NEVER
        happen without a warning being displayed allowing the user to
        cancel the operation!
        See REF VEDPROCS, REF VEDCOMMS. Search for 'action'
        (This generalises the much older "hypertext" mechanism in
        Ved described in HELP vedgetsysfile which required an EXPLICIT
        "ESC h" keyboard action.))]

(c) My own feeling is that although the recent discussions of syntax for
various types of data-constructing expressions are interesting and
could, if they had occurred around 1970, have led to much better syntax
for the pop family, they are far less important for real users than
other "semantic" issues like the availability of powerful libraries that
extend what you can easily do, the availability of new debugging and
development tools, etc.

For example, the extension of list syntax to allow "^" and "^^" to be
used and permitting matched pairs of percents %....% anywhere within
a list (or vector expression) to switch between quoted and unquoted
items (both introduced by Steve Hardy) made a really big difference to
the ability of non-expert programmers to write bug-free easily
maintainable list processing programs (even if using "^^" in the middle
of a list can often be inefficient).

Likewise the provision of a list pattern matcher in the mid 1970s
(also designed by Steve Hardy) made an even bigger difference to the
ability of many programmers to write list processing programs that were
right first time, especially because segment variables ??<var> could
occur ANYWHERE in the list, which is unusual.

(There was a residual source of bugs due to the fact that the pattern
variables had to be global variables, until I introduced the "!" pattern
prefix a few years ago as an optional extra, to make pattern variables
lexically scoped. This is a downloadable extra, built into
the Birmingham startup.psv.)

When LIB FLAVOURS was first introduced many people found it also made a
huge difference to their ability to produce complex software systems.

But it had many problems due to its poor integration with the pop-11
programming style, and worse, because it allowed method selection to be
based only on ONE method argument (because of the 'message sending'
ideology for method invocation fashionable at the time). However it was
used successfully in a number of projects including commercial projects
I think.

LIB OBJECTCLASS (designed by Steve Leach) for me was a HUGE improvement
and most of the programming I have done in the last 5 years would have
been either impossible or far more difficult without it. (I would have
had to re-invent most of it.) I suspect that many things done in the
early 1990s to build X-based interface tools in poplog (See REF POP_UI)
and also Ved/Xved could have been done much better if objectlass had
existed earlier.

(Steve objects to the current method invocation strategy used in the
latest implementation of objectclass, which was done when Sussex/ISL
took it over. However it is easy to switch back to Steve's preferred
strategy, though that's not properly documented. At some point we should
decide which is best and change the default. I'll then have to change
lots of stuff in RCLIB which works only with the current default!)

Examples of other libraries that make a HUGE difference for particular
types of software development are

    John Gibson's socket library (e.g. without this I could not
        so easily have written a newsreader/poster package based
        on Ved)

    The X facilities built into Pop-11 which are actually very
        powerful, though very hard to use in their raw state if
        you have not read all the X manuals. (This is what made
        XVed possible for instance and the Pop_ui tools.)

    David Young's LIB popvision, which provides a lot of utilities
        (many written in C and linked externally) for image manipulation
        and display. Unfortunately the display facilities use colormaps
        and therefore still work only with 8 bit X systems, though
        Brian Logan has a temporary fix that works for 24 bits, but not
        yet 16 bit displays.)

    My RCLIB, based on Objectclass and the X facilities now makes it
        much easier than ever before to create control panels, multi-
        window displays with moving/mouse-selectable objects, sliders,
        buttons, dials, scrolling text sub-panels, pop-up menus, etc.

        Many student projects here in Birmingham would have been very
        much harder without this.

    Poprulebase (based on the pattern matcher and other list
        mechanisms) and Sim_agent (based on poprulebase and objectclass,
        now extended with sim_picagent based on RCLIB for linking
        simulations to displays).

    Jon Meyer's regular expression matcher for strings
        (See REF REGEXP) is potentially very useful but probably
        under-used because it was introduced at a time when very few
        people had access to new versions of pop-11
        (ISL were not able to continue the low prices for academics
        previously charged by Sussex.)

I suspect that some more recent tools that I have not fully understood,
e.g. Steve Leach's stuff on XML, and some libraries other people have
developed for dealing with html are potentially very important for real
applications.

See the utilities at www.poplog.org

There are many other things that would be very useful.

E.g. I suspect that if someone were to do the sort of thing David
Young has done for his image-manipulating and neural net C programs,
but in relation to the GNU scientific/maths library then we could have
in pop-11 something comparable to (more powerful than?) the
widely used matlab system.

Moreover Pop11+gsl would be totally free of charge with open source.

For details see

    http://sourceware.cygnus.com/gsl

    GSL is free. It is distributed under the terms of GPL
    It provides a collection of routines for numerical computing, all
    written in ANSI C, "to present a modern Applications Programming
    Interface (API) for C programmers, while allowing wrappers to be
    written for very high level languages."

I assume that would include pop-11!

The reference manual is browsable here:
    http://sources.redhat.com/gsl/ref/gsl-ref_toc.html

I counted about 380 entries referring to available
functions, categories of algorithms supported, etc. in the table of
contents.

So writing all the "wrappers" and brief pop-11 documentation would be
quite a big job, though not necessarily a very deep one. The resulting
system could be *enormously* useful for all sorts of interactive
development not now supported in Pop-11 because the poor collection of
mathematical facilities.

By comparison with "semantic" extensions of the above types, I believe
changes to the syntax of existing constructs are really of marginal
importance!

(Though interesting as examples of programming language design issues
for people designing a language from scratch.)

Is anyone interested in forming a collaborative project to provide
the gsl extension to pop-11???

Cheers.

Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html



Tue, 28 Oct 2003 19:10:42 GMT  
 Editing filenames with spaces

Quote:

> 2) More seriously, I refer you to ref vedprocs, line 134ff. Ved's treatment
> of filenames with spaces in them is to create a pseudo-buffer instead of
> opening a real file.  There doesn't appear to be any way to disable this
> (since someone seems to think 'sensible' filenames would never have spaces
> in them :-) ), so it would rather scupper Aaron's plan. Personally I'd be
> very happy to see this 'feature' removed or at least made controllable.
> Apart from the general principle of not making unnecessary arbitrary
> assumptions about filenames, it is a real pain for poplog under windows

Someone (Robert Duncan in fact, according to the revision history) seems
to have at least tried to address the problem, because the definition of
ved_ved in vdprocess.p contains (line 812)

#_IF DEF WIN32
        ;;; filenames can include spaces, so treat vedargument as a single
        ;;; file (and not as a workbuff -- see Is_file_name in "vdfiles.p")

Does this not work?  (I guess this question is addressed to Roger, if he
is the only Windows poplog user.)  If it does, then simply adopting the
#_IF DEF WIN32 clauses here and in Is_file_name should be pretty
straightforward.  (And ref vedprocs should be revised.)

A comment in the definition of Is_file_name notes that you still can't
create a new file in the current directory with a space in its name
using ved_ved, but that doesn't sound nearly as serious as Aaron's
original problem.

Steve



Tue, 28 Oct 2003 21:07:10 GMT  
 Editing filenames with spaces
Hmm, thanks for finding this Steve (I have the poplog sources but have never got
round to installing them).
The actual test is for a space in the filename and an empty directory part which
is why it didn't work for me - I was using a full pathname.  I wonder why Rob did
it like that?

But anyway, I don't see why this should be a windows-specific fix. The point is
that restrictions on the form of filenames (or tokens) are/should be restrictions
on the shell/compiler reading them in, not the underlying objects themselves...

Roger

Quote:


> > 2) More seriously, I refer you to ref vedprocs, line 134ff. Ved's treatment
> > of filenames with spaces in them is to create a pseudo-buffer instead of
> > opening a real file.  There doesn't appear to be any way to disable this
> > (since someone seems to think 'sensible' filenames would never have spaces
> > in them :-) ), so it would rather scupper Aaron's plan. Personally I'd be
> > very happy to see this 'feature' removed or at least made controllable.
> > Apart from the general principle of not making unnecessary arbitrary
> > assumptions about filenames, it is a real pain for poplog under windows

> Someone (Robert Duncan in fact, according to the revision history) seems
> to have at least tried to address the problem, because the definition of
> ved_ved in vdprocess.p contains (line 812)

> #_IF DEF WIN32
>         ;;; filenames can include spaces, so treat vedargument as a single
>         ;;; file (and not as a workbuff -- see Is_file_name in "vdfiles.p")

> Does this not work?  (I guess this question is addressed to Roger, if he
> is the only Windows poplog user.)  If it does, then simply adopting the
> #_IF DEF WIN32 clauses here and in Is_file_name should be pretty
> straightforward.  (And ref vedprocs should be revised.)

> A comment in the definition of Is_file_name notes that you still can't
> create a new file in the current directory with a space in its name
> using ved_ved, but that doesn't sound nearly as serious as Aaron's
> original problem.

> Steve



Tue, 28 Oct 2003 22:07:35 GMT  
 Editing filenames with spaces

Quote:

> The actual test is for a space in the filename and an empty directory part which
> is why it didn't work for me - I was using a full pathname.  I wonder why Rob did
> it like that?

#_IF DEF WIN32
        ;;; filenames can include spaces, so treat vedargument as a single
        ;;; file (and not as a workbuff -- see Is_file_name in "vdfiles.p")
        if strmember(`\s`, vedargument)
        and sys_fname_path(vedargument) = nullstring
        then
                '.\\' dir_>< vedargument -> vedargument;
        endif;

It looks to me as if '.\' gets tacked on the front if there is a space
in the name and no directory part, and vedargument gets passed through
untouched otherwise.  The lines you quoted from ref vedprocs suggest
that a space *anywhere* in the pathname - directory part or file part -
will do you in, so I don't see how tacking the '.\' on the front will
help.  But then I haven't tracked down where the actions described in
ref vedprocs are performed.

Steve



Wed, 29 Oct 2003 00:48:23 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Spaces in Directory Names - Long Filenames

2. Opening a file on NT with a space in the filename

3. filenames w/ spaces a

4. filenames w/ spaces as args

5. filenames w/ spaces as ar

6. filenames w/ spaces as a

7. Filenames with Spaces

8. spaces in filenames

9. removing spaces from front and end of filenames

10. arguments(filenames) with spaces in them

11. Spaces in filename

12. space in filename

 

 
Powered by phpBB® Forum Software