[Python-mode] Fwd: Re: adding a standard font-lock-number-face
Hi, would make a bug report/feature request for that. Opinions? Cheers, Andreas Am 17.06.2011 05:54, schrieb Fabian Ezequiel Gallina: 2011/6/17 Stefan Monniermonn...@iro.umontreal.ca: So long story short: isn't a good idea to add a standard font-lock-number-face in order to have fine grained control on font-lock and give the users the chance to customize numbers decoration out of the box? I don't think highlighting tokens that are only lexically relevant but not syntactically relevant is a good idea. E.g. it's good to highlight keywords because they determine structure. It's good to highlight strings and comments because keywords within them *don't* determine structure. It's good to highlight identifier definitions because these are semantically important and they tend to be a bit like section titles, so syntactically meaningful. But it's not useful to highlight all identifiers, or all numbers, or all separators, or all infix operators, ... because that doesn't help the user navigate his code. Thanks for the clarification Stefan, I was pretty sure there was a good reason why it wasn't there already. An argument I can think of for inclusion is that it seems highlighting those kind of stuff (event operators) is really common on other editors, so it is acceptable that people coming from other places would expect this kind of stuff highlighted out-of-the-box. I know the people coming from other editors argument is kinda weak, but I don't see why not giving them the chance to enable that easily in a vanilla Emacs. Please note that I'm no expert at font-locking but I think it might be good (and possible) to let modes to specify a higher or special level of font-locking so this kind of things can be highlighted. Let the default be the standard Emacs way, but giving the users the chance to enable that special level easily. This way standard font-lock performance shouldn't be hit. What do you think? Regards, Hi Fabian, don't know if my opinion here values a cent at all, :) but let me tell that IMO you are right. As long as the default set not differs ie inherits from default face, the user normally will not notice that customizable. OTOH user looking for will find it. Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] adding a standard font-lock-number-face
On Jun 17, 2011, at 08:34 AM, Andreas Röhler wrote: would make a bug report/feature request for that. Opinions? Personally, I think it's overkill. I agree that making the default indistinguishable would lessen the fruit salad look, but I wonder if it's really all that useful. I guess I would compromise by not adding any py-* faces to handle these. If there are already existing font-lock-* faces for these types of things, adding some regexps to recognize them in Python code would be okay, as long as performance doesn't suffer. Just my opinion though. -Barry Am 17.06.2011 05:54, schrieb Fabian Ezequiel Gallina: 2011/6/17 Stefan Monniermonn...@iro.umontreal.ca: So long story short: isn't a good idea to add a standard font-lock-number-face in order to have fine grained control on font-lock and give the users the chance to customize numbers decoration out of the box? I don't think highlighting tokens that are only lexically relevant but not syntactically relevant is a good idea. E.g. it's good to highlight keywords because they determine structure. It's good to highlight strings and comments because keywords within them *don't* determine structure. It's good to highlight identifier definitions because these are semantically important and they tend to be a bit like section titles, so syntactically meaningful. But it's not useful to highlight all identifiers, or all numbers, or all separators, or all infix operators, ... because that doesn't help the user navigate his code. Thanks for the clarification Stefan, I was pretty sure there was a good reason why it wasn't there already. An argument I can think of for inclusion is that it seems highlighting those kind of stuff (event operators) is really common on other editors, so it is acceptable that people coming from other places would expect this kind of stuff highlighted out-of-the-box. I know the people coming from other editors argument is kinda weak, but I don't see why not giving them the chance to enable that easily in a vanilla Emacs. Please note that I'm no expert at font-locking but I think it might be good (and possible) to let modes to specify a higher or special level of font-locking so this kind of things can be highlighted. Let the default be the standard Emacs way, but giving the users the chance to enable that special level easily. This way standard font-lock performance shouldn't be hit. What do you think? Regards, Hi Fabian, don't know if my opinion here values a cent at all, :) but let me tell that IMO you are right. As long as the default set not differs ie inherits from default face, the user normally will not notice that customizable. OTOH user looking for will find it. Cheers, Andreas signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] adding a standard font-lock-number-face
Am 17.06.2011 14:17, schrieb Barry Warsaw: On Jun 17, 2011, at 08:34 AM, Andreas Röhler wrote: would make a bug report/feature request for that. Opinions? Personally, I think it's overkill. Agreed, will not use that. However, as the OP pointed at, users switching from other editors asked for. IMHO a similar thing as with intellisense, which isn't that useful as it looks nice. In some time we should have that too for the reasons above. I agree that making the default indistinguishable would lessen the fruit salad look, but I wonder if it's really all that useful. I guess I would compromise by not adding any py-* faces to handle these. If there are already existing font-lock-* faces for these types of things, adding some regexps to recognize them in Python code would be okay, as long as performance doesn't suffer. Just my opinion though. -Barry OK, that should be a path, Andreas Am 17.06.2011 05:54, schrieb Fabian Ezequiel Gallina: 2011/6/17 Stefan Monniermonn...@iro.umontreal.ca: So long story short: isn't a good idea to add a standard font-lock-number-face in order to have fine grained control on font-lock and give the users the chance to customize numbers decoration out of the box? I don't think highlighting tokens that are only lexically relevant but not syntactically relevant is a good idea. E.g. it's good to highlight keywords because they determine structure. It's good to highlight strings and comments because keywords within them *don't* determine structure. It's good to highlight identifier definitions because these are semantically important and they tend to be a bit like section titles, so syntactically meaningful. But it's not useful to highlight all identifiers, or all numbers, or all separators, or all infix operators, ... because that doesn't help the user navigate his code. Thanks for the clarification Stefan, I was pretty sure there was a good reason why it wasn't there already. An argument I can think of for inclusion is that it seems highlighting those kind of stuff (event operators) is really common on other editors, so it is acceptable that people coming from other places would expect this kind of stuff highlighted out-of-the-box. I know the people coming from other editors argument is kinda weak, but I don't see why not giving them the chance to enable that easily in a vanilla Emacs. Please note that I'm no expert at font-locking but I think it might be good (and possible) to let modes to specify a higher or special level of font-locking so this kind of things can be highlighted. Let the default be the standard Emacs way, but giving the users the chance to enable that special level easily. This way standard font-lock performance shouldn't be hit. What do you think? Regards, Hi Fabian, don't know if my opinion here values a cent at all, :) but let me tell that IMO you are right. As long as the default set not differs ie inherits from default face, the user normally will not notice that customizable. OTOH user looking for will find it. Cheers, Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] more speech driven how twos
making more progress on some of the tools I need for speech or programming. Got a friend working with me on the variable management tool. Could use a few bits to help project along. 1) Where am I. used to help resolve which transformation of an English name is used in a given context. Specifically, I'm looking for files/class/method information. Next variation of this where am I. context is if I have an instance, what names are visible from that class defining that instance. Yes, yes I know all about ducktyping and how it has made people's lives completely miserable (mine at least. I really love a good strong type signature). I'm perfectly content to do my own transformation between instance and class and then ask about what's visible in the class. which raises the question of how does an external application query Emacs for data. 2) (Jump to|push to|get|change) [next | last] (instance|method|argument #|index|single [double] quotes|triple [double] quotes) These are the kind of operations and data types I need to manipulate. Some of these imply selection at the same time (get, change). 3) Something that would be really really nice would be navigation plus selection. If you navigate piece of code like this, you would highlight (and automatically select) in the following sequence if unit is carbs: if unit is carbs: (statements) if unit is carbs: (predicate) if unit is carbs: (comparison) if unit is carbs: if unit is carbs: if unit is carbs: as you can see, navigation involves traversing the language structure. The reason for this is each point is highlighted in red has a name and I should also be able to navigate it by name. I've put in the few that I can think of that makes sense and yes, if you have multiple terms it's going get a little ugly naming them but I'm sure something useful will evolve. For right now though simply navigating and selection would make things much easier because I don't have to coordinate hands, fingers, mouse to select an element. I just get a chunk and it will most likely be the chunk I want. I think I did warn you that speech user interfaces and specifically programming by speech does get a little weird at times if all you're used to his keyboard and mouse. :-) ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] more speech driven how twos
Am 17.06.2011 16:02, schrieb Eric S. Johansson: making more progress on some of the tools I need for speech or programming. [ ... ] Hi Eric, thanks reminding at that. Seeing you introduced a blueprint. Your previous text went into the `second-level-commands'. As said, would like to do that. As soon as we solved issues around python v2-v3 file exec, I'll hopefully address the matter. Meanwhile you could instruct us still a little bit about the specific environment in use. Could you send a kind of technical description of your system? Which programs do the speech recording etc. Do you use emacsspeak? Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
