CEDET

Pete Beardmore writes:
> here is a set of patches for several bugs and some improvements to the 
> inline completion mechanism.

Thank you for the patches; they're much appreciated. Do you have papers
signed with the FSF? This will be necessary since CEDET is merged with
Emacs and your patches by far exceed the "tiny patch" limit.

Cheers,
David

David Engster <deng <at> randomsample.de> writes:
 
> Thank you for the patches; they're much appreciated. Do you have papers
> signed with the FSF? This will be necessary since CEDET is merged with
> Emacs and your patches by far exceed the "tiny patch" limit.
> 
> Cheers,
> David
> 
hi,

no i don't sorry. from what i've just read, is it possible for you to send 
me the assignment paper template(s) for this project? and does it really 
require snail mail all the way across the big pond?

cheers.

Pete Beardmore writes:
> David Engster <deng <at> randomsample.de> writes:
>> Thank you for the patches; they're much appreciated. Do you have papers
>> signed with the FSF? This will be necessary since CEDET is merged with
>> Emacs and your patches by far exceed the "tiny patch" limit.

> no i don't sorry. from what i've just read, is it possible for you to send 
> me the assignment paper template(s) for this project?

I attached the form to this mail. As for the project, just use 'GNU
Emacs', since this will also cover every project that is merged with it.

> and does it really require snail mail all the way across the big pond?

Unfortunately, yes. But I will need some time digging through your
patches anyway. :-) BTW, are you using CEDET from bzr, and which Emacs
version are you using?

-David

David Engster <deng <at> randomsample.de> writes:
> ..but I will need some time digging through your patches anyway.  
> BTW, are you using CEDET from bzr, and which Emacs version are you using?

hi David, just wanted to let you know that my FSF assignment copy arrived back
via email today :) the patches were all done against bzr8071. please come back
to me if you think any of them could go in but need more work, and of course 
no offense taken if you deem any (or all) of them too poor or unsuitable.

cheers,
Pete.

I'm confused.. was a new version of CEDET released?

On Thu, Aug 4, 2011 at 5:39 PM, Pete Beardmore <elbeardmorez@...> wrote:

> David Engster <deng <at> randomsample.de> writes:
> > ..but I will need some time digging through your patches anyway.
> > BTW, are you using CEDET from bzr, and which Emacs version are you using?
>
> hi David, just wanted to let you know that my FSF assignment copy arrived
> back
> via email today :) the patches were all done against bzr8071. please come
> back
> to me if you think any of them could go in but need more work, and of
> course
> no offense taken if you deem any (or all) of them too poor or unsuitable.
>
> cheers,
> Pete.
>
>
>
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Pete Beardmore writes:
> David Engster <deng <at> randomsample.de> writes:
>> ..but I will need some time digging through your patches anyway.  
>> BTW, are you using CEDET from bzr, and which Emacs version are you using?
>
> hi David, just wanted to let you know that my FSF assignment copy arrived back
> via email today :) the patches were all done against bzr8071. please come back
> to me if you think any of them could go in but need more work, and of course 
> no offense taken if you deem any (or all) of them too poor or unsuitable.

Thanks Pete for going through the trouble. I should find time to take a
look at the patches in the coming days.

-David

Pete Beardmore writes:
> here is a set of patches for several bugs and some improvements to the 
> inline completion mechanism.

Hi Pete,

I'm slowly starting to apply your patches. Unfortunately, the diffs are
garbled by word-wrapping - could you send me the full patch again, but
as an attachment? (No need to send the patches one-by-one, the full diff
will suffice).

Regarding tooltip completions, you should also take a look at
company-mode; it's easily installable from GNU ELPA (M-x list-packages
if you're using Emacs24-bzr) and supports Semantic out of the box. What
always bothered me with the graphical tooltips was that they're just too
slow and easily interfere with typing. Company-mode uses text overlays
to mimic tooltips, which is much faster.

-David

On 08/08/2011 02:22 PM, David Engster wrote:
> Pete Beardmore writes:
>> here is a set of patches for several bugs and some improvements to the
>> inline completion mechanism.
>
> Hi Pete,
>
> I'm slowly starting to apply your patches. Unfortunately, the diffs are
> garbled by word-wrapping - could you send me the full patch again, but
> as an attachment? (No need to send the patches one-by-one, the full diff
> will suffice).
>
> Regarding tooltip completions, you should also take a look at
> company-mode; it's easily installable from GNU ELPA (M-x list-packages
> if you're using Emacs24-bzr) and supports Semantic out of the box. What
> always bothered me with the graphical tooltips was that they're just too
> slow and easily interfere with typing. Company-mode uses text overlays
> to mimic tooltips, which is much faster.


I've often been impressed w/ that style tool tip.  Has there been a 
tooltip using overlays like that integrated into Emacs yes?  If so, it 
may be time to add a new tip style into Semantic's completion engine.

Eric

Eric M. Ludlam writes:
> On 08/08/2011 02:22 PM, David Engster wrote:
>> Regarding tooltip completions, you should also take a look at
>> company-mode; it's easily installable from GNU ELPA (M-x list-packages
>> if you're using Emacs24-bzr) and supports Semantic out of the box. What
>> always bothered me with the graphical tooltips was that they're just too
>> slow and easily interfere with typing. Company-mode uses text overlays
>> to mimic tooltips, which is much faster.
>
>
> I've often been impressed w/ that style tool tip.  Has there been a 
> tooltip using overlays like that integrated into Emacs yes?

I think I read on emacs-devel that company-mode is a candidate for
integration into Emacs.

>  If so, it may be time to add a new tip style into Semantic's
> completion engine.

company-mode is more than just a widget - it also takes care of querying
for completions, refining and searching for matches, etc.. So it pretty
much does everything that had to be explicitly coded for the Semantic
tooltip displayor. The only thing you have to provide is a 'back end'
which adheres to the company-mode API, but Nikolaj already wrote one for
Semantic, so there really isn't much to do anymore. :-) I use it all the
time and it works really great. Of course, there are some drawbacks to
using text overlays, the most important being that you're restricted to
the buffer's window for display, but I think its speed makes up for
that.

-David

On 08/09/2011 02:08 AM, David Engster wrote:
> Eric M. Ludlam writes:
>> On 08/08/2011 02:22 PM, David Engster wrote:
>>> Regarding tooltip completions, you should also take a look at
>>> company-mode; it's easily installable from GNU ELPA (M-x list-packages
>>> if you're using Emacs24-bzr) and supports Semantic out of the box. What
>>> always bothered me with the graphical tooltips was that they're just too
>>> slow and easily interfere with typing. Company-mode uses text overlays
>>> to mimic tooltips, which is much faster.
>>
>>
>> I've often been impressed w/ that style tool tip.  Has there been a
>> tooltip using overlays like that integrated into Emacs yes?
>
> I think I read on emacs-devel that company-mode is a candidate for
> integration into Emacs.
>
>>   If so, it may be time to add a new tip style into Semantic's
>> completion engine.
>
> company-mode is more than just a widget - it also takes care of querying
> for completions, refining and searching for matches, etc.. So it pretty
> much does everything that had to be explicitly coded for the Semantic
> tooltip displayor. The only thing you have to provide is a 'back end'
> which adheres to the company-mode API, but Nikolaj already wrote one for
> Semantic, so there really isn't much to do anymore. :-) I use it all the
> time and it works really great. Of course, there are some drawbacks to
> using text overlays, the most important being that you're restricted to
> the buffer's window for display, but I think its speed makes up for
> that.

That's good to know.  I've always been worried about simplified 
completion engines, in that if someone types:

a TAB

the size of the options available after "a" can be large, and the query 
can be slow, so the built in completion engine caches values between 
completion requests, allowing it to be faster.

Of course, that is also semantic's completion engine downfall, as it 
sometimes gets confused.

If a standard full completion request has proven fast enough for all 
requests, perhaps the old optimizations can be dropped.

Eric

Hi Pete,

I think I applied most of your changes now. Here are a few comments:

Pete Beardmore writes:

> #1. bug #1: Bug Showing Completions: (wrong-type-argument consp nil)

> #2. bug #2: Bug Showing Completions:
> 	    (wrong-type-argument number-or-marker-p (+ -90))

Both applied.

> #3. bug #3: tooltip disappears immediately
>
> #recipe
> place the mouse cursor in the region that the tooltip will be displayed in

> #commentary
> this is a 'bug' / 'feature' in the low-level C 'x-show-tip' function ..i 
> won't be looking in there any time soon.

I find that difficult to reproduce. I think it depends very much on the
used toolkit. Did you maybe manage to produce a recipe for this, only
using 'x-show-tip' and starting with 'emacs -Q' ? If so, this should be
reported as an Emacs bug.

> the patch below is a work around which simply warps the mouse pointer
> out of the way.

Since I wasn't able to really reproduce this, I haven't applied that
patch yet.

> #4. bug #4 use last completions when new prefix is subset of old prefix

Applied.

> #5. 'bug' #5 don't complete if there's no context
>
> #recipe
> apply idle patch
> set verbose mode -> (setq semantic-idle-scheduler-verbose-flag t)
> *@#k ..cannot reproduce

Me neither. :-)

>
> #location
> semantic-complete-analyze-inline-idle
> semantic-complete.el:2145 (bzr8071)
>
> #commentary
> a (in)valid overlay ..and no context?! how did i get here? probably just 
> ignore this as it 'should' be impossible, although i suppose it can't 
> hurt to add it given that i don't think i was far enough into my hacking 
> session to have tampered with anything that would obviously leave the 
> engine in an unrecoverable state (i.e. quiting the debugger so the 
> clean-up hooks don't run). i patched 'semantic-complete-analyze-idle' 
> assuming a similar issue could arise from the mini-buffer.

I'm not too fond of sprinkling the code with
semantic-analyze-current-context calls; I think we should try to find
the 'real' bug here... :-)

> also note that this error was only evident having patched semantic-idle.el 
> to not simply ignore problems (which i think should stand going forward!) 

I agree and have applied that.

> #6. misc typo patches..

> #7. improvement #1 collect additional matches when the context/prefix 
> decreases in size

> #8. improvement #2 short-circuit 'display action on TAB

All applied.

> #9. improvement #3 refine displayor modes of operation, make some properties 
> customisable, add 'remaining match' counts to tooltips, reset max-tags count
> when searching on a shortened prefix

I applied most of this with a few changes. 

> 'quiet-mode' - suppress all matches until the total number of matches 
> available is less than 'semantic-completion max-tags' number. several 
> tab presses will show an extended completion list, but only until the 
> next non-completion key/command is sent, hence truly staying 'quiet'. 
>
> 'standard-mode' - always provide up to 'semantic-completion max-tags' 
> number of completions when available by default. single TAB will reveal 
> the extended list of completions up to 
> 'semantic-completion max-tags-extended' number, and this extended list 
> will be shown for the remainder of the completion, unless backspace is 
> keyed which resets the max-tags count back down to 
> 'semantic-completion-max-tags'.
>
> 'verbose-mode' - always show the extended completions list. horrible.

I think those modes are good and an improvement over the previous
'force-show' option, which was a bit... erm, strange. :-)

> +(defcustom semantic-complete-inline-mode-quiet nil
> +  "When enabled, only show completions when we have narrowed all 
> +posibilities down to a maximum of 'semantic-complete-inline-max-tags'
> +tags. Pressing TAB multiple times will also show completions."
> +  :group 'semantic
> +  :type 'boolean
> +  :set '(lambda (sym var)
> +            (set-default sym var)
> +	    (setq semantic-complete-inline-mode-standard nil)
> +	    (setq semantic-complete-inline-mode-verbose nil)
> +	    (if var (setq semantic-complete-inline-mode -1))))

I did change that, since you usually implement those kinds of 'radio
button' behavior by using the 'choice' type and one variable. I also
renamed all variables to make clear that they're related to the tooltip
class. Most of my other changes were small and shouldn't touch the
actual code you did, but please try it out.

A few more remarks:

- Use 'delete-trailing-whitespace' to, well, delete trailing
  whitespaces. :-)

- doc-strings are expected to have a certain style in Emacs. For
  example, the first line should be a sentence describing the
  function. Also, all documentation in Emacs uses 'sentence spacing',
  meaning that there should be two whitespaces between sentences. (You
  can run 'checkdoc' to check your doc-strings and other stuff).

- You don't have to use 'progn' in the "else"-branch of an 'if'.

Thanks again,
-David

David Engster <deng <at> randomsample.de> writes:

> 
> > #3. bug #3: tooltip disappears immediately
> 
> I find that difficult to reproduce. I think it depends very much on the
> used toolkit. Did you maybe manage to produce a recipe for this, only
> using 'x-show-tip' and starting with 'emacs -Q' ? If so, this should be
> reported as an Emacs bug.

i just pulled and compiled bzr8090 and cannot hit this problem at all - a good 
thing! i'll keep an eye on it though, i have two other sessions running now 
using the bzr8071 base that both exhibit the problem if i remove my patches. 
strange.  

> 
> > #9. improvement #3 refine displayor modes of operation, make some 
properties 
> > customisable, add 'remaining match' counts to tooltips, reset max-tags count
> > when searching on a shortened prefix
> 
> I applied most of this with a few changes. 
> 
> 
> > +(defcustom semantic-complete-inline-mode-quiet nil
> > +  "When enabled, only show completions when we have narrowed all 
> > +posibilities down to a maximum of 'semantic-complete-inline-max-tags'
> > +tags. Pressing TAB multiple times will also show completions."
> > +  :group 'semantic
> > +  :type 'boolean
> > +  :set '(lambda (sym var)
> > +            (set-default sym var)
> > +	    (setq semantic-complete-inline-mode-standard nil)
> > +	    (setq semantic-complete-inline-mode-verbose nil)
> > +	    (if var (setq semantic-complete-inline-mode -1))))
> 
> I did change that, since you usually implement those kinds of 'radio
> button' behavior by using the 'choice' type and one variable. I also
> renamed all variables to make clear that they're related to the tooltip
> class. Most of my other changes were small and shouldn't touch the
> actual code you did, but please try it out.

brilliant thank you. the switch/radio/'choice' is exactly what i wanted to do, 
but i simply couldn't work out how to do it.

> 
> A few more remarks:
> 
> - Use 'delete-trailing-whitespace' to, well, delete trailing
>   whitespaces. 
> 
> - doc-strings are expected to have a certain style in Emacs. For
>   example, the first line should be a sentence describing the
>   function. Also, all documentation in Emacs uses 'sentence spacing',
>   meaning that there should be two whitespaces between sentences. (You
>   can run 'checkdoc' to check your doc-strings and other stuff).
> 
> - You don't have to use 'progn' in the "else"-branch of an 'if'.
> 

many thanks for the tips, i will apply all of them going forward.

on the last point though, i think i do remember deliberately adding a 
few superfluous progn forms to try and make the larger else blocks 
more readable ..a more 'prominent' marker in the sea of parenthesis 
helps when you have a mismatch (well i know what i mean here even if 
nobody else is following ;D). clearly frowned upon though.

anyway, fingers crossed the changes don't break the ideals of 'how it 
should work' for anybody but if it does turn out to be the case, i'll 
have another look at it. i do want to improve it further (time-
permitting) ..for example, in playing with it just now it's clear that 
there should at least be the option to let 'backspace' cancel the 
current 'completion session', as now, backspacing many times is painful 
having effectively removed the previous (incomplete) caching actions. 
it's fast going forwards but slow going backwards.

again, thanks for your help 'living the FSF dream'..

Pete.

Pete Beardmore writes:
> on the last point though, i think i do remember deliberately adding a 
> few superfluous progn forms to try and make the larger else blocks 
> more readable ..a more 'prominent' marker in the sea of parenthesis 
> helps when you have a mismatch (well i know what i mean here even if 
> nobody else is following ;D). clearly frowned upon though.

I agree the different branches of `if' statements can sometimes be hard
to spot. This is why if there actually is no 'else'-branch, you should
always use `when' or `unless' instead of `if', so at least that becomes
immediately clear (that's just my opinion and by no means an "official"
rule).

> anyway, fingers crossed the changes don't break the ideals of 'how it 
> should work' for anybody but if it does turn out to be the case, i'll 
> have another look at it. i do want to improve it further (time-
> permitting) ..for example, in playing with it just now it's clear that 
> there should at least be the option to let 'backspace' cancel the 
> current 'completion session', as now, backspacing many times is painful 
> having effectively removed the previous (incomplete) caching actions. 
> it's fast going forwards but slow going backwards.

Yes, I noticed that. I usually use backward-kill-word if I'm completely
off, so it didn't bother me at least.

-David