From amol.vinayak.deshpande at gmail.com  Fri Jan  1 18:03:38 2021
From: amol.vinayak.deshpande at gmail.com (Amol Deshpande)
Date: Fri, 1 Jan 2021 10:03:38 -0800
Subject: [Tcsh] unicode in prompt
In-Reply-To: <CAHiFnDnjifnAMHfPhikwDA+5Kdich1+hf2skT4_S6YQPe8KxYQ@mail.gmail.com>
References: <CAHiFnDnjifnAMHfPhikwDA+5Kdich1+hf2skT4_S6YQPe8KxYQ@mail.gmail.com>
Message-ID: <CAHiFnDm0Rh3GcmQN9P190A5KmKNQGmnDkQj9stc=7OYDZW1rnw@mail.gmail.com>

false alarm. turns out it was a user error. I was putting non-escape
characters in %{ %}.  I confused the details of LITERAL and QUOTE.
Everything's fine on Linux.

thanks,
-amol

On Mon, Dec 28, 2020 at 7:12 AM Amol Deshpande <
amol.vinayak.deshpande at gmail.com> wrote:

> hey all,
>
> I've been trying to get unicode in the prompt like all the cool kids are
> doing these days. I created a gist based on my attempts with the prompt
> configuration tool oh my posh (at
> https://github.com/JanDeDobbeleer/oh-my-posh3)
>
> my gist:
> https://gist.github.com/amoldeshpande/8b95c58b94fe2278b65ba10e44e5a27e
>
> However, even on Linux  (WSL2 in Windows), setting the prompt this way
> seems to mess up the editing.  backward-delete-word , line erase etc. don't
> quite work reliably. They erase more than required (visually. the actual
> command itself is intact in the shell's buffer)
>
> Anyone have experience with this ?
>
> For Linux, should I be setting my locale somehow  to enable unicode in the
> term ? I am assuming it should just work.
>
>  From stepping through on Windows it looks like the calculations for
> cursor location are messed up by UTF8.  But that's a whole different thing
> I'm struggling with, so I'm not sure it's related. Doesn't Unix use UTF-32
> anyway ?
>
> BTW, gmail has been ghosting this mailing list for me (I do seem to get
> replies to threads though), so please feel free to email me directly if
> anything needs my attention.  I'm in the process of setting up a different
> email.
>
> thanks and Happy Holidays to all
>
> regards,
> -amol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.astron.com/pipermail/tcsh/attachments/20210101/8a187754/attachment.htm>

From jamie at catflap.org  Sat Jan  2 00:26:12 2021
From: jamie at catflap.org (Jamie Landeg-Jones)
Date: Sat, 02 Jan 2021 00:26:12 +0000
Subject: [Tcsh] Further issues with jobcmd
In-Reply-To: <2ea031c0-d5db-49fd-ba00-f28d2441dbdf@www.fastmail.com>
References: <2ea031c0-d5db-49fd-ba00-f28d2441dbdf@www.fastmail.com>
Message-ID: <202101020026.1020QCUE024726@donotpassgo.dyslexicfish.net>

"Eduardo Alvarez" <ealvarez at fastmail.com> wrote:

> Hello, list,
>
> Last year, I reported an issues with jobcmd and ls (see "[Tcsh] ls prints 0m if xterm title is set via jobcmd" from September 18). I recently decided to revisit this configuration, using ls-F as a substitute, and in the process of testing I found another bit of odd behavior.
>
> Where it happens: I've seen this take place on Xterm and rxvt-unicode. No further tests have been conducted.
>
> How to reproduce:
>
> 1. Alias jobcmd as follows. Again, note the un-escaped semicolon, which is necessary for this to work correctly:
>
>     alias jobcmd 'echo -n "\033]2;\!#:q\007"'
>
> 2. Run any command that uses an argument. I used "man man",  "vim foo", and "ls /etc" as tests.
> 3. If it's a full-screen program (such as vim or man), close the app.
> 4. Press up arrow or CTRL-P to invoke up-history.

>
> What should happen:
>
> The history mechanism should put the last command executed, complete with its arguments (eg, man man).
>
> What happens:
>
> The history mechanism prints only the command, without arguments. If up-history is invoked again, however, then the command + argument is displayed.
>
> Oddly enough, executing "history" only shows the command and its arguments, there isn't a listing in history with just the command.
>
> Thanks in advance for the help,

In my tcshrc, I have a piece of code in "postcmd" that sets a variable "this_command". I hit the
same problem a while back. My tcshrc currently contains:

## _____________________________________________________________________________________________________
## NB: In the following command, instead of the snippet:   set this_command="`history -h 1`";
##     , we should have been able to use:                  set this_command='"'"'\!#:0:q \!#:*:q'"'"';
##
##     However, this produces a bug that messes up the interactive session history
##     (in particular, using up-arrow to move backwards in history)
## _____________________________________________________________________________________________________
##

I don't have a fix, but does the workaround I used above work for you?

Cheers
   Jamie