[dev] dwm alpha patch: const isn't a const??

2019-05-26 Thread Paul Swanson
Hello,

I've a fresh clone of dwm and the dwm alpha patch (20180613-b69c870) and it's 
generating
the following error:

dwm.c
In file included from dwm.c:280:0:
config.h:24:27: error: initializer element is not constant
  [SchemeNorm] = { OPAQUE, baralpha, borderalpha },
   ^~~~
config.h:24:27: note: (near initialization for ‘alphas[0][1]’)
config.h:24:37: error: initializer element is not constant

What I can't understand, is the fact that 'baralpha', and all the other 
variables
accused of not being constants are in fact declared as "static const unsigned 
int":

static const unsigned int baralpha = 0xd0;
static const unsigned int borderalpha = OPAQUE;

If I substitute the initialising variables for a numeric literal (ie. 1) it 
compiles.
But if I leave the constants from the patch or make my own, it fails.

How can a const, not be a const?

Any help would be greatly appreciated.

Regards,

Paul Swanson

Sent from ProtonMail, encrypted email based in Switzerland.



Re: [dev] dwm alpha patch: const isn't a const??

2019-05-26 Thread Paul Swanson
Thanks for the swift reply Michael.

I just checked, my GCC is 6.3 ... ugh. I'd just run up a new install of MX 
Linux 18.2, for the first time, to check it out.

I wonder if this is a scenario that could be prevented /better identified 
through build flags or something.

Anyway, I'll explore that angle.

Cheers,

Paul Swanson

Sent from ProtonMail, encrypted email based in Switzerland.

‐‐‐ Original Message ‐‐‐
On Sunday, May 26, 2019 6:39 PM, Michael Forney  wrote:

> On 2019-05-26, Paul Swanson p...@protonmail.com wrote:
>
> > Hello,
> > I've a fresh clone of dwm and the dwm alpha patch (20180613-b69c870) and
> > it's generating
> > the following error:
> >
> > dwm.c
> > In file included from dwm.c:280:0:
> > config.h:24:27: error: initializer element is not constant
> >   [SchemeNorm] = { OPAQUE, baralpha, borderalpha },
> >^~~~
> > config.h:24:27: note: (near initialization for ‘alphas[0][1]’)
> > config.h:24:37: error: initializer element is not constant
> >
> >
> > What I can't understand, is the fact that 'baralpha', and all the other
> > variables
> > accused of not being constants are in fact declared as "static const
> > unsigned int":
> >
> > static const unsigned int baralpha = 0xd0;
> > static const unsigned int borderalpha = OPAQUE;
> >
> >
> > If I substitute the initialising variables for a numeric literal (ie. 1) it
> > compiles.
> > But if I leave the constants from the patch or make my own, it fails.
> > How can a const, not be a const?
> > Any help would be greatly appreciated.
>
> I'm not familiar with the alpha patch, but in standard C, initializer
> elements need to be constant expressions, which is different from an
> identifier for a const-qualified object. See
> http://port70.net/~nsz/c/c99/n1256.html#6.6p7 for what is allowed in
> initializers for static objects.
>
> Perhaps the author of the patch was using a compiler that allows these
> initializers (it looks like gcc-8 does, but gcc-7 does not).
>
> If you want a portable way to use an identifier in an initializer for
> a global, you have to use a preprocessor define like `#define baralpha 0xd0`, 
> or enum constant like `enum { baralpha = 0xd0 };`.





[dev] [st] how do cursor colors work?

2020-10-07 Thread Paul Swanson
Hi,

I'm trying to understand how the cursor coloring works in st. Maybe someone can 
kindly help.

In Vim, I was previously able to change cursor color, based on Vim mode, with 
the following use of op codes and the OSC patch, for example:

let &t_SI = "\[6 q\]12;yellow\x7"

However, I'm now trying to set cursor colors in NeoVim, which doesn't support 
the old Vim style 't_SI' method for setting op codes.
NeoVim help boldly claims that it "treats the terminal as any other UI", but 
its 'modern' cursor coloring just doesn't work in st, as best I can tell.

Are there methods other than OSC escape codes for setting cursor color? If so, 
what are they and does st support them?

Thanks,

Paul Swanson