search

tcsh-org / tcsh

This is a read-only mirror of the tcsh code repository.
https://www.tcsh.org/
Other
232 stars 42 forks source link

Request option for prompt newline character to be real newline character w/o side effect of settc am no #15

Closed smprather closed 2 years ago

smprather commented 5 years ago

Hi tcsh team--

I am looking for robust resolution to the issue I raised here.

I want to be able to use a newline character in my prompt w/o the terminal thinking the first line is padded with spaces (which apparently most do when "move to end of line" escape sequence is used). The excellent answer given at StackExchange notes that the settc work-around causes any multi-line selection to contain newline characters at the wrap boundary. That's a showstopper for me.

So I would like to have a tcsh option have prompt newlines generate actual newline characters instead of the "move to end of line" sequence".

Thanks! --Myles

Jamie-Landeg-Jones commented 4 years ago

Yeah, this has bugged me for a while, too:

I have a newline in my prompt, and I get "all the spaces" instead of a newline when running GNU "screen".. This becomes more obvious when viewing back a "screen" session in a different sized window!

Accidentally stumbling on your message has prompted me to look further.

I'm not really sure why the padding to the end of the line is done. I think it may be something to do with the fact that when you echo a line to the screen, if the line includes the last character of the column, you don't necessarily want to do a newline unless another character is produced (i.e. when a character overflows to the next line, you don't want the newline before it until and only if the character appears)

However, whether this is right or not, I can't see why a literal newline character is treated similarly, as to me it seems that it should appear literally.

Anyway, this patch seems to fix it, removing the padding when a literal newline is processed.

I've only been running with this for a short while, and so there may be some situations where things go wrong, but give it a go, and let me know!

In the meantime, I'd be grateful if @zoulasc could throw some light on it,

cheers, Jamie

--- ed.refresh.c.orig   2017-01-31 18:41:14.000000000 +0000
+++ ed.refresh.c        2019-11-29 10:38:48.935126000 +0000
@@ -195,7 +195,7 @@
     w = NLSClassify(c, nocomb, drawPrompt);
     switch (w) {
        case NLSCLASS_NL:
-           Vdraw('\0', 0);             /* assure end of line    */
+         /*  Vdraw('\0', 0); */        /* assure end of line    */
            vcursor_h = 0;              /* reset cursor pos      */
            vcursor_v++;
            break;
zoulasc commented 4 years ago

I think this Vdraw('\0', 0); just does Vdisplay[vcursor_v][vcursor_h] = '\0'; which is to NUL terminate the line. I think that removing it is not a good idea because it might end up displaying garbage if the line used to be longer. Does just doing that assignment instead of calling Vdraw() change things?

christos

On Nov 29, 2019, at 5:53 AM, Jamie Landeg Jones notifications@github.com wrote:

Yeah, this has bugged me for a while, too:

I have a newline in my prompt, and I get "all the spaces" instead of a newline when running screen.. This becomes more obvious when viewing back a screen session in a different sized window!

Stumbling on your message accidentally prompted me to look further.

I'm not really sure why the padding to the end of the line is done. I think it may be something to do with the fact that when you echo a line to the screen, if the line includes the last character of the column, you don't necessarily want to do a newline unless another character is produced (i.e. when a character overflows to the next line, you don't want the newline before it until and only if the character appears)

However, whether this is right or not, I can't see why a literal newline character is treated similarly, as to me it seems that it should appear literally.

Anyway, this patch seems to fix it, removing the padding when a literal newline is processed.

I've only been running with this for a short while, and so there may be some situations where things go wrong, but give it a go, and let me know!

In the meantime, I'd be grateful if @zoulasc https://github.com/zoulasc could throw some light on it,

cheers, Jamie

--- ed.refresh.c.orig 2017-01-31 18:41:14.000000000 +0000 +++ ed.refresh.c 2019-11-29 10:38:48.935126000 +0000 @@ -195,7 +195,7 @@ w = NLSClassify(c, nocomb, drawPrompt); switch (w) { case NLSCLASS_NL:

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tcsh-org/tcsh/issues/15?email_source=notifications\u0026email_token=AAENP5NT5YK7HQN5VMPFXBTQWDYBJA5CNFSM4IOPAAP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFORZMA#issuecomment-559750320", "url": "https://github.com/tcsh-org/tcsh/issues/15?email_source=notifications\u0026email_token=AAENP5NT5YK7HQN5VMPFXBTQWDYBJA5CNFSM4IOPAAP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFORZMA#issuecomment-559750320", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

suominen commented 2 years ago

Closing due to no response.