Re: Comments
On Tue, Feb 14, 2006 at 09:10:09PM +0100, Viktor Griph wrote: Right now Style * Colorset 1 #, HilightColorset 2 is the same as Style * Colorset 1, HilightColorset 2 i.e. the # is simply ignored, which is somewhat correct according to the man page. In-line comments were never meant to work anyway. However most users familiar with shell-scripts and perl scripts would think that the end of the first line is a comment, also the fact that fvwm does not warn about ignoring unused arguments to style parts makes it really hard to spot such a misstake in a config file. (I actually didn't know that fvwm-comments had to start on the first character of a line until I looked it up in the man page right now. (and the emacs mode does not deal with that either ;))) However, it's not entierly sure that commetns only start on the beginning of a line, but they can also be before any command in stacked commands. No, not in the way you may think. In that case they are taken as part of the command and the '#' eventually becomes the first character of a command line and is interpreted as a comment. They *do not* comment out the rest of the line in which they occured. This in all can confuse some users (me included) alot. I think it would be good to think over the comment syntax, and maybe extend it to allow end of line comments as well. Since this would beak config file compability (if someone actually needs a '#' somewhere in the config file that is not on the beginning of line (s)he would have to escape it) it will have to wait until after 2.6 is realeased. I don't think that's a good idea at all. People who think that fvwm syntax is shell syntax are going to have a problem anyway. Fvwm's command line parser is undoubtedly strange, and I always had a vague plan to clean up parsing and command syntax radically in 3.0. It would be nice to have a real parser, maybe leveraged from zsh. Worrying just about comment syntax won't take us anywhere. Thoughts? One thing that probably can be done now, without to mush effort would be to add a warning for unconsumed non-whitespace characters following style options. It would also trap missing commas. Yes, that wouldn't hurt. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Comments
On Wed, 15 Feb 2006, Bert 'theBlackDragon' Geens wrote: On 2/14/06, Viktor Griph [EMAIL PROTECTED] wrote: (and the emacs mode does not deal with that either ;))) I don't know if you're using my emacs mode or the old one that's floating about the web, but I've fixed mine so it only higlights start of line comments. I'm not sure if it's allowed to have those preceded by spaces though, so if somebody could tell me that I'd be very grateful. Comments are allowed to be preceded by spaces. The mode I'm talking about is this one btw: http://www.lair.be/projects_fvwm-mode.php If you would know of a better or more up to date one, please do tell me as I haven't manage to find any (only a very old one that I didn't really like). I've actually been using a havily modified version [1] of that old mode, but I tested your mode before stating that the emacs mode didn't hilight comments correctly (to be on the safe side ;)). I've not posted it before since you posted your mode inbetween my start of adopting it for 2.5 and it being in somewhat working mode. Also I hadn't done anything in emacs lisp prior to that, so it's not very well written (and it's possible to follow my own evolving in the knowledge of emacs lisp by looking through how the coding style evolves in that file.) It only has support for config files, and not FvwmScript. It also can be a little slow sometimes since it's designed to be context sensitive for where keywords can be, and I really don't know the best way to optimize emacs lisp. (My brother asked me to do it for the reason that he always mixed up some keywords.) The reason why I stick to this mode and don't move over to your is probably that I have quite a fast machine, so I don't notice slowdowns in the fontlocking, and more importantly: Your mode does not font-lock comments spanning multiple lines (with escaped newlines), which makes commenting out long commands highlight strangely. The reason why I've never noticed that comments should be at start of commands is that I, normally always use it that way. It were just in a quick test I decided to try to disable the trail of a style command, and figured it didn't work. /Viktor [1] http://www.dd.chalmers.se/~griph/fvwm-mode.el.gz
Re: comments on the recent ter-off menu patches
On Tue, Jul 01, 2003 at 12:53:34AM +0200, [EMAIL PROTECTED] wrote:
There are some parts of the patch I do not understand or that are
bugs.
1) In menu_tear_off():
ms = menustyle_find(buffer);
if (!ms)
{
/* this must never happen */
fvwm_msg(
ERR, menu_tear_off,
impossible to create %s menu style, buffer);
free(buffer);
DestroyMenu(mr, False, False);
return;
}
Is there a specific reason why you use menustyle_find() instead of
MR_STYLE(mr_to_copy) which is much simpler and can not fail?
Even if there is a reason, I don't think you can return from the
function.
ms is not MR_STYLE(mr_to_copy) it is the menu style just created
by menustyle_parse_style(F_PASS_ARGS) where action is the address
of mr. Maybe, it will be good that menustyle_parse_style return
the menu style that it creates or modifies ... done.
2) In clone_menu_root_static():
What is the logic of changing
MR_COPIES(dest_mr) = 0;
to
MR_COPIES(dest_mr) = 1;
? Was it a bug?
When, you create a menu (with AddToMenu) MR_COPIES(mr) = 1. The menu
code logic implies that MR_COPIES is never 0 but in DestroyMenu just
before it is totally destroyed (and maybe re-created and in this case
MR_COPIES is re-incremented).
Yes, I think it was a bug. What happen if you enter DestroyMenu
with MR_COPIES(dest_mr) = 0?
...
MR_COPIES(dest_mr)--; -- MR_COPIES is -1
...
if (MR_COPIES(dest_mr) == 0) -- leaks
{
free some stuff
}
Any way if you change the test
MR_COPIES(dest_mr) == 0
by
MR_COPIES(dest_mr) = 0
it is not a big problem to set MR_COPIES to 0 for a tear off
menu. However, it seems that the logic is to set MR_COPIES
to 1 when you create a tear off menu.
3) This is a bug:
do_menu_close_tear_off_menu(pmp-menu, *pmp);
pmret-rc = MENU_ABORTED;
discard_window_events(
MR_WINDOW(pmp-menu), EnterWindowMask);
do_menu_close_tear_off_menu() destroys the MR_WINDOW(pmp-menu)
and thus discard_window_events() operates on a random Xid.
Yes. Fixed.
4) Please name all functions exported in menustyle.c
menustyle_something(). (I renamed copy_menu_style() to
menustyle_copy()).
Yep, such naming scheme is good. Ha 2 questions.
Under which condition you start the function with __?
(a private version of an exported function?).
What is the goal of the TearMenuOff command, how can
we use it?
Regards, Olivier
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: comments on the recent ter-off menu patches
On Tue, Jul 01, 2003 at 07:14:40AM +0200, Olivier Chapuis wrote:
On Tue, Jul 01, 2003 at 12:53:34AM +0200, [EMAIL PROTECTED] wrote:
2) In clone_menu_root_static():
What is the logic of changing
MR_COPIES(dest_mr) = 0;
to
MR_COPIES(dest_mr) = 1;
? Was it a bug?
When, you create a menu (with AddToMenu) MR_COPIES(mr) = 1. The menu
code logic implies that MR_COPIES is never 0 but in DestroyMenu just
before it is totally destroyed (and maybe re-created and in this case
MR_COPIES is re-incremented).
Yes, I think it was a bug. What happen if you enter DestroyMenu
with MR_COPIES(dest_mr) = 0?
...
MR_COPIES(dest_mr)--; -- MR_COPIES is -1
...
if (MR_COPIES(dest_mr) == 0) -- leaks
{
free some stuff
}
Any way if you change the test
MR_COPIES(dest_mr) == 0
by
MR_COPIES(dest_mr) = 0
it is not a big problem to set MR_COPIES to 0 for a tear off
menu. However, it seems that the logic is to set MR_COPIES
to 1 when you create a tear off menu.
Yes, it may have been a bug. However, testing for = 0 hides
potential problems elsewhere. Instead, we should call abort() if
it ever becomes 0.
4) Please name all functions exported in menustyle.c
menustyle_something(). (I renamed copy_menu_style() to
menustyle_copy()).
Yep, such naming scheme is good. Ha 2 questions.
Under which condition you start the function with __?
(a private version of an exported function?).
When I feel like it :-) Seriously, the __ indicates its an
internal helper function that encapsulates some work done by
higher level functions of the same module. Only static functions
can begin with __. It indicates that the function is really,
*really* internal and must never be exported.
What is the goal of the TearMenuOff command, how can
we use it?
It is a dummy command only defined in menus, exactly like Title.
Clicking on an item that uses it tears off the menu. It's not
implemented yet, though. If you try to write the command, the
following should be taken into account:
a) It should work on all visible menu items:
- normal items (+ foo tearmenuoff)
- separators (+ bar nop tearmenuoff?)
- titles (+ baz title tearmenuoff?)
b) An item that can tear off a menu must be selectable, i.e.
must be hilighted when the mouse is over it. This must be
somehow merged into the IS_SELECTABLE flag. Perhaps we need
a new flag too.
c) It would be nice if it worked in the dynamic menu actions.
This is probably hard to implement, and thus optional.
Bye
Dominik ^_^ ^_^
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: comments on the recent ter-off menu patches
On Tue, Jul 01, 2003 at 10:09:50AM +0200, fvwm-workers wrote: On Tue, Jul 01, 2003 at 07:14:40AM +0200, Olivier Chapuis wrote: What is the goal of the TearMenuOff command, how can we use it? It is a dummy command only defined in menus, exactly like Title. Clicking on an item that uses it tears off the menu. It's not implemented yet, though. If you try to write the command, the following should be taken into account: a) It should work on all visible menu items: - normal items (+ foo tearmenuoff) - separators (+ bar nop tearmenuoff?) - titles (+ baz title tearmenuoff?) b) An item that can tear off a menu must be selectable, i.e. must be hilighted when the mouse is over it. This must be somehow merged into the IS_SELECTABLE flag. Perhaps we need a new flag too. c) It would be nice if it worked in the dynamic menu actions. This is probably hard to implement, and thus optional. I have to take back everything. TearMenuOff is already implemented. Try AddToMenu ... + TearMenuOff for a tear off bar, and + Tear me off! for a normal item that reas out the menu. Bye Dominik ^_^ ^_^ -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
