Re: [9fans] sam label and rio snarf buffer
> I've to think about the plumber and the the named pipe to be able
> to plumb a file and bring to the front a sam instance if it has
> the file open, moving the file's window to the front with dot set at
> the address, if one is given.
I have this:
diff -u /sys/src/cmd/samterm/plan9.c ./plan9.c
--- /sys/src/cmd/samterm/plan9.cMon Jun 21 18:44:27 2021
+++ ./plan9.c Mon Jun 21 19:51:51 2021
@@ -215,6 +215,11 @@
which = i;
send(c, );
}
+ if((n = open("/dev/wctl", OWRITE)) >= 0){
+ write(n, "current\n", 8);
+ write(n, "unhide\n", 7);
+ close(n);
+ }
}
}
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M619b1c2110ae7f980ce9f1c9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
In case someone was playing with this, last patch was really naive
(and buggy). I tried different approaches while learning more about
how the two parts of the editor interact with each other and after
some back-and-forths it's working now.
I enabled again the menu item when samriosnarf is defined,
so the internal buffer can be used as a temporal storage.
I've to think about the plumber and the the named pipe to be able
to plumb a file and bring to the front a sam instance if it has
the file open, moving the file's window to the front with dot set at
the address, if one is given.
If you don't set samriosnarf you wont notice anything, this
patch doesn't change the normal behavior of sam.
I've to revise the code and test it more, but I don't like the idea
of a buggy patch floting on the list, even if no one is using it.
Regards,
adr.
--- sys/src/cmd/samterm/main.c Sat Jun 26 21:12:44 2021
+++ /sys/src/cmd/samterm/main.c Fri Jul 23 21:49:09 2021
@@ -1,5 +1,6 @@
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,7 @@
long modified = 0; /* strange lookahead for menus */
char hostlock = 1;
char hasunlocked = 0;
+char riosnarf = 0;
int maxtab = 8;
int autoindent;
@@ -35,6 +37,8 @@
Rectangle r;
Flayer *nwhich;
+ if(getenv("samriosnarf"))
+ riosnarf = 1;
getscreen(argc, argv);
iconinit();
initio();
@@ -250,10 +254,27 @@
snarf(Text *t, int w)
{
Flayer *l = >l[w];
+ int fd;
+ int n;
+ long p;
if(l->p1>l->p0){
snarflen = l->p1-l->p0;
- outTsll(Tsnarf, t->tag, l->p0, l->p1);
+ if(riosnarf){
+ if((fd=open("/dev/snarf", OWRITE)) < 0){
+ fprint(2, "samterm:snarf: can't open /dev/snarf for
writing");
+ return;
+ }
+ t = l->user1;
+ for(p=l->p0; pp1; p+=n){
+ n = l->p1-p>BLOCKSIZE? BLOCKSIZE : l->p1-p;
+ rload(>rasp, p, p+n, nil);
+ if(fprint(fd, "%.*S", n, scratch) < 0)
+ break;
+ }
+ close(fd);
+ }else
+ outTsll(Tsnarf, t->tag, l->p0, l->p1);
}
}
@@ -280,14 +301,75 @@
hcheck(t->tag);
}
+#define HSIZE 3
+#define MAXCSTR (DATASIZE-HSIZE-sizeof(int)-2*sizeof(long)) /* Max cstring
allowed by outTsllS */
void
paste(Text *t, int w)
{
- if(snarflen){
- cut(t, w, 0, 0);
- t->lock++;
- outTsl(Tpaste, t->tag, t->l[w].p0);
+ Rune *rstr, *rp;
+ Biobuf *bp;
+ int rstrsize;
+ int len; /* size in bytes of current rstr converted to UTF */
+ int m, n; /* n: number of runes already on rstr */
+ long offset, last;
+
+ if(!riosnarf){
+ if(snarflen){
+ cut(t, w, 0, 0);
+ t->lock++;
+ outTsllS(Tpaste, t->tag, 0, t->l[w].p0, L"");
+ }
+ return;
+ }
+ rstrsize = MAXCSTR;
+ if((bp=Bopen("/dev/snarf", OREAD)) == 0){
+ fprint(2, "samterm:paste: can't open /dev/snarf");
+ return;
+ }
+ offset = t->l[w].p0;
+ rp = rstr = alloc(rstrsize);
+ len = n = 0;
+ if((last=Bgetrune(bp)) <= 0)
+ return;
+ cut(t, w, 0, 0);
+ while((long)(*rp=last?last:Bgetrune(bp)) > 0){
+ last = 0;
+ if((len+=runelen(*rp)) > MAXCSTR){
+ Bungetrune(bp);
+ --n;
+ last = *(rp-1); /* can't Bungetrune again... */
+ *(rp-1) = 0;
+ if(t->lock == 0)
+ t->lock = 1;
+ if(Bgetrune(bp) <= 0){ /* Last chunk */
+ outTsllS(Tpaste, t->tag, t->l[w].p0, offset,
rstr);
+ break;
+ }
+ Bungetrune(bp);
+ outTsllS(Tpaste, t->tag, -1, offset, rstr);
+ offset += n;
+ rp = rstr;
+ n = len = 0;
+ continue;
+ }
+ if(RUNESIZE*(rp-rstr+2) > rstrsize){
+ m = rp - rstr;
+ rstr = realloc(rstr, rstrsize+=MAXCSTR);
+ if(!rstr)
+ panic("realloc");
+ rp = rstr + m;
+ }
+ ++rp;
+ ++n;
+ }
+ *rp = 0;
+ if(*rstr){
+ if(t->lock == 0)
+ t->lock = 1;
+ outTsllS(Tpaste, t->tag, t->l[w].p0,
Re: [9fans] sam label and rio snarf buffer
> Will cooperation come back to rescue this planet, or will it be too > late? I suppose if one omits human exceptionalism, Nature will triumph > by default. But it's going to hurt like hell! works on my 9front -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M1e9c386b7efe346683c407ea Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
On 7/21/21, adr via 9fans <9fans@9fans.net> wrote: >> You'll need to reinvent (or change, at least) plumbing if you want >> multiple editors, be it one >> per file or one per project. > > I'll make sam create allways the named pipe with the pid in the > name so I can identify wich one I want to talk with. > > There are a lot of possibilities. > That's what I like about controversial suggestions: they trigger the flow of information that may otherwise remain hidden. And dialogue to replace unchallenged, dead-end monologues that never saw the light of day (or peer review). I blame the 1980s for creating the exceptionalist culture that is rapidly destroying all stable ecosystems, but I think its roots go quite a bit further back, ever since competition for some perhaps not all that obscure reasons, replaced teamwork. Will cooperation come back to rescue this planet, or will it be too late? I suppose if one omits human exceptionalism, Nature will triumph by default. But it's going to hurt like hell! Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-Mfedf06641e73d54516081309 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
You'll need to reinvent (or change, at least) plumbing if you want multiple editors, be it one per file or one per project. I'll make sam create allways the named pipe with the pid in the name so I can identify wich one I want to talk with. There are a lot of possibilities. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M7399c12fd69d9910d71248d0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
Quoth Stuart Morrow : > You'll need to reinvent (or change, at least) plumbing if you want > multiple editors, be it one > per file or one per project. You can also run a nested plumber in a subrio, which is what I do for work -- I open a rio with a plumber that has work-specific rules, along with a sshfs and a vt; the unix commands that get run over ssh get the plumb output rewritten to sshfs paths that I can open on 9front. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M309e489ef51b0b77ea4497ab Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
> Have you seen ptrap(4) in 9front? Yes, Ori mentioned it in 0intro, the Plan 9 podcast -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M9582240260310aa609582fc5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
On Tue, Jul 20, 2021, at 10:27 PM, Stuart Morrow wrote: > You'll need to reinvent (or change, at least) plumbing if you want > multiple editors, be it one > per file or one per project. I used to use one plumber per project window, where a project window was either an instance of acme or a subrio. It worked well for me. When I was setting it up, someone suggested some clever plumbing rules instead, but I couldn't understand them at the time. Their suggestion is in this list's archives, but I can't remember how many years ago it was. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-Mcf34fecc46674557471d7ce6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
Have you seen ptrap(4) in 9front? tir. 20. jul. 2021 23.30 skrev Stuart Morrow : > You'll need to reinvent (or change, at least) plumbing if you want > multiple editors, be it one > per file or one per project. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M0756140797d033bb2089cae1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
On Tue, 20 Jul 2021, adr via 9fans wrote: buffer. I can't identify the file I'm editing using winwatch or the menu when hidden, and so on. Oh my... is "I can identify..." and I wanted to make things clear... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M034dd1bb3ac6bfaa1b679c71 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
You'll need to reinvent (or change, at least) plumbing if you want multiple editors, be it one per file or one per project. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-Mfc05d179050f78c209653739 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
I don't want to add noise to the list, but it seem that some people are confused about what I'm doing with this. You start in rio to work in some project. You open sam in a big window because all the files will be opened inside. You start opening files and changing the focus using the menu, and the text selected in one window can be pasted easily in another, beautiful. Now you need to open a pdf, for example with the specification of some image format. Beautiful? no, horrible, because now you have to arrange the big sam window and the windows inside of it so you can keep editing some file while the pdf is at sight. And now you have to consult some information in a website related to other file you are working on, and you want to copy a selection to sam... well you have the idea. The problem (for me, it seem other people are happy with this) is the design concept of one editor to edit all the files, recreating another windows environment inside the windows environment you already have, rio. This patch allows you to use sam in another way, without breaking nor changing anything when used "normally". I have plumbing rules to open a file with a new instance of sam with the label "sam /file/path". I can exchange selections easily with other sam instances or other applications that use rio's snarf buffer. I can't identify the file I'm editing using winwatch or the menu when hidden, and so on. I hope all is clear now. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M22f1441f0287b54e19a5f95c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
I just realized there was another (earlier) thread on this with similar questions; didn't mean to be badgering you. On Tue, Jul 20, 2021 at 12:23 PM adr via 9fans <9fans@9fans.net> wrote: > > On Tue, 20 Jul 2021, Skip Tavakkolian wrote: > > what problem did this fix for you? > > > > all the changes seem like bad ideas for general use; e.g. would hiding > > a sam window show a name other than sam? > > This is for using different instances of sam... Is not for your > "general use". I've explained this before. Anyway, this add the > posibility of changing the label, it not forces you to do it. If > you don't use the -l option, don't define samriosnarf and you are > unaware of the 'l' command, sam will behave exactly the same, you > will not notice, that's something I really like of this patch. > > > regarding snarf, couldn't you get what you need by manipulating the > > namespace with an rc script wrapper? > > I really don't know what on earth are you talking about. Sam's > snarf buffer is an internal buffer (defined in sam/mesg.c), it > isn't presented in a file system. But even if that were the case, > it will not work if samter and sam were in different machines. > > Regards, > adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-M6620b2860c771cffecbb594d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
On Tue, 20 Jul 2021, Skip Tavakkolian wrote: what problem did this fix for you? all the changes seem like bad ideas for general use; e.g. would hiding a sam window show a name other than sam? This is for using different instances of sam... Is not for your "general use". I've explained this before. Anyway, this add the posibility of changing the label, it not forces you to do it. If you don't use the -l option, don't define samriosnarf and you are unaware of the 'l' command, sam will behave exactly the same, you will not notice, that's something I really like of this patch. regarding snarf, couldn't you get what you need by manipulating the namespace with an rc script wrapper? I really don't know what on earth are you talking about. Sam's snarf buffer is an internal buffer (defined in sam/mesg.c), it isn't presented in a file system. But even if that were the case, it will not work if samter and sam were in different machines. Regards, adr. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-Mad061fe322c02394d56d259c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam label and rio snarf buffer
what problem did this fix for you? all the changes seem like bad ideas for general use; e.g. would hiding a sam window show a name other than sam? regarding snarf, couldn't you get what you need by manipulating the namespace with an rc script wrapper? > I changed the last patch so sam wont change the label at startup. > I added a new option '-l' to set the label, it's more flexible and > doesn't chage the normal behavior. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-Mc696e0847b9795d2e068383b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] sam label and rio snarf buffer
Hi,
I changed the last patch so sam wont change the label at startup.
I added a new option '-l' to set the label, it's more flexible and
doesn't chage the normal behavior. If samriosnarf is in /env, sam will
use rio's snarf buffer instead of the internal one.
This patch should apply to 9legacy, if you use the lab's distro
apply first sam-wheel.diff from 9legacy.
Regards,
adr.
--- sys/src/cmd/sam/cmd.c Wed Apr 24 00:06:05 2013
+++ /sys/src/cmd/sam/cmd.c Sun Jul 18 18:23:06 2021
@@ -17,6 +17,7 @@
'g',0, 1, 0, 'p',aDot, 0, 0, g_cmd,
'i',1, 0, 0, 0, aDot, 0, 0, i_cmd,
'k',0, 0, 0, 0, aDot, 0, 0, k_cmd,
+ 'l',0, 0, 0, 0, aNo,0, linex, l_cmd,
'm',0, 0, 1, 0, aDot, 0, 0, m_cmd,
'n',0, 0, 0, 0, aNo,0, 0, n_cmd,
'p',0, 0, 0, 0, aDot, 0, 0, p_cmd,
--- sys/src/cmd/sam/mesg.c Fri Jan 12 17:02:55 2007
+++ /sys/src/cmd/sam/mesg.c Tue Jul 20 12:10:43 2021
@@ -1,4 +1,5 @@
#include "sam.h"
+#include
Headerh;
uchar indata[DATASIZE];
@@ -348,17 +349,26 @@
f = whichfile(inshort());
p0 = inlong();
journaln(0, p0);
- for(l=0; lBLOCKSIZE)
- m = BLOCKSIZE;
- bufread(, l, genbuf, m);
- loginsert(f, p0, tmprstr(genbuf, m)->s, m);
+
+ if(*(char*)inp != 0){
+ str = tmpcstr((char*)inp);
+ m = str->n;
+ loginsert(f, p0, str->s, m);
+ freetmpstr(str);
+ }else{
+ for(l=0; lBLOCKSIZE)
+ m = BLOCKSIZE;
+ bufread(, l, genbuf, m);
+ loginsert(f, p0, tmprstr(genbuf, m)->s, m);
+ }
+ m = snarfbuf.nc;
}
if(fileupdate(f, FALSE, TRUE))
seq++;
f->dot.r.p1 = p0;
- f->dot.r.p2 = p0+snarfbuf.nc;
+ f->dot.r.p2 = p0+m;
f->tdot.p1 = -1; /* force telldot to tell (arguably a BUG) */
telldot(f);
outTs(Hunlockfile, f->tag);
--- sys/src/cmd/sam/mesg.h Fri Mar 18 22:33:33 2005
+++ /sys/src/cmd/sam/mesg.h Sun Jul 18 18:25:36 2021
@@ -67,6 +67,7 @@
Hack, /* request acknowledgement */
Hexit,
Hplumb, /* return plumb message to terminal - version 1 */
+ Hlabel, /* change /dev/label */
HMAX,
}Hmesg;
typedef struct Header{
--- sys/src/cmd/sam/parse.h Thu Oct 27 15:36:34 2005
+++ /sys/src/cmd/sam/parse.hSat Jul 17 19:55:51 2021
@@ -55,13 +55,12 @@
int nl_cmd(File*, Cmd*), a_cmd(File*, Cmd*), b_cmd(File*, Cmd*);
int c_cmd(File*, Cmd*), cd_cmd(File*, Cmd*), d_cmd(File*, Cmd*);
-intD_cmd(File*, Cmd*), e_cmd(File*, Cmd*);
-intf_cmd(File*, Cmd*), g_cmd(File*, Cmd*), i_cmd(File*, Cmd*);
-intk_cmd(File*, Cmd*), m_cmd(File*, Cmd*), n_cmd(File*, Cmd*);
-intp_cmd(File*, Cmd*), q_cmd(File*, Cmd*);
-ints_cmd(File*, Cmd*), u_cmd(File*, Cmd*), w_cmd(File*, Cmd*);
-intx_cmd(File*, Cmd*), X_cmd(File*, Cmd*), plan9_cmd(File*, Cmd*);
-inteq_cmd(File*, Cmd*);
+intD_cmd(File*, Cmd*), e_cmd(File*, Cmd*), f_cmd(File*, Cmd*);
+intg_cmd(File*, Cmd*), i_cmd(File*, Cmd*), k_cmd(File*, Cmd*);
+intl_cmd(File*, Cmd*), m_cmd(File*, Cmd*), n_cmd(File*, Cmd*);
+intp_cmd(File*, Cmd*), q_cmd(File*, Cmd*), s_cmd(File*, Cmd*);
+intu_cmd(File*, Cmd*), w_cmd(File*, Cmd*), x_cmd(File*, Cmd*);
+intX_cmd(File*, Cmd*), plan9_cmd(File*, Cmd*), eq_cmd(File*, Cmd*);
String*getregexp(int);
--- sys/src/cmd/sam/sam.c Tue Dec 6 17:05:45 2005
+++ /sys/src/cmd/sam/sam.c Tue Jul 20 12:23:28 2021
@@ -25,6 +25,7 @@
int termlocked;
char *samterm = SAMTERM;
char *rsamname = RSAM;
+char *samtermlabel = nil;
File *lastfile;
Disk *disk;
long seq;
@@ -57,6 +58,9 @@
case 's':
rsamname = EARGF(usage());
break;
+ case 'l':
+ samtermlabel = EARGF(usage());
+ break;
default:
dprint("sam: unknown flag %c\n", ARGC());
usage();
@@ -82,6 +86,11 @@
startup(machine, Rflag, termargs, argv);
notify(notifyf);
getcurwd();
+ if(samtermlabel){
+ t=tmpcstr(samtermlabel);
+ outTS(Hlabel, t);
+ freetmpstr(t);
+ }
if(argc>0){
for(i=0; iunread)
load(f);
if(f==0 && (cp->addr==0 || cp->addr->type!='"') &&
- !utfrune("bBnqUXY!", cp->cmdc) &&
+
