Scott Fitzgerald

it seems as if umenu doesn't evaluate the "-" symbol correctly.

when it holds as an item "-" it draws a horizontal break in the menu.

if it has "\-" it appears correctly in the dropdown, but evaluates as

if the item is set to "-", it disappears.

i noticed this when jit.op wasn't behaving as expected from an old

still exists like this in the jit.op helpfile

when it holds as an item "-" it draws a horizontal break in the menu.
if it has "\-" it appears correctly in the dropdown, but evaluates as
"-".
if the item is set to "-", it disappears.

i noticed this when jit.op wasn't behaving as expected from an old
patch when selecting the "-"

umenu-bug

Quote: Scott Fitzgerald wrote on Wed, 21 May 2008 03:43

----------------------------------------------------

> when it holds as an item "-" it draws a horizontal break in the menu.

If you want a minus sign in your menu list (weird, but ok...) either use " -" or en-dash or em-dash or any of the other unicode dashes or something else.

You will, of course, adjust your test to match what you're actually using.

Quote: Scott Fitzgerald wrote on Wed, 21 May 2008 03:43
----------------------------------------------------
> when it holds as an item "-" it draws a horizontal break in the menu.

You will, of course, adjust your test to match what you're actually using.


There is a bug in umenu where, if you correctly specify a minus with "\-", the object outputs "-" instead of "-" from the middle outlet. This will be fixed in the next release.

+1 for backwards compatibility with my 4.x patches!

On Wed, May 21, 2008 at 12:46 PM, Jeremy Bernstein wrote:

> There is a bug in umenu where, if you correctly specify a minus with "\-", the object outputs "-" instead of "-" from the middle outlet. This will be fixed in the next release.

On Wed, May 21, 2008 at 12:46 PM, Jeremy Bernstein  wrote:
>
> There is a bug in umenu where, if you correctly specify a minus with "\-", the object outputs "-" instead of "-" from the middle outlet. This will be fixed in the next release.


> There is a bug in umenu where, if you correctly specify a minus with

> "\-", the object outputs "-" instead of "-" from the middle outlet.

> This will be fixed in the next release.

I just observed, that in the moment you place a - into the inspector, 

the inspector is changing it to an unslashed -. Maybe that is the real 

I would expect from a \- to output correctly -...

(escape one which is a special character...)

Jeremy Bernstein schrieb:
> There is a bug in umenu where, if you correctly specify a minus with
> "\-", the object outputs "-" instead of "-" from the middle outlet.
> This will be fixed in the next release. 

Why would it need two \- instead of -?
I just observed, that in the moment you place a - into the inspector, 
the inspector is changing it to an unslashed -. Maybe that is the real 
culprit...
I would expect from a  \- to output correctly -...
(escape one  which is a special character...)

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


"\-" resolves to "-": an escaped '' is '', '-' remains '-'.

"-" resolves to "-": an escaped '-' is '-'

"-" means 'minus', and '-' means 'divider'.

"\-" resolves to "-": an escaped '' is '', '-' remains '-'.
"-" resolves to "-": an escaped '-' is '-'

Absolutely clear. I just think it's easier to use something that looks like a minus but isn't (ie some kind of Unicode dash), rather than deal with escaping escape characters (which tends to confuse both me and Max and a lot of other people).

Also, the dashes often look nicer than minus... dare I say "more dashing" ?–)

When you provide the perfectly-typeable-on-all-platforms-and-layouts-but-not-actually-desired-as-a-text-character unicode dash, I will be more than happy to implement it as an alternative.

My suggestion was not for a replacement to the minus sign indicating menu divider. I was suggesting that Scott might want to consider something other than minus for his project (assuming there is something that works for him).

I'm as aware of the vagaries of keyboard layouts as the next guy. At least.–

If Scott's on Mac OS, he can use option-minus (either US/Int'l or French layouts) to create a dash (en or em, respectively) for his umenu that won't genereate a menu break. 'Fraid I don't have an easy solution for Windows.

I was able to swap out "-" with "sub" in this case (using jit.op).

However, I am somewhat loathe to do that in all my old patches.

The option-minus is pretty sweet though, thanks Peter.

On Thu, May 22, 2008 at 6:35 PM, Peter Castine wrote:

> My suggestion was not for a replacement to the minus sign indicating menu divider. I was suggesting that Scott might want to consider something other than minus for his project (assuming there is something that works for him).

> I'm as aware of the vagaries of keyboard layouts as the next guy. At least.–

> If Scott's on Mac OS, he can use option-minus (either US/Int'l or French layouts) to create a dash (en or em, respectively) for his umenu that won't genereate a menu break. 'Fraid I don't have an easy solution for Windows.

I was able to swap out "-" with "sub" in this case (using jit.op).
However, I am somewhat loathe to do that in all my old patches.

On Thu, May 22, 2008 at 6:35 PM, Peter Castine  wrote:
>
> My suggestion was not for a replacement to the minus sign indicating menu divider. I was suggesting that Scott might want to consider something other than minus for his project (assuming there is something that works for him).
>
> I'm as aware of the vagaries of keyboard layouts as the next guy. At least.–
>
> If Scott's on Mac OS, he can use option-minus (either US/Int'l or French layouts) to create a dash (en or em, respectively) for his umenu that won't genereate a menu break. 'Fraid I don't have an easy solution for Windows.
>
> Hope this helps,
> P.


umenu bug?