Hi Pierre,
I’m happy to discuss it further (to some extent at least, because there
are other patches waiting for us to be reviewed :-)), but first, as I
wrote in another message, I think the topic was not consensual and thus
the series wasn’t ready to be pushed.
Pierre Neidhardt skribis:
> Ludo
Hi,
On Mon, 24 Feb 2020 at 17:44, Pierre Neidhardt wrote:
> >> - Leave colors when INSIDE_EMACS is set.
> >
> > Like Ricardo wrote before, this is not desirable for shell-mode. Also,
> > all or most GNU command-line tools behave that way.
>
> There might be a misunderstanding because M-x shell
Hi Pierre,
On Mon, 24 Feb 2020 at 17:45, Pierre Neidhardt wrote:
> Done, and it's fixed upstream!
You mean that INSIDE_EMACS is now correctly set with EShell, right?
Then, the Emacs manual is correct too in *eshell*:
--8<---cut here---start->8---
Emacs s
On Mon, 24 Feb 2020 at 17:22, Ludovic Courtès wrote:
> I have a preference for something that doesn’t fill the screen,
> especially since the last answers (those that remain visible without
> scrolling) are the least relevant. Emacs makes it easier to scroll up
> and search, but still.
Why just
Hi,
On Mon, 24 Feb 2020 at 17:19, Ludovic Courtès wrote:
> Jack Hill skribis:
> > I've been trying to follow this discussion as I have observed problems
> > with the linking characters in eshell. However, it seems I am having
> > seeing different behavior than others. In both Emacs 26.3 and
> >
Done, and it's fixed upstream!
Question: Which INSIDE_EMACS hack?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi!
I’m sorry that I’m so late to the discussion…
Pierre Neidhardt skribis:
> Can we still do the following:
>
> - Leave colors when INSIDE_EMACS is set.
Like Ricardo wrote before, this is not desirable for shell-mode. Also,
all or most GNU command-line tools behave that way.
> - Disable pag
Hi Jack,
Jack Hill skribis:
> I've been trying to follow this discussion as I have observed problems
> with the linking characters in eshell. However, it seems I am having
> seeing different behavior than others. In both Emacs 26.3 and
> Emacs-next 27.0.50, running as `emacs -q`, INSIDE_EMACS is
On Mon, 17 Feb 2020 at 14:42, Pierre Neidhardt wrote:
> Patch sent: #39642.
Nice! :-)
Hi Pierre,
On Mon, 17 Feb 2020 at 08:51, Pierre Neidhardt wrote:
>
> Can we still do the following:
>
> - Leave colors when INSIDE_EMACS is set.
It is what I propose. But this a "bug" in the patches that I sent. The
'link' is turned off and the 'highlight' is still set on but the
display is with
zimoun writes:
> Well, concretely, if you use EShell and you want a readable "guix
> describe", you have to put in your '.emacs' config file something like
> '(setenv "INSIDE_EMACS" "1")'. Or you should patch EShell and report
> it upstream.
I've reported upstream.
--
Pierre Neidhardt
https://
Hi,
On Thu, 13 Feb 2020 at 14:42, Alex Griffin wrote:
>
> On Thu, Feb 13, 2020, at 9:30 AM, zimoun wrote:
> > Therefore, IMHO you need to set the environment variable by yourself
> > in your config file. Or send a patch upstream.
> > Because the reason is that EShell is not doing the right thing
On Thu, Feb 13, 2020, at 9:30 AM, zimoun wrote:
> Therefore, IMHO you need to set the environment variable by yourself
> in your config file. Or send a patch upstream.
> Because the reason is that EShell is not doing the right thing and it
> is not compliant to the doc.
Compliant to which doc? The
On Wed, 12 Feb 2020 at 17:30, zimoun wrote:
> 1.
> By default with Emacs, *shell* is doing right and EShell not. Is it
> coming from Emacs or other? Could the Emacs from Guix do always the
> right thing?
>
> Other said, *shell* sets by default INSIDE_EMACS to "26.3,comint". And
> EShell does noth
Hi Pierre,
On Thu, 6 Feb 2020 at 10:51, Pierre Neidhardt wrote:
> Ricardo Wurmus writes:
> > I suppose you are not using a comint-derived mode for your shell then.
>
> Precision: It works with M-x shell but not with Eshell.
Yes, it is expected.
1. INSIDE_EMACS is set by 'comint-mode'
http://
Hi,
On Wed, 12 Feb 2020 at 14:39, Pierre Neidhardt wrote:
> zimoun writes:
> > However, I thought that it was fixed in Emacs 27. Ouch!
> I tried with Guix' emacs-next and I get the same problem.
Ok, I should have misread some news. :-)
Well, I am not following what we are talking about. Ther
zimoun writes:
> However, I thought that it was fixed in Emacs 27. Ouch!
>
>
>> commit:
>> ]8;;https://git.savannah.gnu.org/cgit/guix.git/commit/?id=232f344f9b9dc775fe8f9c7db2e45ba20431b071\232f344f9b9dc775fe8f9c7db2e45ba20431b071]8;;\
I tried with Guix' emacs-next and I get the same probl
On Tue, 11 Feb 2020, zimoun wrote:
In shell and term mode, INSIDE_EMACS is being set, and everything looks fine
(although without any highlighting).
You mean set by default, right?
Yes, for me emacs is setting INSIDE_EMACS for shell and term, but not
eshell with the default configuration.
Hi Jack,
On Tue, 11 Feb 2020 at 17:37, Jack Hill wrote:
> I've been trying to follow this discussion as I have observed problems
> with the linking characters in eshell. However, it seems I am having
> seeing different behavior than others. In both Emacs 26.3 and Emacs-next
> 27.0.50, running as
Hi Guix,
I've been trying to follow this discussion as I have observed problems
with the linking characters in eshell. However, it seems I am having
seeing different behavior than others. In both Emacs 26.3 and Emacs-next
27.0.50, running as `emacs -q`, INSIDE_EMACS is not being set in eshell
On Tue, 11 Feb 2020 at 15:19, Pierre Neidhardt wrote:
> Assuming we spit out right escape characters. Maybe what Zimoun meant
> here is that when INSIDE_EMACS is set, we don't write any escape char,
> so Eshell can't color anything here.
No, coloring and OSC are not related IMHO.
INSIDE_EMACS s
Hi Ludo,
On Tue, 11 Feb 2020 at 15:11, Ludovic Courtès wrote:
> >> The issue is that the highlight is not done and I am not happy with it. :-)
> >> Have you a fix for that?
> >
> > What do you want to do exactly? Underline the links?
>
> It’s up to the terminal emulator to do that (VTE does tha
On Tue, 11 Feb 2020 at 07:22, Pierre Neidhardt wrote:
> zimoun writes:
> > The issue is that the highlight is not done and I am not happy with it. :-)
> > Have you a fix for that?
>
> What do you want to do exactly? Underline the links?
It is not about the 'hyperlink' but about 'highlight'.
'
Ludovic Courtès writes:
> Pierre Neidhardt skribis:
>
>> zimoun writes:
>>
>>> The issue is that the highlight is not done and I am not happy with it. :-)
>>> Have you a fix for that?
>>
>> What do you want to do exactly? Underline the links?
>
> It’s up to the terminal emulator to do that (VT
Pierre Neidhardt skribis:
> zimoun writes:
>
>> The issue is that the highlight is not done and I am not happy with it. :-)
>> Have you a fix for that?
>
> What do you want to do exactly? Underline the links?
It’s up to the terminal emulator to do that (VTE does that, Eterm does
some fancy ani
zimoun writes:
> The issue is that the highlight is not done and I am not happy with it. :-)
> Have you a fix for that?
What do you want to do exactly? Underline the links?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi Pierre,
On Mon, 10 Feb 2020 at 20:36, Pierre Neidhardt wrote:
>
> This patch looks good to me. If no one objects I'd like to merge it.
Thank you to give a look.
The issue is that the highlight is not done and I am not happy with it. :-)
Have you a fix for that?
> > +
This patch looks good to me. If no one objects I'd like to merge it.
> + (commit (channel-commit channel))
> + (transformer hyperlink))
>"Return a hyperlink for COMMIT in CHANNEL, using COMMIT as the hyperlink's
> -text. The
Pierre Neidhardt skribis:
> Ludovic Courtès writes:
>
>> Hi!
>>
>> ‘INSIDE_EMACS’ has always been honored by (guix colors). Also, it’s
>> honored similar by all GNU tools and in particular Coreutils, which I
>> think is overall a good thing as Ricardo explained!
>
> Something did change for me
Hi!
Pierre Neidhardt skribis:
> In my experience, colors worked perfectly before the INSIDE_EMACS switch
> was introduced. I don't understand what this change tried to fix.
> Maybe one fix broke something else.
‘INSIDE_EMACS’ has always been honored by (guix colors). Also, it’s
honored simila
Pierre Neidhardt writes:
>>> - Rename it to GUIX_INSIDE_EMACS?
>>> - Document the existence of INSIDE_EMACS.
>>
>> The variable is set by Emacs. As an Emacs feature we should not
>> document it in Guix, nor should we rename it to GUIX_INSIDE_EMACS.
>
> Strange, I don't have this variable in my
Pierre Neidhardt writes:
>> Isn’t it considered best practise to set PAGER=cat when using Emacs as a
>> shell? That’s what I do to show man pages (when I’m not using M-x
>> woman) or to have “git log” do the right thing.
>
> --8<---cut here---start->8---
> e
On Tue, 4 Feb 2020 at 17:39, Pierre Neidhardt wrote:
> In my experience, colors worked perfectly before the INSIDE_EMACS switch
> was introduced. I don't understand what this change tried to fix.
> Maybe one fix broke something else.
INSIDE_EMACS fixes the terminals that render OSC character
in
Hi Ricardo,
On Tue, 4 Feb 2020 at 17:12, Ricardo Wurmus wrote:
> > - Rename it to GUIX_INSIDE_EMACS?
> > - Document the existence of INSIDE_EMACS.
>
> The variable is set by Emacs. As an Emacs feature we should not
> document it in Guix, nor should we rename it to GUIX_INSIDE_EMACS.
This is mi
Hi Pierre,
> - Rename it to GUIX_INSIDE_EMACS?
> - Document the existence of INSIDE_EMACS.
The variable is set by Emacs. As an Emacs feature we should not
document it in Guix, nor should we rename it to GUIX_INSIDE_EMACS.
> - Leave colors on when inside Emacs.
Wouldn’t this mess with font lo
Hi!
I just discovered the existence of the INSIDE_EMACS variable (thank you,
Zimoun!) which disable the funky characters in `guix describe`,
etc. when run from Eshell or Emacs' M-x shell.
Sadly, it also disables colours.
On a related topic, I think we should disable the
--8<---cut
36 matches
Mail list logo
