Empty line when opening terminal

[martensjostrand]

Bug Report

Current Behavior

When add_line is enabled a new line is added at the beginning of every new terminal window/tab.

Expected Behavior

Using add_line should not add a new line above the first line of every window / tab.

Additional context/Screenshots

Environment

• Starship version: starship 0.25.0
• Shell type: zsh
• Shell version: zsh 5.3 (x86_64-apple-darwin18.0)
• Shell plugin manager: antibody
• Terminal emulator: iTerm2
• Operating system: OSX 10.14.6

Relevant Shell Configuration

eval "$(starship init zsh)"

source <(antibody init)
antibody bundle < ~/.zsh_plugins.txt

Starship Configuration

add_newline = true

Possible Solution

if config.add_newline {
        writeln!(buf).unwrap();
}

The above if-statement from https://github.com/starship/starship/blob/master/src/print.rs#L23 could be changed into something inspired by Spaceship's solution:
max-baz/spaceship-prompt@815b68c found in spaceship-prompt/spaceship-prompt#462

[yuri1969]

It is certainly possible to reuse max-baz/spaceship-prompt@815b68c - check if starship has been called for the first time and pass it that information. This would prevent printing the newline after a shell initiation.

However, since starship includes the newline in PS1 it would still display the newline when issuing Ctrl+L/clear. Correct me if I'm wrong.

[taranjlu]

I also find this very visually distracting, particularly on clearing the screen.

[mnpw]

VSCode integrated terminal adds more padding on top of this which I find very annoying.

[disketten]

How about something like this?

diff --git a/Cargo.toml b/Cargo.toml
index 4837654..17b0a3d 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -59,6 +59,7 @@ open = "1.4.0"
 unicode-width = "0.1.8"
 textwrap = "0.12.0"
 term_size = "0.3.2"
+crossterm = "0.17"

 # Optional/http:
 attohttpc = { version = "0.15.0", optional = true, default-features = false, features = ["tls", "form"] }
diff --git a/src/print.rs b/src/print.rs
index 369f3b3..47e4783 100644
--- a/src/print.rs
+++ b/src/print.rs
@@ -4,6 +4,7 @@ use rayon::prelude::*;
 use std::fmt::{self, Debug, Write as FmtWrite};
 use std::io::{self, Write};
 use unicode_width::UnicodeWidthChar;
+use crossterm::cursor;

 use crate::context::{Context, Shell};
 use crate::module::Module;
@@ -23,7 +24,11 @@ pub fn get_prompt(context: Context) -> String {

     // Write a new line before the prompt
     if config.add_newline {
-        writeln!(buf).unwrap();
+        if let Ok(pos) = cursor::position() {
+            if pos != (0, 0) {
+                writeln!(buf).unwrap();
+            }
+        }
     }

     // A workaround for a fish bug (see #739,#279). Applying it to all shells

I think this should eliminate the Ctrl+L/clear problem as well and handle the root situation as well.

Note, I am not a Rust programmer. In fact, this is my first Rust code, so you can probably do better. I have only tested this using cargo run -- prompt as I do not know how to use this binary outside of the project tree.

[yuri1969]

@Sharpeee Just a quick observation. On my machine (Linux urxvt+Bash), it takes over 1sec to render when running the patched binary as a prompt (on $PATH).

[disketten]

@yuri1969 I have seen some weird behaviour as well. It works as expected when I run it through cargo, but fails when running as stand-alone. I will look into it when I have time.

If it does not work using crossterm, maybe there is another way to get the current cursor position?

[disketten]

FYI: I have moved back to a one line prompt (not because of this issue), so I will not look any more at this.

[chipbuster]

Related issue at spaceship: spaceship-prompt/spaceship-prompt#462

Looks like Spaceship hasn't solved this issue either. I tried applying the patch from max-baz/spaceship-prompt@815b68c to the current version of spaceship, but it straight-up doesn't work--it just disables the newlines altogether.

The issue that @yuri1969 brought up is also relevant here, since even if we fix the first newline (when the shell initializes), we have no way of knowing if the screen's been cleared, since that happens while the shell is still running.

It seems that at least some shells implement screen clear by just emitting a form-feed character, so there's no way in general to figure out if the screen has been cleared, because the shell doesn't have to tell us what it's doing, and starship does not read the output of the shell it's currently attached to (nor should it).

I really don't want to tie the prompt to a terminal either. While the crossterm trick is an interesting idea, we already have several terminal compatibility issues, and I the last thing I want is to make those more explicit.

So at the moment, I'm stumped. In essence, we need some way to detect if we're printing at the top of the terminal (because the shell was just launched, or because the user cleared the screen with CTRL+L, or because the user ran echo -e '\0033\0143', or because the VTE-based terminal received a Reset-and-Clear command, or because an xterm-based system received Esc-c......) but without being explicitly tied to a terminal type.

[chipbuster]

If we're shooting for ANSI-compatible terminals, I suppose we could try using ANSI escape codes to query the cursor position, but we'd need some way to intercept that response before it gets printed to the terminal. We do currently use ANSI color codes already, but I don't know how general the support is for the full ANSI escape code set: it might be a very different game for a terminal to support just color codes vs. a full set of ANSI control sequences.

[jspiro]

While I see how this issue is the commonality of the others referenced and closed, and an extra empty line is annoying–I don't feel it's as significant as the first line of the prompt being missing after clearing the buffer (when you run Clear Buffer in e.g. iTerm), and may garner more attention from the community.

I.e. #1601 seems like it should be left open, even if it shares the cause of #560.

[chipbuster]

I wasn't tracking #1601 closely, but the post there mentions that zprezto doesn't have this issue, which we could potentially investigate for a solution (I had tried previously to look at how this was supposedly solved in a spaceship fork, but the patches there just caused my shell to crash and I couldn't work out why).

I have a question.. Will this bug be fixed and merged say EVER in future?

[matchai]

I have a question.. Will this bug be fixed and merged say EVER in future?

If you have an idea for how to address this issue, pull requests are welcome. 😊