On Wed, Oct 8, 2008 at 9:45 AM, [EMAIL PROTECTED] wrote:
Edit source, specifically /sys/src/cmd/acme/wind.c^winsettag1.
snip
Easy.
Right up until you want to pull in upstream bugfixes.
-sqweek
Edit source, specifically /sys/src/cmd/acme/wind.c^winsettag1.
snip
Easy.
Right up until you want to pull in upstream bugfixes.
there have only been 5 changes to this file since 2002.
diff isn't that hard to use, is it?
- erik
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
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 rules.
-rob
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
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 the next
* Rudolf Sykora [EMAIL PROTECTED] [081007 14:02]:
Hello,
I am sorry for repeating my question, but noone has told me a solution and I
have not found one for myself yet.
Is there a way 'Edit' appeared in an acme tag line automatically (and for
any new window)?
Just add it in the source
2008/9/10 Pietro Gagliardi [EMAIL PROTECTED]:
On Sep 10, 2008, at 10:04 AM, hugo rivera wrote:
I think double-clicking on the box to the left of the column information
line thingy should do it.
You mean the small purple box left of the column tag? probably I am
doing something wrong, but when
On Thu, Sep 11, 2008 at 12:24 PM, sqweek [EMAIL PROTECTED] wrote:
I think Pietro was making a suggestion, rather than explaining the
current state of affairs.
-sqweek
i think your doubts benefit more than mine do.
2008/9/11 sqweek [EMAIL PROTECTED]:
I think Pietro was making a suggestion, rather than explaining the
current state of affairs.
Oops.
Well, I think is a good suggestion.
:-)
2008/9/10 erik quanstrom [EMAIL PROTECTED]:
no. and you're right, it would be a great feature but it would take
quite a bit of rethinking.
Sorry to hear that.
not in the same way. you want to b3 :-/text/ (no quotes)
in the tag. i'm sure there are other ways to do this.
Great, thanks.
On Wed, Sep 10, 2008 at 7:48 PM, Pietro Gagliardi [EMAIL PROTECTED] wrote:
I think double-clicking on the box to the left of the column information
line thingy should do it.
erm. you really could have tried this first.
it doesn't take much, you know.
for the record, i once had a go at
[EMAIL PROTECTED] (sqweek) writes:
On Thu, Aug 21, 2008 at 5:06 PM, Paul Donnelly
[EMAIL PROTECTED] wrote:
The bear is indentation, since to make it work out it's
necessary to use a fixed-width font (something I'd rather not do) and
adjust it by hand, which needs to happen more often and by
On Thu, Aug 21, 2008 at 2:06 AM, Paul Donnelly
[EMAIL PROTECTED]wrote:
[EMAIL PROTECTED] (Gorka Guardiola) writes:
On Wed, Aug 20, 2008 at 7:42 PM, David Leimbach [EMAIL PROTECTED]
wrote:
The only thing I'd miss in Acme vs emacs then, most likely, for
lisp-like
languages is
One of the central tenets of Plan 9 is that everything is a file. So
all file based activities are really, really easy.
Most OO programming appears to follow a more DB oriented style (at
least those with horrendous packaging/module mechanisms). That files
are used to store your programs appears
On Wed, Aug 20, 2008 at 11:12 PM, Wendell xe [EMAIL PROTECTED] wrote:
My nutshell evaluation of Acme is that it is for systems-level coding in C on
modest-sized projects. It seems very well designed for that purpose but
quickly becomes awkward as you move away. It is definitely not suited to
On Wed, Aug 20, 2008 at 10:14 AM, sqweek [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 11:12 PM, Wendell xe [EMAIL PROTECTED] wrote:
My nutshell evaluation of Acme is that it is for systems-level coding in
C on modest-sized projects. It seems very well designed for that purpose but
On Wed, Aug 20, 2008 at 7:42 PM, David Leimbach [EMAIL PROTECTED] wrote:
The only thing I'd miss in Acme vs emacs then, most likely, for lisp-like
languages is paren-matching.
And I'd miss it dearly.
Double click on the paren selects the area enclosed by the matching paren.
--
-
Date: Sun Apr 27 19:42:09 EDT 2008
Is it intentional that the 2-1 chord behaves differently in external
programs? For example, I have a guide file with 0,.d in it. If I
2-1 on Edit in a normal text window in Acme, it does what I'd
expect: delete from start of file to current selection. In
Edit ,x/.*/g/$/a/foo/
shouldn't this append foo after every line?
Edit ,x/.*\n/g/\n/a/foo
or
Edit ,x/.*\n/g/$/a/foo
where the latter gives a little hint about what the code might be doing
On Jul 17, 2008, at 6:03 AM, roger peppe wrote:
Edit ,x/.*/g/$/a/foo/
shouldn't this append foo after every line?
sam gives slightly different behaviour here
(but still questionable) - it appends foo after
every empty line.
is this actually a bug, or have i misunderstood the
way that
[EMAIL PROTECTED] wrote:
I dislike this idea. I think for most people, most of the time,
the lines acme's working with will fit well within the width of
a window. Yeah, I bet most of us have run into longer lines at
times, but the interface is optimized for the common case. I
wouldn't like to
Hi,
The scrollbar handle will always change it's length when moving
through the files.
Why isn't the length based on the total lines of the file?
because that would require reading the whole file.
- erik
That makes perfect sense, thanks.
I love the way how the text at the clicked point will just move to the top.
Perhaps I am being stupid, but why doesn't left-clicking cause that
point to move down to the bottom?
I never know where in the text I will end up when I'm scrolling upwards...
--
hiro
The left click is basically doing the opposite of the right click - it moves
the top line to the position of the click. That way a left click after a
right click restores the previous view of the file. (There may be some small
distortion due to lines longer than the width of the window but that
On 7/3/08, Martin Neubauer [EMAIL PROTECTED] wrote:
The left click is basically doing the opposite of the right click - it moves
the top line to the position of the click. That way a left click after a
right click restores the previous view of the file. (There may be some small
distortion
What do you think about my idea of moving the line to the bottom instead?
bad idea. to be honest i don't think the precise semantics of the scroll
distance are very important, but it is important that left and right
buttons are near inverses of each other, which means that when
scrolling down,
I dislike this idea. I think for most people, most of the time,
the lines acme's working with will fit well within the width of
a window. Yeah, I bet most of us have run into longer lines at
times, but the interface is optimized for the common case. I
wouldn't like to see that go.
Having the undo
On 7/3/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I dislike this idea. I think for most people, most of the time,
the lines acme's working with will fit well within the width of
a window. Yeah, I bet most of us have run into longer lines at
times, but the interface is optimized for the
bad idea. to be honest i don't think the precise semantics of the scroll
distance are very important, but it is important that left and right
buttons are near inverses of each other, which means that when
scrolling down, you can easily get back to the last view you saw
without moving the
Thanks a lot for your help, I am not sure what I was doing, but now
everything is ok.
Saludos
Hugo
/lib/keyboard (or $PLAN9/lib/keyboard in your case).
Hi guys:
I hope this is not a very silly question, but I do not remember how to
write unicode characters in Acme. I am using plan 9 from user space on
FreeBSD.
As far as I remember, it was something like Alt+X SOME_NUMBER, but
this does
http://swtch.com/plan9port/man/man7/keyboard.html
On Wed, May 14, 2008 at 8:44 AM, hugo rivera [EMAIL PROTECTED] wrote:
Hi guys:
I hope this is not a very silly question, but I do not remember how to
write unicode characters in Acme. I am using plan 9 from user space on
FreeBSD.
As far
keyboard(7) (keyboard(6) on plan 9). lots of shortcuts for
specific things, but alt+x+1234 should produce glyphs.
see also $PLAN9/lib/keyboard.
---BeginMessage---
Hi guys:
I hope this is not a very silly question, but I do not remember how to
write unicode characters in Acme. I am using plan 9
It is perhaps worth pointing out that in Plan 9
(and in Plan 9 from User Space), Alt is just a=20
key like any other, not a modifier like Shift:
you don't have to hold it down through the entire
sequence.
Thanks. I never noticed that. Since I need Alt-*
a lot that is very helpful to know.
I understand that a speadsheet would solve the situation, but...
Vim has always been sufficient for the task I described, having that one
particular feature.
If acme were able of the same, it would suffice me as well...
Ruda
On 24/03/2008, Robert Raschke [EMAIL PROTECTED] wrote:
On 3/23/08,
On Tue, Mar 25, 2008 at 3:33 PM, Rudolf Sykora [EMAIL PROTECTED] wrote:
I understand that a speadsheet would solve the situation, but...
Vim has always been sufficient for the task I described, having that one
particular feature.
If acme were able of the same, it would suffice me as well...
Well, [EMAIL PROTECTED] could definitely be a choice. But, doesn't it go
against the
basic philosophy ... ??!
the response here usually follows these steps:
(1) at most a mild suggestion to try using the system somewhat as intended
(2) ignoring it
this is in contrast to affirmative-action
I haven't said that to use Vim is bad. Vim is my most favourite editor. I am
myself happy to have Vim around in Plan9 (and am not alone for sure).
Nonetheless, it's bad to not have an alternative which would follow the
system's principles. Please read all I mentioned before. Vim does not follow
Thanks, I'll read it and see if it can be of help
R
On 25/03/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hola,
i think you can take other approaches to solve your problems instead of
using vim, or making acme behave like vim.
see what others have done with acme:
have you considered using sam to break each line into multiple lines
and then rejoining. e.g. if you have a | separated record structure, you
could do something like:
,x/^.*\n/ {
s/\|/\n/g
s/\n/\n\n/
}
edit the fields, then rejoin before writing it back:
,y/\n\n/ x/\n/ c/|/
,x/\n\n/ c/\n/
Is there any way how to sensibly edit a file with long lines (eg. a table
with many fields, like /sys/lib/lp/devices) using acme/sam? What I miss is a
way to not wrap long lines when I need to concentrate
on the different fields and a whole
single line is a true representative of an item (a
Thanks for the answer, although it did not please me... :(
(In Vim, you only have to do :set nowrap and you are done... From time to
time I find this rather useful.)
Ruda
it's unreasonable for the lp configuration file to need lines 200 characters
long.
i would think it would make more sense
501 - 543 of 543 matches
Mail list logo
