> Edit source, specifically /sys/src/cmd/acme/wind.c^winsettag1.
>
> Look for where "Look" is added to the tag, and extend to whatever
> you wish. Easy.
Thanks a lot :)
Ruda
>
> it's done this way, i believe, to ensure that two rc shells running in
> the same namespaces do not step all over each others' environments. if
> you simply run 'rfork e' before you experiment with all those
> functions you won't see the empty files anywhere.
Sorry, but I don't understand...
> > it's done this way, i believe, to ensure that two rc shells running in
> > the same namespaces do not step all over each others' environments. if
> > you simply run 'rfork e' before you experiment with all those
> > functions you won't see the empty files anywhere.
>
> Sorry, but I don't under
Here native = the carbon OS-X gui rewrite, not native plan 9. Sorry for the
confusion!
--underspecified
On Wed, Oct 8, 2008 at 8:44 PM, erik quanstrom <[EMAIL PROTECTED]>wrote:
> > > 1) Are you sure you are running the new, native gui version? Your hg
> info
> > > suggests this is the case, but I
Hi there,
while there I want to mention that the resizing event from os X
does not seem to trigger a redraw of sam/acme. Am I right?
Kind regards,
Christian
--
You may use my gpg key for replies:
pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
pgp47cWXkBeNG.pgp
Description: PGP s
> Hello,
>I tried to install plan 9 on virtual pc and succedded. But, once
> i boot through plan 9 errors are coming.
> Attached the screen shot of the error.
the plan 9 ide driver apparently disagrees with virtual pc.
this isn't a fossil or venti problem.
unfortunately, i have no acces
Greetings,
I have been using a scroll wheel in p9p's acme on OS-X for some time without
any problems.
This raises a few questions about your setup:
1) Are you sure you are running the new, native gui version? Your hg info
suggests this is the case, but I want to make sure you recompiled the
binari
* underspecified <[EMAIL PROTECTED]> [081008 14:44]:
> It should show a transparent outline while you drag and redraw when you let
> go.What happens when you try to resize the window?
>
The window size changes but the content does not get redrawn leading to a
window like this:
http://pestilenz.o
* underspecified <[EMAIL PROTECTED]> [081008 14:14]:
>
> In principle the scroll wheel and touchpad should be sending the same events
> when scrolling,
> so if it fails with just the mouse, I think the problem is more likely to be
> specific to that mouse.
> Have you tried any other mice? My Lenov
> > 1) Are you sure you are running the new, native gui version? Your hg info
> > suggests this is the case, but I want to make sure you recompiled the
> > binaries between now and then.
> Yes I do run native and I rebuild everything just to make sure.
i'm confused. you send a gdb backtrace from
Dear List,
I am experiencing a strange behaviour of p9p acme: When I scroll
with the mouse wheel acme just hangs. The console prints acme: bad
rpc tag 2 (no one waiting on that tag)
attaching with gdb says:
0x9526a1b5 in read$UNIX2003 ()
(gdb) bt
#0 0x9526a1b5 in read$UNIX2003 ()
#1 0x89e7
* underspecified <[EMAIL PROTECTED]> [081008 13:26]:
> 1) Are you sure you are running the new, native gui version? Your hg info
> suggests this is the case, but I want to make sure you recompiled the
> binaries between now and then.
Yes I do run native and I rebuild everything just to make sure.
It should show a transparent outline while you drag and redraw when you let
go.What happens when you try to resize the window?
--underspecified
On Wed, Oct 8, 2008 at 9:28 PM, Christian Kellermann <
[EMAIL PROTECTED]> wrote:
> Hi there,
>
> while there I want to mention that the resizing event f
Greetings,
On Wed, Oct 8, 2008 at 8:40 PM, Christian Kellermann <
[EMAIL PROTECTED]> wrote:
> * underspecified <[EMAIL PROTECTED]> [081008 13:26]:
> > 1) Are you sure you are running the new, native gui version? Your hg info
> > suggests this is the case, but I want to make sure you recompiled the
Hello,
is that an intention that acme does not recognize " (or "", not so sure
about '''chk' ) to be a name of a valid file? At least " and "" seems to me
to be a valid file name, but clicking on it with button 3 in acme doesn't
work --- file is not opened. Only explicit use of Get opens it.
Tha
It's the plumber that decides. If you want those characters to be understood as
file name characters in general - and you really don't, whatever you think now;
consider what happens when you click on "includefile.h" - then change the
plumbing rules.
-rob
On Wed, Oct 8, 2008 at 9:35 AM, Rudolf Syk
2008/10/8 Rob Pike <[EMAIL PROTECTED]>
> It's the plumber that decides. If you want those characters to be
> understood as
> file name characters in general - and you really don't, whatever you think
> now;
> consider what happens when you click on "includefile.h" - then change the
> plumbing rule
Insert a plumbing rule before the usual one that considers those
characters part of filenames. Now you can plumb those scripts. When
it fails to find the file named "includefile.h" (with the quotes as
part of the filename), the plumber will move on to the next rule to
check for includefile.h (no
Hello,
I'd expect
window -hide rc -c 'label a_name; tail -f some_file'
would create a new hidden window (and so it does), run the tail command (and
so it does) and set the name for the hidden window to a_name.
The last thing seems to not happen (at least from the viewpoint of using the
button-3
On Oct 8, 2008, at 2:26 PM, Rudolf Sykora wrote:
Hello,
I'd expect
window -hide rc -c 'label a_name; tail -f some_file'
would create a new hidden window (and so it does), run the tail
command (and so it does) and set the name for the hidden window to
a_name.
The last thing seems to not h
see the window(1) man page regarding the -m option passed to the
command and what it does in this case. not to repeat everything here,
but it suffices to say that
window -m -hide rc -c 'label a_name; tail -f /sys/log/telnet'
works as expected.
note that -m must appear first in the argument list
On Oct 8, 2008, at 6:58 AM, Rudolf Sykora wrote:
So, if I continuously want to add and remove functions within one
shell (running hypothetically forever), do I have to 'manually'
delete those empty left-behind files? --- that is, not only use
fn name_that_I _don't_need
but also
rm /env/'fn#
So, if I continuously want to add and remove functions within one shell
>> (running hypothetically forever), do I have to 'manually' delete those empty
>> left-behind files? --- that is, not only use
>> fn name_that_I _don't_need
>> but also
>> rm /env/'fn#name_that_I _don't_need' ?
>>
>
> No.
>
window -hide rc -c 'label a_name; tail -f some_file'
>>
>>
> rc -c only runs the commands given and then terminates. When all the
> processes given to window terminates, the window closes. That's what's
> happening to you. Try this:
>
> window -hide 'label a_name; tail -f some_file; rc'
First, i
>
> Well... that's an answer, but not very constructive indeed. When do those
> files dissapear?
they don't. but it shouldn't be a problem.
there's no explicit limit. why don't you
sidestep the problem by using a space between
the fixed part and the path?
- erik
2008/10/8 andrey mirtchovski <[EMAIL PROTECTED]>
> see the window(1) man page regarding the -m option passed to the
> command and what it does in this case. not to repeat everything here,
> but it suffices to say that
>
> window -m -hide rc -c 'label a_name; tail -f /sys/log/telnet'
>
> works as
On Oct 8, 2008, at 2:52 PM, Rudolf Sykora wrote:
So, if I continuously want to add and remove functions within one
shell (running hypothetically forever), do I have to 'manually'
delete those empty left-behind files? --- that is, not only use
fn name_that_I _don't_need
but also
rm /env/'f
2008/10/8 Pietro Gagliardi <[EMAIL PROTECTED]>
> On Oct 8, 2008, at 2:52 PM, Rudolf Sykora wrote:
>
>
>>
>> So, if I continuously want to add and remove functions within one shell
>> (running hypothetically forever), do I have to 'manually' delete those empty
>> left-behind files? --- that is, not
2008/10/8 grai <[EMAIL PROTECTED]>
> Insert a plumbing rule before the usual one that considers those
> characters part of filenames. Now you can plumb those scripts. When
> it fails to find the file named "includefile.h" (with the quotes as
> part of the filename), the plumber will move on to t
I have tracked this down along with another OS X display problem.
I will push out the fix later today.
Russ
scratch my previous explanation. it is incorrect. looking through
rio's source code it appears that the cause is the supplied "rc -c"
argument to 'window'. the window command assumes that everything after
the switches is a command to be executed and actually prepends 'rc -c'
in front of your comman
while looking around for information on the RC strangeness i triggered
a bug with rio: if the last window on the "hidden" stack disappears
_while_ the third mouse button menu is opened, then upon attempting to
unhide the window without releasing the mouse button in between will
result in a read add
> * underspecified <[EMAIL PROTECTED]> [081008 14:44]:
>> It should show a transparent outline while you drag and redraw when you let
>> go.What happens when you try to resize the window?
>>
>
> The window size changes but the content does not get redrawn leading to a
> window like this:
> http://
On Wed, Oct 8, 2008 at 1:41 PM, Russ Cox <[EMAIL PROTECTED]> wrote:
> I have tracked this down along with another OS X display problem.
> I will push out the fix later today.
This fix and the resize fix is now in hg and cvs.
Russ
The fixes work very well. Thank you.
On Wed, Oct 8, 2008 at 5:05 PM, Russ Cox <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 8, 2008 at 1:41 PM, Russ Cox <[EMAIL PROTECTED]> wrote:
>> I have tracked this down along with another OS X display problem.
>> I will push out the fix later today.
>
> This fix a
35 matches
Mail list logo
