headers
Mike Hearn | 2 Jun 2004 15:18

Inline Completion question

Hi,

After a bit of fiddling I got completion working with semantic. It's
really nice, thanks!

Two questions though: 

1) Why does semantic-complete-analyze-inline require at least one
character in order to work when semantic-ia-complete-symbol-menu does not?

2) Why does semantic-complete-analyze-inline refuse to simply type the
rest of the symbol when there is only one possible completion. Currently
it just says "No inline completion necessary" or something like that ...

thanks -mike

-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
Permalink | Reply | 2 comments |
headers
Eric M. Ludlam | 7 Jun 2004 21:55
Gravatar

DOS line endings

David,

Paul K. noticed that semantic-grammar-wy.el had DOS line endings in
his build area.  I double checked my build area, and found that same
file (the one I built the dist from) was utf-8 encoding.

Could you add something to the parser generator that would force
generated files to have unix line endings, which Emacs seems capable
of handling on diverse systems?

Thanks
Eric

--

-- 
          Eric Ludlam:                 zappo <at> gnu.org, eric <at> siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
Permalink | Reply | 2 comments |
headers
David Ponce | 7 Jun 2004 22:31
Picon

Re: DOS line endings

Hi Eric,

> Paul K. noticed that semantic-grammar-wy.el had DOS line endings in
> his build area.  I double checked my build area, and found that same
> file (the one I built the dist from) was utf-8 encoding.

I think the line endings depend on the OS Emacs was running on, when the -wy.el file was
generated.  I think Paul run Emacs on MS-Windows so generated files have DOS line endings
for him.

On my build area (GNU Emacs 21.3 on GNU/Linux) semantic-grammar-wy.el coding system is:

- -- undecided-unix

No conversion on encoding, automatic conversion on decoding

Type: t (do automatic conversion)
EOL type: LF
This coding system encodes the following charsets:
   ascii

I can't see why yours is utf-8 encoding.

> Could you add something to the parser generator that would force
> generated files to have unix line endings, which Emacs seems capable
> of handling on diverse systems?

What is the problem with line endings?  Emacs is capable of handling Unix/DOS/Mac
line endings on any OS it runs.  And I am not sure it is a good practice to
generate files with different line endings than the OS default.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric M. Ludlam | 7 Jun 2004 23:43
Gravatar

Re[2]: DOS line endings

>>> David Ponce <david.ponce <at> wanadoo.fr> seems to think that:
>Hi Eric,
>
>> Paul K. noticed that semantic-grammar-wy.el had DOS line endings in
>> his build area.  I double checked my build area, and found that same
>> file (the one I built the dist from) was utf-8 encoding.
>
>I think the line endings depend on the OS Emacs was running on, when the -wy.el file was
>generated.  I think Paul run Emacs on MS-Windows so generated files have DOS line endings
>for him.
>
>On my build area (GNU Emacs 21.3 on GNU/Linux) semantic-grammar-wy.el coding system is:
>
>- -- undecided-unix
>
>No conversion on encoding, automatic conversion on decoding
>
>Type: t (do automatic conversion)
>EOL type: LF
>This coding system encodes the following charsets:
>   ascii
>
>I can't see why yours is utf-8 encoding.
>
>> Could you add something to the parser generator that would force
>> generated files to have unix line endings, which Emacs seems capable
>> of handling on diverse systems?
>
>What is the problem with line endings?  Emacs is capable of handling Unix/DOS/Mac
>line endings on any OS it runs.  And I am not sure it is a good practice to
(Continue reading)

Permalink | Reply | 0 comments |
headers
David PONCE | 8 Jun 2004 09:00
Picon

Re: DOS line endings

Hello Eric,

[...]
> That is true for text files.  The files we are talking about are
> Emacs specific files.  This line-ending thing could be the problem
> some folks bump into that is fixed by the "make clean; make" process,
> but no one had debugged.  (For files generated by autoloads, or from
> the parser.)

Generated loaddefs files always have Unix line endings, so I doubt it
is the problem.  IMO, it looks more like an obscure compatibility
problem between Emacs and XEmacs, and I am not sure we can really
solve it (that is, generate true [X]Emacs-independent loaddefs files).
I think it is far better (and easy) to always use "make
clean-autoloads; make".  This is also why I am not in favor of
including pre-built loaddefs files in the distribution ;-)

> If forcing the line ending change stops all the "I can't build" email,
> then I think it would be worth the platform unspecified output.
> 
> I'm not entirely certain what build problems there are and what the
> current state in CVS is.  I could be way off base.  Paul just happens
> to be the first to make this observation.

OK.  I fixed semantic-grammar.el so that now generated *-[wb]y.el files
have LF line endings.

David

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

Permalink | Reply | 1 comment |
headers
Eric M. Ludlam | 8 Jun 2004 13:57
Gravatar

Re[2]: DOS line endings

>>> David PONCE <david.ponce <at> wanadoo.fr> seems to think that:
>Hello Eric,
>
>[...]
>> That is true for text files.  The files we are talking about are
>> Emacs specific files.  This line-ending thing could be the problem
>> some folks bump into that is fixed by the "make clean; make" process,
>> but no one had debugged.  (For files generated by autoloads, or from
>> the parser.)
>
>Generated loaddefs files always have Unix line endings, so I doubt it
>is the problem.  IMO, it looks more like an obscure compatibility
>problem between Emacs and XEmacs, and I am not sure we can really
>solve it (that is, generate true [X]Emacs-independent loaddefs files).
>I think it is far better (and easy) to always use "make
>clean-autoloads; make".  This is also why I am not in favor of
>including pre-built loaddefs files in the distribution ;-)

Should we make that a default or something?  ie, "make" would include
"make clean-autoloads" from the CEDET directory.  Or perhaps as Emacs
does, "make bootstrap" could do that.

>> If forcing the line ending change stops all the "I can't build" email,
>> then I think it would be worth the platform unspecified output.
>> 
>> I'm not entirely certain what build problems there are and what the
>> current state in CVS is.  I could be way off base.  Paul just happens
>> to be the first to make this observation.
>
>OK.  I fixed semantic-grammar.el so that now generated *-[wb]y.el files
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berndl, Klaus | 8 Jun 2004 16:28
Picon

RE: Re[2]: DOS line endings


>>Generated loaddefs files always have Unix line endings, so I doubt it
>>is the problem.  IMO, it looks more like an obscure compatibility
>>problem between Emacs and XEmacs, and I am not sure we can really
>>solve it (that is, generate true [X]Emacs-independent loaddefs files).
>>I think it is far better (and easy) to always use "make
>>clean-autoloads; make".  This is also why I am not in favor of
>>including pre-built loaddefs files in the distribution ;-)

>Should we make that a default or something?  ie, "make" would include
>"make clean-autoloads" from the CEDET directory.  Or perhaps as Emacs
>does, "make bootstrap" could do that.

yes, this would be fine - i would second this.

Klaus

-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
Permalink | Reply | 0 comments |
headers
David PONCE | 8 Jun 2004 16:54
Picon

Re: DOS line endings

[...]
> Should we make that a default or something?  ie, "make" would include
> "make clean-autoloads" from the CEDET directory.  Or perhaps as Emacs
> does, "make bootstrap" could do that.
[...]

Do you mean to add "clean-autoloads" as the first dependency of the
default "all" target in the main CEDET Makefile?

If so, what is the point of including default loaddefs files in the
distribution, as they will be first deleted by "make"?

About "make bootstrap", it is a good idea.  However, it would probably
make more sense to have it equivalent to "make clean-all; make", to do
a full rebuild of all generated files.  WDYT?

David

-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
Permalink | Reply | 1 comment |
headers
David PONCE | 9 Jun 2004 10:19
Picon

Re: query-replace-string broken in .java buffers, jde2.3.3

Hi Eric,

__ I moved this discussion to cedet-devel to avoid polluting the JDEE
   ML with consideration about CEDET internals ;-) __

[...]
>>Please, could you try the following patch to semantic-edit.el that
>>makes `semantic-edits-incremental-parser' distinguish between expected
>>incremental parse failures, that schedule a full re-parse, and other
>>unexpected errors which shouldn't be caught, in order to produce a
>>backtrace when `debug-on-error' is set.
>>
>>Eric, WDYT of that patch?  Is it worth committing it?
> 
>   [ ... ]
> 
> That does sound helpful.  Thanks!

I checked the patch in.

> Should it use 'semantic-safe' the fling signals?
> 
> Should the condition-case change to only accept the new
> 'semantic-parse-changes-failed' signal?

I am not sure to understand.  The patch changed the `condition-case'
to only accept expected `semantic-parse-changes-failed' conditions,
that schedule a full re-parse.  For now true errors are not handled.
Probably we could use `semantic-safe' to catch those errors and issue
a message when `debug-on-error' is not set.  Is that what you meant?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric M. Ludlam | 9 Jun 2004 13:54
Gravatar

Re[2]: query-replace-string broken in .java buffers, jde2.3.3

>>> David PONCE <david.ponce <at> wanadoo.fr> seems to think that:
>Hi Eric,
>
>__ I moved this discussion to cedet-devel to avoid polluting the JDEE
>   ML with consideration about CEDET internals ;-) __
>
>[...]
>>>Please, could you try the following patch to semantic-edit.el that
>>>makes `semantic-edits-incremental-parser' distinguish between expected
>>>incremental parse failures, that schedule a full re-parse, and other
>>>unexpected errors which shouldn't be caught, in order to produce a
>>>backtrace when `debug-on-error' is set.
>>>
>>>Eric, WDYT of that patch?  Is it worth committing it?
>> 
>>   [ ... ]
>> 
>> That does sound helpful.  Thanks!
>
>I checked the patch in.
>
>> Should it use 'semantic-safe' the fling signals?
>> 
>> Should the condition-case change to only accept the new
>> 'semantic-parse-changes-failed' signal?
>
>I am not sure to understand.  The patch changed the `condition-case'
>to only accept expected `semantic-parse-changes-failed' conditions,

You are right.  I misinterpreted a chunk of the patch.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane