On 2016-04-22, at 02:10, John P. Hartmann wrote: > Under the bonnet, XEDIT support for BFS are pipelines to load and write the > file into the existing > So close! If only similar hooks could be used with an arbitrary pipeline as input! What does it use as FN FT FM? Or has XEDIT itself been enhanced to recognize BFS paths for Save? I used to play games with aliases and/or GLOBALV, qualifying by ring member, such that Save might have a different semantic for each member. I imagine that for a BFS member it might be a macro piping back to BFS.
> structure. If you want a width larger than the default, you must specify so > at the initial XEDIT > WIDTH is an archaic, stopgap, PITA. It should be eliminated, or at least made flexible so if I Insert or GET a larger line WIDTH adapts automatically. I recall struggling long ago to automate WIDTH in PROFILE XEDIT; worst case for a new file of unrecognized FT. If I choose WIDTH too small, GET fails; if I choose WIDTH too large, storage is exhausted. I suspect this is less a problem modern larger storage. Does XEDIT use 31-bit storage? 64? > command. Also note that the ring can contain a mix of BFS and normal files. > I recall long ago customizing FILELIST, RDRLIST, PEEK, XEDIT, ... all to run in the same ring (why isn't that the default option?). But I used unsupported interfaces, and my customizations have largely been Overcome by Events. I haven't tried the BROWSE stage. I fear it might be at best reinventing the wheel. Unless it has kevlar-belted radial tires. But unless it has the usual XEDIT facilities such as ALL and search-within-bounds, it may be more like reinventing the flat tire. I use BROWSE MODULE only for data that are too big to view with XEDIT. Then it's infuriating -- I can't even do a search backwards. Is there a BFSLIST utility? How does it deal with case-sensitivity? -- gil
