Alex Ott | 1 May 2012 10:47
Picon
Gravatar

Re: Merge of 'newtrunk' branch

Hello David

I found one error with autoloads, and not sure how to fix it - can you
look onto it?

I have code in my cedet config in following form:

(when (cedet-ectag-version-check t)
  (require 'semantic/ectags/db)
  (semantic-load-enable-primary-ectags-support))

When I start Emacs, I get following error:

Debugger entered--Lisp error: (file-error "Cannot open load file" "ectags/util")
  (cedet-ectag-version-check t)
  (if (cedet-ectag-version-check t) (progn (require (quote
semantic/ectags/db)) (semantic-load-enable-primary-ectags-support)))
  (when (cedet-ectag-version-check t) (require (quote
semantic/ectags/db)) (semantic-load-enable-primary-ectags-support))
  eval-buffer(#<buffer  *load*≤2>> nil
"/Users/ott/emacs/rc/emacs-rc-cedet.el" nil t)  ; Reading at buffer
position 2885
  load-with-code-conversion("/Users/ott/emacs/rc/emacs-rc-cedet.el"
"/Users/ott/emacs/rc/emacs-rc-cedet.el" nil nil)
  load("~/emacs/rc/emacs-rc-cedet.el")
  eval-buffer(#<buffer  *load*≥ nil "/Users/ott/.emacs" nil t)  ;
Reading at buffer position 784
  load-with-code-conversion("/Users/ott/.emacs" "/Users/ott/.emacs" t t)
  load("~/.emacs" t t)
....
(Continue reading)

David Engster | 1 May 2012 14:11
Picon

Re: Merge of 'newtrunk' branch

Alex Ott writes:
> It looks like loaddefs aren't correctly generated. I checked
> semantic/loaddefs.el, and `cedet-ectag-version-check' function exists
> there, but it marked as

Yes, ones has to override `generated-autoload-load-name' in the local
variables section of the file, which I forgot to do. This is now fixed
in trunk.

> (when (cedet-ectag-version-check t)
>   (require 'semantic/ectags/db)
>   (semantic-load-enable-primary-ectags-support))

That require in there shouldn't be necessary. If you see that you need
to require packages to call end-user functions, please report this as a
bug.

Thanks,
David

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Alex Ott | 1 May 2012 15:29
Picon
Gravatar

Re: Merge of 'newtrunk' branch

Thank you David!

On Tue, May 1, 2012 at 2:11 PM, David Engster <deng <at> randomsample.de> wrote:
> Alex Ott writes:
>> It looks like loaddefs aren't correctly generated. I checked
>> semantic/loaddefs.el, and `cedet-ectag-version-check' function exists
>> there, but it marked as
>
> Yes, ones has to override `generated-autoload-load-name' in the local
> variables section of the file, which I forgot to do. This is now fixed
> in trunk.
>
>> (when (cedet-ectag-version-check t)
>>   (require 'semantic/ectags/db)
>>   (semantic-load-enable-primary-ectags-support))
>
> That require in there shouldn't be necessary. If you see that you need
> to require packages to call end-user functions, please report this as a
> bug.
>
> Thanks,
> David

--

-- 
With best wishes,                    Alex Ott
http://alexott.net/
Tiwtter: alexott_en (English), alexott (Russian)
Skype: alex.ott

------------------------------------------------------------------------------
(Continue reading)

David Engster | 2 May 2012 21:49
Picon

Re: Merge of 'newtrunk' branch

David Engster writes:
> Alex Ott writes:
>> On Thu, Apr 26, 2012 at 10:11 PM, David Engster <deng <at> randomsample.de> wrote:
>>> Ilya Zonov writes:
>>>> I found that function 'semantic-ia-complete-symbol-menu'
>>>> (/lisp/cedet/semantic/
>>>> ia.el) is not available at last revision. It seems this function was removed
>>>> after sync with Emacs. Will this function be returned back?
>>>
>>> Yes, it was removed in Emacs. I'm not sure, but my guess is that it was
>>> removed because it depends on Senator, and we wanted to get rid of that
>>> one, hence I don't think we should bring it back.
>>
>> It's good idea to remove something, but this function is often used,
>> as I see, and its removal, without providing alternatives out-of-box,
>> is pretty bad idea :-(
>
> This is CEDET-bzr, anything can happen. ;-)
>
> I see that Senator is actually still in Emacs trunk, so I'm at a loss
> why the above function was removed. Eric, do you know? Otherwise I'll
> ask Yidong.

OK, I've brought the function back with a 'do not merge' notice.

The different completion tools in CEDET are... confusing. We have the
semantic-ia-complete-symbol/menu/tip functions, which (I'm guessing)
predate semantic-complete-analyze-inline, which is configured through
`semantic-complete-inline-analyzer-displayor-class' (phew...). The
semantic-complete package is more powerful but doesn't have that neat
(Continue reading)

Alex Ott | 2 May 2012 21:53
Picon
Gravatar

Re: Merge of 'newtrunk' branch

Thank you David

I also installed autocomplete and trying to use it together with
Semantic, although maybe I'll need to experiment with semantic-only
backend, etc.

On Wed, May 2, 2012 at 9:49 PM, David Engster <deng <at> randomsample.de> wrote:
> David Engster writes:
>> Alex Ott writes:
>>> On Thu, Apr 26, 2012 at 10:11 PM, David Engster <deng <at> randomsample.de> wrote:
>>>> Ilya Zonov writes:
>>>>> I found that function 'semantic-ia-complete-symbol-menu'
>>>>> (/lisp/cedet/semantic/
>>>>> ia.el) is not available at last revision. It seems this function was removed
>>>>> after sync with Emacs. Will this function be returned back?
>>>>
>>>> Yes, it was removed in Emacs. I'm not sure, but my guess is that it was
>>>> removed because it depends on Senator, and we wanted to get rid of that
>>>> one, hence I don't think we should bring it back.
>>>
>>> It's good idea to remove something, but this function is often used,
>>> as I see, and its removal, without providing alternatives out-of-box,
>>> is pretty bad idea :-(
>>
>> This is CEDET-bzr, anything can happen. ;-)
>>
>> I see that Senator is actually still in Emacs trunk, so I'm at a loss
>> why the above function was removed. Eric, do you know? Otherwise I'll
>> ask Yidong.
>
(Continue reading)

David Engster | 2 May 2012 21:58
Picon

Re: Merge of 'newtrunk' branch

Alex Ott writes:
> Thank you David
>
> I also installed autocomplete and trying to use it together with
> Semantic, although maybe I'll need to experiment with semantic-only
> backend, etc.

Yes, I would recommend to use

(setq-default ac-sources '(ac-source-semantic-raw))

to really only get Semantic completions. I would also recommend to
choose a longer delay until auto-complete triggers, otherwise it can
easily become quite annoying.

-David

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Eric M. Ludlam | 3 May 2012 00:32
Picon
Gravatar

Re: Merge of 'newtrunk' branch

On 05/02/2012 03:49 PM, David Engster wrote:
> David Engster writes:
[...]
>> I see that Senator is actually still in Emacs trunk, so I'm at a loss
>> why the above function was removed. Eric, do you know? Otherwise I'll
>> ask Yidong.
>
> OK, I've brought the function back with a 'do not merge' notice.
>
> The different completion tools in CEDET are... confusing. We have the
> semantic-ia-complete-symbol/menu/tip functions, which (I'm guessing)
> predate semantic-complete-analyze-inline, which is configured through

All the semantic-ia functions were meant as examples, showing how to 
write a simple function using the semantic backend to do the heavy 
lifting.  The point being to help folks writing a nice completion ui 
something to try out.

That took a long time though, so enhancements went in making them not so 
simple. ;)

> `semantic-complete-inline-analyzer-displayor-class' (phew...). The
> semantic-complete package is more powerful but doesn't have that neat
> menu-style completion from the semantic-ia package. Instead, it has this
> 'ghosting' style and tooltips. I guess the semantic-ia-complete
> functions should be deprecated some day and moved to semantic-complete?

The primary complexity in the semantic-complete function is performance, 
recycling as much data as possible between requests within a particular 
completion edit session.  ie. handling multiple completion requests on a 
(Continue reading)

David Engster | 3 May 2012 22:06
Picon

New mozrepl backend for Semantic

For you Javascript coders out there this should be fairly interesting. I
added a semanticdb omniscience database using mozrepl, which is a
Firefox extension providing access to a running session. I've written
more about it here, also covering installation and the different
completion solutions that are currently available:

http://www.randomsample.de/dru5/node/147

Cheers,
David

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Daniel Hackney | 4 May 2012 07:02
Favicon
Gravatar

Re: Making listing buffers (data-debug and symref) read-only

Eric M. Ludlam <ericludlam <at> gmail.com> wrote:
> On 04/20/2012 07:02 PM, Daniel Hackney wrote:
>>
>> I have a branch which makes these two buffers read-only, so they don't get
>> junk
>> written to them in the form of self-inserting keys. After a long fight
>> with
>> Bazaar, I have a branch here:
>>
>> lp:~haxney/+junk/listing-buffers-read-only
>>
>> Rather than using `toggle-read-only', which the documentation says is bad
>> form
>> in an elisp program, I used `buffer-read-only' and `inhibit-read-only' to
>> achieve the desired effect. Also, I made sure the buffers do not show up
>> as
>> modified when sections are expanded and collapsed.
>
>
> I like this idea based on your description, but don't know how to access the
> location you provided.  If the patch is short (in terms of new code lines)
> we can include it, otherwise we may need a release from you for this work.

Any progress on this? Once again, the bzr URL is:

  http://bazaar.launchpad.net/~haxney/%2Bjunk/listing-buffers-read-only/

Consider this a friendly, gentle poke :)

--
(Continue reading)

Eric Ludlam | 4 May 2012 13:02
Picon
Gravatar

Re: Making listing buffers (data-debug and symref) read-only

  On 05/04/2012 01:02 AM, Daniel Hackney wrote:
> Eric M. Ludlam<ericludlam <at> gmail.com>  wrote:
>> On 04/20/2012 07:02 PM, Daniel Hackney wrote:
>>> I have a branch which makes these two buffers read-only, so they don't get
>>> junk
>>> written to them in the form of self-inserting keys. After a long fight
>>> with
>>> Bazaar, I have a branch here:
>>>
>>> lp:~haxney/+junk/listing-buffers-read-only
>>>
>>> Rather than using `toggle-read-only', which the documentation says is bad
>>> form
>>> in an elisp program, I used `buffer-read-only' and `inhibit-read-only' to
>>> achieve the desired effect. Also, I made sure the buffers do not show up
>>> as
>>> modified when sections are expanded and collapsed.
>>
>> I like this idea based on your description, but don't know how to access the
>> location you provided.  If the patch is short (in terms of new code lines)
>> we can include it, otherwise we may need a release from you for this work.
> Any progress on this? Once again, the bzr URL is:
>
>    http://bazaar.launchpad.net/~haxney/%2Bjunk/listing-buffers-read-only/
>
> Consider this a friendly, gentle poke :)

I haven't gotten anywhere on pretty much anything in a few weeks as my 
hacking machine is currently in my livingroom as a mythtv experiment.  
Hacking code on the TV is kind of sucky, even if the couch is comfy.  
(Continue reading)


Gmane