Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2019.04.02 10:52:34 +0200:
> On Mon, Apr 01 2019, Jeremie Courreges-Anglas wrote:
> > On Mon, Jun 18 2018, "Todd C. Miller" wrote:
> >> On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
> >>
> >>> On Sun, 17 Jun 2018 17:29:31 +0200, Mark
On Tue, Apr 02, 2019 at 11:39:05AM -0400, Andras Farkas wrote:
> $ set -o vi
> $ true^[^L #redraws the line
> $ true
>
> vi uses the escape or ^[ character to go into command mode from insert mode
Ooooh... I blatantly tried ^L without ESC in vi mode, of course that
won't work.
Yup, sorry for the
On Tue, Apr 02, 2019 at 05:31:22PM +0200, Klemens Nanni wrote:
> On Tue, Apr 02, 2019 at 05:20:19PM +0200, Theo Buehler wrote:
> > Yes, ^L is printed in vi insert mode. The text you quoted is about vi
> > command mode which does indeed redraw the current line on ^L. I agree
> > with jca, no need
On Tue, Apr 2, 2019 at 11:32 AM Klemens Nanni wrote:
> On Tue, Apr 02, 2019 at 05:20:19PM +0200, Theo Buehler wrote:
> > Yes, ^L is printed in vi insert mode. The text you quoted is about vi
> > command mode which does indeed redraw the current line on ^L. I agree
> > with jca, no need for a
On Tue, Apr 02, 2019 at 05:20:19PM +0200, Theo Buehler wrote:
> Yes, ^L is printed in vi insert mode. The text you quoted is about vi
> command mode which does indeed redraw the current line on ^L. I agree
> with jca, no need for a change there.
I'm confused. Without jca's diff, I did the
On Tue, Apr 02, 2019 at 05:04:42PM +0200, Klemens Nanni wrote:
> On Tue, Apr 02, 2019 at 04:56:58PM +0200, Jeremie Courreges-Anglas wrote:
> > The diff changes only the emacs mode. I don't think sh.1 needs to be
> > adjusted given that the paragraph you quote is about vi mode.
> Sure it's just
On Tue, Apr 02, 2019 at 10:52:34AM +0200, Jeremie Courreges-Anglas wrote:
> On Mon, Apr 01 2019, Jeremie Courreges-Anglas wrote:
> > On Mon, Jun 18 2018, "Todd C. Miller" wrote:
> >> On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
> >>
> >>> On Sun, 17 Jun 2018 17:29:31 +0200, Mark
On Tue, Apr 02, 2019 at 04:56:58PM +0200, Jeremie Courreges-Anglas wrote:
> The diff changes only the emacs mode. I don't think sh.1 needs to be
> adjusted given that the paragraph you quote is about vi mode.
Sure it's just emacs mode. But for sh(1), ^L does print a literal "^L"
in vi mode; in
On Tue, Apr 02 2019, Klemens Nanni wrote:
> On Tue, Apr 02, 2019 at 10:52:34AM +0200, Jeremie Courreges-Anglas wrote:
>> So here's a diff. oks/nays?
> OK with the one mention in sh(1) adjusted as well:
>
> There are two modes, interactive and command. The shell starts in
> interactive
On Tue, Apr 02, 2019 at 10:52:34AM +0200, Jeremie Courreges-Anglas wrote:
> So here's a diff. oks/nays?
OK with the one mention in sh(1) adjusted as well:
There are two modes, interactive and command. The shell starts in
interactive mode. In this mode text is entered normally. A
On Mon, Apr 01 2019, Jeremie Courreges-Anglas wrote:
> On Mon, Jun 18 2018, "Todd C. Miller" wrote:
>> On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
>>
>>> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
>>>
>>> > If folks indeed think that this is a must-have feature,
On 2019 Apr 01 (Mon) at 09:53:31 -0600 (-0600), Todd C. Miller wrote:
:On Mon, 01 Apr 2019 16:52:34 +0200, Jeremie Courreges-Anglas wrote:
:
:> Since this went in, I'm using it on my machines instead of a bind -m hack.
:>
:> Can't we make ^L=clear-screen the default behavior? I don't see
:>
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2019.04.01 16:52:34 +0200:
> On Mon, Jun 18 2018, "Todd C. Miller" wrote:
> > On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
> >
> >> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
> >>
> >> > If folks indeed think that this is a
On Mon, Apr 01, 2019 at 09:53:31AM -0600, Todd C. Miller wrote:
> AT ksh doesn't clear the screen by default on ^L. Other shells
> like bash, zsh, and tcsh do. I don't object to making it the default
> but as I'm not a ksh user I'll defer to those who are.
Although I'm mostly using ksh in Vi
On Mon, 01 Apr 2019 16:52:34 +0200, Jeremie Courreges-Anglas wrote:
> Since this went in, I'm using it on my machines instead of a bind -m hack.
>
> Can't we make ^L=clear-screen the default behavior? I don't see
> discussions about that.
AT ksh doesn't clear the screen by default on ^L. Other
On Mon, Jun 18 2018, "Todd C. Miller" wrote:
> On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
>
>> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
>>
>> > If folks indeed think that this is a must-have feature, this is
>> > certainly a better approach. I wonder though if
Never mind, should have finished reading the later emails ;-).
On Sat, Jun 23, 2018 at 09:02:24AM +0100, Nicholas Marriott wrote:
> Hi
>
> I think you should not pass NULL to the last argument of setupterm(),
> from terminfo(3):
>
> If errret is null, setupterm prints an error message upon
Hi
I think you should not pass NULL to the last argument of setupterm(),
from terminfo(3):
If errret is null, setupterm prints an error message upon finding an
error and exits.
On Sat, Jun 16, 2018 at 04:16:57PM -0600, Todd C. Miller wrote:
> On Sat, 16 Jun 2018 14:50:40
On June 18, 2018 11:00:00 PM GMT+02:00, Richard Procter
wrote:
>
>On 6/06/2018, at 10:20 AM, Alexander Hall wrote:
>
>> This adds a "clear-screen" editing command to the emacs editing mode.
>> This is the same name as bash and zsh uses, and then I stopped
>looking.
>>
>> Thoughts? OK?
>
On 6/06/2018, at 10:20 AM, Alexander Hall wrote:
> This adds a "clear-screen" editing command to the emacs editing mode.
> This is the same name as bash and zsh uses, and then I stopped looking.
>
> Thoughts? OK?
It's unclear to me what need is being being addressed here --- are you
wanting a
On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
>
> > If folks indeed think that this is a must-have feature, this is
> > certainly a better approach. I wonder though if the setupterm() call
> > should happen earlier when
On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
> If folks indeed think that this is a must-have feature, this is
> certainly a better approach. I wonder though if the setupterm() call
> should happen earlier when interactive mode is initialized?
This turns out to be simpler than
I'm currently on vacation with very limited ability to test, but I do approve
of this way.
/Alexander
On June 17, 2018 5:00:17 PM GMT+02:00, "Todd C. Miller"
wrote:
>On Sat, 16 Jun 2018 16:16:57 -0600, "Todd C. Miller" wrote:
>
>> On Sat, 16 Jun 2018 14:50:40 +0200, Mark Kettenis wrote:
>>
On Sat, 16 Jun 2018 12:41:12 -0700, Il Ka wrote:
> > alternative that doesn't require linking ksh with
> > curses?
>
> I'm curious, is it possible to use termcap/terminfo directly here?
My recent diffs use the terminfo api rather than full-blown curses
but it is all the same library.
- todd
> alternative that doesn't require linking ksh with
> curses?
I'm curious, is it possible to use termcap/terminfo directly here?
--
Sent from:
http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html
On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
> If folks indeed think that this is a must-have feature, this is
> certainly a better approach. I wonder though if the setupterm() call
> should happen earlier when interactive mode is initialized? Probably
> best to link against
> From: "Todd C. Miller"
> Date: Sun, 17 Jun 2018 09:00:17 -0600
>
> On Sat, 16 Jun 2018 16:16:57 -0600, "Todd C. Miller" wrote:
>
> > On Sat, 16 Jun 2018 14:50:40 +0200, Mark Kettenis wrote:
> >
> > > To be honest, I find the whole idea of invoking an external program to
> > > clear the screen
On Sat, 16 Jun 2018 16:16:57 -0600, "Todd C. Miller" wrote:
> On Sat, 16 Jun 2018 14:50:40 +0200, Mark Kettenis wrote:
>
> > To be honest, I find the whole idea of invoking an external program to
> > clear the screen insane.
>
> Linking with curses doesn't increase the size a huge amount since
>
On Sat, 16 Jun 2018 14:50:40 +0200, Mark Kettenis wrote:
> To be honest, I find the whole idea of invoking an external program to
> clear the screen insane.
Linking with curses doesn't increase the size a huge amount since
we just need to query terminfo.
textdatabss dec hex
Yeah, I've made such stuff, even which preserves the actual position on the
command line, but I'm not too happy about screwing up the yank buffers...
On June 16, 2018 9:16:50 PM GMT+02:00, Sebastian Benoit
wrote:
>
>fwiw you can just use
>
>bind -m '^L'=^Uclear'^J^Y'
>
>
>Todd C.
fwiw you can just use
bind -m '^L'=^Uclear'^J^Y'
Todd C. Miller(todd.mil...@sudo.ws) on 2018.06.16 06:37:03 -0600:
> On Tue, 12 Jun 2018 02:35:57 +0200, Alexander Hall wrote:
>
> > The diff below uses system(3) to call /usr/bin/clear, fiddling with
> > *env() to make sure the current TERM
On Sat, Jun 16, 2018 at 07:47:07PM +0200, Mark Kettenis wrote:
> > Date: Sat, 16 Jun 2018 18:15:42 +0200
> > From: Tomasz Rola
> >
[...]
> >
> > Just my cent or two.
>
> You're missing the point here. Calling /usr/bin/clear to clear the
> screen from one of your scripts is fone. Doing so
> Date: Sat, 16 Jun 2018 18:15:42 +0200
> From: Tomasz Rola
>
> On Sat, Jun 16, 2018 at 02:50:40PM +0200, Mark Kettenis wrote:
> [...]
> >
> > To e honest, I find the whole idea of invoking an external program to
> > clear the screen insane.
>
> Not necesarilly wanting to quarrel about this,
On Sat, Jun 16, 2018 at 02:50:40PM +0200, Mark Kettenis wrote:
[...]
>
> To e honest, I find the whole idea of invoking an external program to
> clear the screen insane.
Not necesarilly wanting to quarrel about this, but:
1. What would you say to someone who wants to run an old sh script
which
> From: "Todd C. Miller"
> Date: Sat, 16 Jun 2018 06:53:38 -0600
>
> On Sat, 16 Jun 2018 14:50:40 +0200, Mark Kettenis wrote:
>
> > To be honest, I find the whole idea of invoking an external program to
> > clear the screen insane.
>
> Do you have an alternative that doesn't require linking
On Sat, 16 Jun 2018 14:50:40 +0200, Mark Kettenis wrote:
> To be honest, I find the whole idea of invoking an external program to
> clear the screen insane.
Do you have an alternative that doesn't require linking ksh with
curses?
- todd
> From: "Todd C. Miller"
> Date: Sat, 16 Jun 2018 06:37:03 -0600
>
> On Tue, 12 Jun 2018 02:35:57 +0200, Alexander Hall wrote:
>
> > The diff below uses system(3) to call /usr/bin/clear, fiddling with
> > *env() to make sure the current TERM value is propagated. The error
> > handling is
On Tue, 12 Jun 2018 02:35:57 +0200, Alexander Hall wrote:
> The diff below uses system(3) to call /usr/bin/clear, fiddling with
> *env() to make sure the current TERM value is propagated. The error
> handling is deliberately sparse, since I don't know what the reasonable
> error actions would
On 06/06/18 13:50, Todd C. Miller wrote:
> On Tue, 05 Jun 2018 16:29:33 -0600, "Theo de Raadt" wrote:
>
>>> + clearstr = "\033[H\033[J";
>>
>> I abhor increasing assumptions that the terminal honours that particular
>> ANSI standard.
>>
>> Sorry, but at that point you have
On Tue, 05 Jun 2018 16:29:33 -0600, "Theo de Raadt" wrote:
> > + clearstr = "\033[H\033[J";
>
> I abhor increasing assumptions that the terminal honours that particular
> ANSI standard.
>
> Sorry, but at that point you have to use the libraries and get the
> information.
Or
On Wed, Jun 06, 2018 at 12:20:50AM +0200, Alexander Hall wrote:
> This adds a "clear-screen" editing command to the emacs editing mode.
> This is the same name as bash and zsh uses, and then I stopped looking.
>
> The default binding of 'redraw' remains for ^L, for now anyway, so
> you'll need to
> + clearstr = "\033[H\033[J";
I abhor increasing assumptions that the terminal honours that particular
ANSI standard.
Sorry, but at that point you have to use the libraries and get the
information.
This adds a "clear-screen" editing command to the emacs editing mode.
This is the same name as bash and zsh uses, and then I stopped looking.
The default binding of 'redraw' remains for ^L, for now anyway, so
you'll need to run
$ bind ^L=clear-screen"
when testing.
$CLEARSTR can be set to an
43 matches
Mail list logo
