headers
John Yates | 1 Nov 20:01

Re: [st] a real (I think) feature request

On Sat, Oct 31, 2009 at 4:52 AM, John A. Grahor <jag <at> techma.com> wrote:
> I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
> line editing can happen locally and what one types is only sent to the tty
> when one hits return (or some other key).

Two decades ago I fell in love with Apollo Computer's solution to this
problem.  A terminal window was broken into two "panes":

1) an editable input pane
2) a read-only transcript pane

The two panes were separated by a full window horizontal line or rule.
 The input pane never shrank to less than one line but could also
steal lines from the transcript pane until it grew to a specified
fraction of the input window (typically 1/4).  The input pane had two
modes of operation with an icon on the title bar to indicating which
mode was in effect.  I cannot recall the actual names so let me just
call them "connected mode" and "disconnected mode".  In

In connected mode type ahead hung around in the input pane until a
program running in under that terminal window issued a read from
stdin.  When that happened a single line of input (i.e. up to a
newline) was passed from the input pane to the requesting program.
That input line disappeared from the input pane, the program's prompt
(if any) appeared in the transcript followed by the input line just
delivered.  In essence the input pane was simply a visible
representation of unconsumed type-ahead.

In disconnected mode type ahead input again hung around in the input
pane.  This time though when a program running in the terminal window
(Continue reading)

Permalink | Reply | 24 comments |
headers
hiro | 1 Nov 20:45

Re: [st] a real (I think) feature request

From the length of your description I would guess this solution would
be pretty complicated to implement.

On Sun, Nov 1, 2009 at 8:01 PM, John Yates <john <at> yates-sheets.org> wrote:
> On Sat, Oct 31, 2009 at 4:52 AM, John A. Grahor <jag <at> techma.com> wrote:
>> I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
>> line editing can happen locally and what one types is only sent to the tty
>> when one hits return (or some other key).
>
> Two decades ago I fell in love with Apollo Computer's solution to this
> problem.  A terminal window was broken into two "panes":
>
> 1) an editable input pane
> 2) a read-only transcript pane
>
> The two panes were separated by a full window horizontal line or rule.
>  The input pane never shrank to less than one line but could also
> steal lines from the transcript pane until it grew to a specified
> fraction of the input window (typically 1/4).  The input pane had two
> modes of operation with an icon on the title bar to indicating which
> mode was in effect.  I cannot recall the actual names so let me just
> call them "connected mode" and "disconnected mode".  In
>
> In connected mode type ahead hung around in the input pane until a
> program running in under that terminal window issued a read from
> stdin.  When that happened a single line of input (i.e. up to a
> newline) was passed from the input pane to the requesting program.
> That input line disappeared from the input pane, the program's prompt
> (if any) appeared in the transcript followed by the input line just
> delivered.  In essence the input pane was simply a visible
(Continue reading)

Permalink | Reply | 4 comments |
headers
Moritz Wilhelmy | 2 Nov 01:04
Picon
Favicon

Re: [surf] Bookmarks patch for 0.2

Would you please add it to the surf page in the suckless wiki?

On Fri, Oct 23, 2009 at 08:52:33PM +0200, Tadeusz Sośnierz wrote:
> On 23-10-2009 19:26:50, Julien Pecqueur wrote:
> > Le mardi 20 octobre 2009 à 02:44:53, Tadeusz Sośnierz a écrit :
> > > Hello,
> > > I wrote some patch for bookmark handling, attached. Everything is driven
> > > by the right-click menu. Sadly, I had no idea how to include some labels
> > > for the urls. Also, I'm rather beggining with C, so I'm sorry for any
> > > eye-stabbing stupidities you may encounter, and please report
> > > them to me.
> > > 
> > > Hope You'll like it.
> > 
> > I'd have the same idea few weeks ago and i wrote a very-simple bookmarks 
> > management implementation for surf (using dmenu). However, your idea of
> > displaying bookmarks list in a about:bookmarks page is smartest :)
> > 
> > > +void
> > > +addbookmark(Client *c, const Arg *arg) {
> > > +	char *bmark_uri;
> > > +	FILE *f;
> > > +	bmark_uri = geturi(c);
> > > +	f = fopen(bmarksfile, "a+");
> > > +	fprintf(f, "%s\n", geturi(c));
> > > +	fclose(f);
> > > +}
> > 
> > The pointer *bmark_uri is not used in the function.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nico Golde | 2 Nov 02:15
Picon
Favicon

Re: [surf] Bookmarks patch for 0.2

Hi,
* Tadeusz So??nierz <tadzikes <at> gmail.com> [2009-10-20 16:36]:
[...] 
> +showbmarks(Client *c, const Arg *arg) {
> +	/* I wonder if 4 kB is too much or not enough */
> +	char html[4096] = "";
> +	/* same here. time will tell */
> +	char uri[128];
> +	FILE *f;
> +	stop(c, NULL);
> +	f = fopen(bmarksfile, "r");
> +	while(fscanf(f, "%127s\n", uri) != EOF) {
> +		snprintf(&html[strlen(html)], sizeof(html) - strlen(html),
> +			"<a href='%s'>%s</a><br />", uri, uri);

You may want to html escape the uri, not?

Cheers
Nico
--

-- 
Nico Golde - http://www.ngolde.de - nion <at> jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.
Permalink | Reply | 2 comments |
headers
Tadeusz Sośnierz | 2 Nov 05:10
Picon
Gravatar

Re: [surf] Bookmarks patch for 0.2

On  2-11-2009 01:04:32, Moritz Wilhelmy wrote:
> Would you please add it to the surf page in the suckless wiki?

Sure. I'll make a fresh diff today, if there are no protests I'll be
glad to submit.

Regards,
Ted

> On Fri, Oct 23, 2009 at 08:52:33PM +0200, Tadeusz Sośnierz wrote:
> > On 23-10-2009 19:26:50, Julien Pecqueur wrote:
> > > Le mardi 20 octobre 2009 à 02:44:53, Tadeusz Sośnierz a écrit :
> > > > Hello,
> > > > I wrote some patch for bookmark handling, attached. Everything is driven
> > > > by the right-click menu. Sadly, I had no idea how to include some labels
> > > > for the urls. Also, I'm rather beggining with C, so I'm sorry for any
> > > > eye-stabbing stupidities you may encounter, and please report
> > > > them to me.
> > > > 
> > > > Hope You'll like it.
> > > 
> > > I'd have the same idea few weeks ago and i wrote a very-simple bookmarks 
> > > management implementation for surf (using dmenu). However, your idea of
> > > displaying bookmarks list in a about:bookmarks page is smartest :)
> > > 
> > > > +void
> > > > +addbookmark(Client *c, const Arg *arg) {
> > > > +	char *bmark_uri;
> > > > +	FILE *f;
> > > > +	bmark_uri = geturi(c);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tadeusz Sośnierz | 2 Nov 05:17
Picon
Gravatar

Re: [surf] Bookmarks patch for 0.2

On  2-11-2009 02:15:25, Nico Golde wrote:
> Hi,
> * Tadeusz So??nierz <tadzikes <at> gmail.com> [2009-10-20 16:36]:
> [...] 
> > +showbmarks(Client *c, const Arg *arg) {
> > +	/* I wonder if 4 kB is too much or not enough */
> > +	char html[4096] = "";
> > +	/* same here. time will tell */
> > +	char uri[128];
> > +	FILE *f;
> > +	stop(c, NULL);
> > +	f = fopen(bmarksfile, "r");
> > +	while(fscanf(f, "%127s\n", uri) != EOF) {
> > +		snprintf(&html[strlen(html)], sizeof(html) - strlen(html),
> > +			"<a href='%s'>%s</a><br />", uri, uri);
> 
> You may want to html escape the uri, not?

Well, there are some security reasons, if that's what you mean. But
my tiny investigation (I mean, entering query string to google
containing html tags) showed that they become urlencoded by the app
itself, so it seems safe to me. If there's anything I don't know, please
let me know.

Regards,
Ted

--

-- 
===========================================================
()  ascii ribbon campaign - against html e-mail
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yuval Hager | 2 Nov 07:52
Favicon
Gravatar

multiple fonts in wmii

Hi there,

Can wmii support multiple fonts? This way if glyphs are not found in the 
first font, the next one is being searched.
I am looking for some functionality along the lines of 
http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#How_does_rxvt_unicode_choose_fonts
(yes, this link actually works).

Most fonts do not contain the glyphs for my native language, so I am ending 
up with blank squares instead. If I modify wmii font to one that contains 
native glyphs, the latin letters are just ugly..

OTOH, shouldn't fontconfig do this (select matching fonts by language) by 
default? it obviously is not the case in my setup, and I couldn't find any 
docs on how to make this work the way I expect it to.

--yuval
Permalink | Reply | 4 comments |
headers
Kris Maglione | 2 Nov 08:01
Picon

Re: multiple fonts in wmii

On Mon, Nov 02, 2009 at 08:52:39AM +0200, Yuval Hager wrote:
>Hi there,
>
>Can wmii support multiple fonts? This way if glyphs are not found in the
>first font, the next one is being searched.
>I am looking for some functionality along the lines of
>http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#How_does_rxvt_unicode_choose_fonts
>(yes, this link actually works).
>
>Most fonts do not contain the glyphs for my native language, so I am ending
>up with blank squares instead. If I modify wmii font to one that contains
>native glyphs, the latin letters are just ugly..
>
>OTOH, shouldn't fontconfig do this (select matching fonts by language) by
>default? it obviously is not the case in my setup, and I couldn't find any
>docs on how to make this work the way I expect it to.

wmii supports multiple fonts in exactly the same way as rxvt. 
Just list them separated by commas. If you want fontconfig, 
prefix the font string with xft:, otherwise you get regular X11 
fontsets, which have atrocious unicode support.

--

-- 
Kris Maglione

The tragedy of modern war is not so much that young men die but that
they die fighting each other, instead of their real enemies back home
in the capitals.
	--Edward Abbey
(Continue reading)

Permalink | Reply | 3 comments |
headers
Yuval Hager | 2 Nov 13:09
Favicon
Gravatar

Re: multiple fonts in wmii

On Monday 02 November 2009, Kris Maglione wrote:
> On Mon, Nov 02, 2009 at 08:52:39AM +0200, Yuval Hager wrote:
> >Hi there,
> >
> >Can wmii support multiple fonts? This way if glyphs are not found in the
> >first font, the next one is being searched.
> >I am looking for some functionality along the lines of
> >http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#How_
> >does_rxvt_unicode_choose_fonts (yes, this link actually works).
> >
> >Most fonts do not contain the glyphs for my native language, so I am
> > ending up with blank squares instead. If I modify wmii font to one that
> > contains native glyphs, the latin letters are just ugly..
> >
> >OTOH, shouldn't fontconfig do this (select matching fonts by language)
> > by default? it obviously is not the case in my setup, and I couldn't
> > find any docs on how to make this work the way I expect it to.
>
> wmii supports multiple fonts in exactly the same way as rxvt.
> Just list them separated by commas. If you want fontconfig,
> prefix the font string with xft:, otherwise you get regular X11
> fontsets, which have atrocious unicode support.

I've tried this, and it looks like it is not working. 
Running
$ wmiir xwrite /ctl font 'xft:Arial'
presents the Hebrew characters correctly (in windows title, and mpd status area), while
$ wmiir xwrite /ctl font 'xft:terminus-10'
presents just white boxes instead.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert C Corsaro | 2 Nov 16:15
Favicon

Re: [st] a real (I think) feature request

It reminds me of your typical IRC client.  transcript above and one line 
of command at the bottom.

hiro wrote:
> From the length of your description I would guess this solution would
> be pretty complicated to implement.
>
> On Sun, Nov 1, 2009 at 8:01 PM, John Yates <john <at> yates-sheets.org> wrote:
>   
>> On Sat, Oct 31, 2009 at 4:52 AM, John A. Grahor <jag <at> techma.com> wrote:
>>     
>>> I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where
>>> line editing can happen locally and what one types is only sent to the tty
>>> when one hits return (or some other key).
>>>       
>> Two decades ago I fell in love with Apollo Computer's solution to this
>> problem.  A terminal window was broken into two "panes":
>>
>> 1) an editable input pane
>> 2) a read-only transcript pane
>>
>> The two panes were separated by a full window horizontal line or rule.
>>  The input pane never shrank to less than one line but could also
>> steal lines from the transcript pane until it grew to a specified
>> fraction of the input window (typically 1/4).  The input pane had two
>> modes of operation with an icon on the title bar to indicating which
>> mode was in effect.  I cannot recall the actual names so let me just
>> call them "connected mode" and "disconnected mode".  In
>>
>> In connected mode type ahead hung around in the input pane until a
(Continue reading)

Permalink | Reply | 3 comments |

Gmane