On Mon, 2020-02-03 at 22:29 +, Bernd Edlinger wrote:
> On 2/3/20 10:05 PM, Segher Boessenkool wrote:
> > On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote:
> > > So gnome terminal is a problem, since it depend heavily on the
> > > software
> > > version, VTE library, and
Ping...
the latest version of this patch is here:
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00121.html
Thanks
Bernd.
On 2/3/20 11:29 PM, Bernd Edlinger wrote:
> On 2/3/20 10:05 PM, Segher Boessenkool wrote:
>> On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote:
>>> So gnome
On 2/3/20 10:05 PM, Segher Boessenkool wrote:
> On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote:
>> So gnome terminal is a problem, since it depend heavily on the software
>> version, VTE library, and gnome-terminal.
>> Sometimes URLs are functional, sometimes competely buggy.
>>
>>
On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote:
> So gnome terminal is a problem, since it depend heavily on the software
> version, VTE library, and gnome-terminal.
> Sometimes URLs are functional, sometimes competely buggy.
>
> But, wait a moment, here is the deal:
>
> I can
On 2/3/20 9:26 PM, Jakub Jelinek wrote:
> On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote:
>> Jakub, can you confirm that the COLORTERM on your working
>> gnome-terminal is set to "truecolor" ?
>
> On the box where I have display attached to yes, but it isn't propagated
> through
On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote:
> Jakub, can you confirm that the COLORTERM on your working
> gnome-terminal is set to "truecolor" ?
On the box where I have display attached to yes, but it isn't propagated
through ssh to the workstation that I do GCC development
On 2/3/20 3:08 PM, Segher Boessenkool wrote:
> On Sun, Feb 02, 2020 at 08:00:44AM +, Bernd Edlinger wrote:
Okay, thanks. That is a strong indication that there is no need
to interfere with screen, which proves that any auto-disabling should
have a very specific terminal
On Sun, Feb 02, 2020 at 08:00:44AM +, Bernd Edlinger wrote:
> >> Okay, thanks. That is a strong indication that there is no need
> >> to interfere with screen, which proves that any auto-disabling should
> >> have a very specific terminal detection logic.
> >
> > Jakub says that he tested
On 2/2/20 1:28 AM, Sandra Loosemore wrote:
> On 2/1/20 8:43 AM, Bernd Edlinger wrote:
>
>> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>> index 6ffafac..1d3fec5 100644
>> --- a/gcc/doc/install.texi
>> +++ b/gcc/doc/install.texi
>> @@ -2097,9 +2097,18 @@ option (if not used explicitly
On 2/2/20 12:05 AM, Segher Boessenkool wrote:
> On Sat, Feb 01, 2020 at 05:21:30PM +, Bernd Edlinger wrote:
>> On 2/1/20 6:12 PM, Jakub Jelinek wrote:
>>> On Sat, Feb 01, 2020 at 03:43:20PM +, Bernd Edlinger wrote:
I seem to remember him saying that he always has to configure with
On 2/1/20 8:43 AM, Bernd Edlinger wrote:
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 6ffafac..1d3fec5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2097,9 +2097,18 @@ option (if not used explicitly on the command line).
@var{choice}
can be one of
On Sat, Feb 01, 2020 at 05:21:30PM +, Bernd Edlinger wrote:
> On 2/1/20 6:12 PM, Jakub Jelinek wrote:
> > On Sat, Feb 01, 2020 at 03:43:20PM +, Bernd Edlinger wrote:
> >> I seem to remember him saying that he always has to configure with
> >> --with-diagnostics-color=never, and the URLs
On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> none of which use "TERM=fancy-pants-term-v42" either. (Did anyone ever
> use "dumb", anyway?)
>
It seems like emacs shell does set TERM=dumb, and it is certainly
the right thing not to emit any control codes in that environment.
Bernd.
On 2/1/20 6:12 PM, Jakub Jelinek wrote:
> On Sat, Feb 01, 2020 at 03:43:20PM +, Bernd Edlinger wrote:
>> I seem to remember him saying that he always has to configure with
>> --with-diagnostics-color=never, and the URLs are on top of that.
>> But there was no configure option for that, which,
On 2/1/20 4:54 PM, Segher Boessenkool wrote:
> Hi!
>
> On Sat, Feb 01, 2020 at 05:02:18AM +, Bernd Edlinger wrote:
Definitely, if the situation with tmux is like xfce4-terminal (reportedly
the 0.8 version switched to a fixed VTE, which makes the URLs invisible,
but the URL
On Sat, Feb 01, 2020 at 03:43:20PM +, Bernd Edlinger wrote:
> I seem to remember him saying that he always has to configure with
> --with-diagnostics-color=never, and the URLs are on top of that.
> But there was no configure option for that, which, given his explanation,
> made immediately
On Sat, Feb 01, 2020 at 08:41:15AM -0500, David Malcolm wrote:
> Does our existing colorization code not work with TMUX, or is it just the
> new URLs that are broken? Segher?
I don't know, I have colourisation turned off in GCC pretty much always
on systems I use with tmux. Some other programs
Hi!
On Sat, Feb 01, 2020 at 05:02:18AM +, Bernd Edlinger wrote:
> >> Definitely, if the situation with tmux is like xfce4-terminal (reportedly
> >> the 0.8 version switched to a fixed VTE, which makes the URLs invisible,
> >> but the URL feature request is pending sine 2017, with no activity
On 2/1/20 2:41 PM, David Malcolm wrote:
> On Sat, 2020-02-01 at 07:30 +, Bernd Edlinger wrote:
>>
>> On 1/31/20 11:06 PM, David Malcolm wrote:
>>> On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote:
Hi,
this is patch is heavily based on David's original patch here:
On Sat, 2020-02-01 at 07:30 +, Bernd Edlinger wrote:
>
> On 1/31/20 11:06 PM, David Malcolm wrote:
> > On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote:
> > > Hi,
> > >
> > > this is patch is heavily based on David's original patch here:
> > >
On 2/1/20 9:55 AM, Jakub Jelinek wrote:
> On Sat, Feb 01, 2020 at 07:30:15AM +, Bernd Edlinger wrote:
>> @@ -239,20 +243,86 @@ colorize_init (diagnostic_color_rule_t rule)
>> }
>> }
>>
>> +/* Return URL_FORMAT_XXX which tells how we should emit urls
>> + when in always mode.
>> +
On Sat, Feb 01, 2020 at 07:30:15AM +, Bernd Edlinger wrote:
> @@ -239,20 +243,86 @@ colorize_init (diagnostic_color_rule_t rule)
> }
> }
>
> +/* Return URL_FORMAT_XXX which tells how we should emit urls
> + when in always mode.
> + We use GCC_URLS and if that is not defined
On 1/31/20 11:06 PM, David Malcolm wrote:
> On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote:
>> Hi,
>>
>> this is patch is heavily based on David's original patch here:
>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html
>>
>> and addresses Jakub's review comments here:
>>
Hi Segher,
On 2/1/20 2:32 AM, Segher Boessenkool wrote:
> On Fri, Jan 31, 2020 at 11:38:04PM +, Bernd Edlinger wrote:
>> On 1/31/20 11:54 PM, Segher Boessenkool wrote:
>>> about most, which caused me to open PR93168, is TERM=screen (which is
>>> what tmux uses), so at least exclude that one?
On Fri, Jan 31, 2020 at 11:38:04PM +, Bernd Edlinger wrote:
> On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> > about most, which caused me to open PR93168, is TERM=screen (which is
> > what tmux uses), so at least exclude that one? And doing all this
>
> Definitely, if the situation with
On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> Hi!
>
> Thanks for working on this.
>
> On Fri, Jan 31, 2020 at 04:59:02PM +, Bernd Edlinger wrote:
>> I will try to improve the patch a bit, and hope you are gonna like
>> it. I agree that this feature is fine, and should be enabled by
>>
Hi!
Thanks for working on this.
On Fri, Jan 31, 2020 at 04:59:02PM +, Bernd Edlinger wrote:
> I will try to improve the patch a bit, and hope you are gonna like
> it. I agree that this feature is fine, and should be enabled by
> default, and just if it is positively clear that it won't work,
On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote:
> Hi,
>
> this is patch is heavily based on David's original patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html
>
> and addresses Jakub's review comments here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html
Hi Andrew,
I just saw your patch here:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01474.html
Re: [PATCH] gcc: Add new configure options to allow static libraries to be
selected
Note: the artefacts in my patch below seem to be a missing re-generated
gcc/configure
from your patch?
Is that
Hi,
this is patch is heavily based on David's original patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html
and addresses Jakub's review comments here:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html
So I hope you don't mind, when I pick up this patch since there
was
30 matches
Mail list logo
