Sorry, I couldn't understand from the discussion how this issue can be fixed in Emacs. Currently, I'm getting the following kind of errors in the expanded minibuffer when there are some syntax errors:
ModuleSyntaxError: Syntax error in file <tests/test_collector.py> line <266>: Syntax errors in file tests/test_collector.py: * line 266: unexpected indent ... fixed * line 266: unexpected indent ... fixed * line 266: unexpected indent ... fixed * line 266: unexpected indent ... fixed * line 266: unexpected indent ... fixed * line 266: unexpected indent ... fixed * line 266: unexpected indent ... fixed * line 266: unexpected indent ... fixed * line 266: unexpected indent ... fixed * line 266: unexpected indent ... raised!
Could you please clarify for me how these errors can be hidden or reduced to one line in Emacs?
On Monday, 26 March 2012 06:38:42 UTC+11, aligrudi wrote:
> Takafumi Arakaki <aka...@gmail.com <javascript:>> wrote: > > > When there is no completion, signal an error is good but a multi-line > > > error message is not because it causes the minibuffer to enlarge which > > > is visually disturbing.
> > Yes, that's exactly why I wanted to send the patches.
> I think it is better to change rope/contrib/fixerror.py, since AFAIR, > it is the only place we use multi-line short exception messages.
Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> Sorry, I couldn't understand from the discussion how this issue can be > fixed in Emacs. Currently, I'm getting the following kind of errors in the > expanded minibuffer when there are some syntax errors:
I meant something like this patch for rope. Not tested, so it
may need to be tweaked to work.
On Friday, 24 August 2012 09:41:44 UTC+10, Leo wrote:
> On 2012-08-23 21:59 +0800, Ali Gholami Rudi wrote: > > I meant something like this patch for rope. Not tested, so it > > may need to be tweaked to work.
> Note that Pymacs (0.25 and above) no longer prints the whole backtrace > unless debug-on-error is non-nil.
Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> Thanks for your replies! Is there any issue with incorporating this fix > into the main branch of rope?
I think that's a good idea. Did you test it?
> On Friday, 24 August 2012 09:41:44 UTC+10, Leo wrote:
> > Note that Pymacs (0.25 and above) no longer prints the whole backtrace > > unless debug-on-error is non-nil.
I don't think that would help, since we do want the error
message but the message is too long; codeassist syntax
errors have multi-line messages, each line describing an
attempt to fix the error. The patch in my previous
mail made it less verbose.
Sorry for the delay. I've tested your patch: the error message has got
indeed reduced into one line. However, the mini buffer still expands into
multiple lines for some reason. Here is a screenshot:
http://i.imgbox.com/ady0ackX.jpg
Do you know what could be the reason for such behavior?
Thanks,
Anton
On Fri, Aug 24, 2012 at 12:09 PM, Ali Gholami Rudi <aligr...@gmail.com>wrote:
> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> > Thanks for your replies! Is there any issue with incorporating this fix
> > into the main branch of rope?
> I think that's a good idea. Did you test it?
> > On Friday, 24 August 2012 09:41:44 UTC+10, Leo wrote:
> > > Note that Pymacs (0.25 and above) no longer prints the whole backtrace
> > > unless debug-on-error is non-nil.
> I don't think that would help, since we do want the error
> message but the message is too long; codeassist syntax
> errors have multi-line messages, each line describing an
> attempt to fix the error. The patch in my previous
> mail made it less verbose.
Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> Sorry for the delay. I've tested your patch: the error message has got
> indeed reduced into one line. However, the mini buffer still expands into
> multiple lines for some reason. Here is a screenshot:
> http://i.imgbox.com/ady0ackX.jpg
> Do you know what could be the reason for such behavior?
Odd... Does the included patch make any difference.
> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> > Sorry for the delay. I've tested your patch: the error message has got
> > indeed reduced into one line. However, the mini buffer still expands into
> > multiple lines for some reason. Here is a screenshot:
> > http://i.imgbox.com/ady0ackX.jpg
> > Do you know what could be the reason for such behavior?
> Odd... Does the included patch make any difference.
I've just found that this message is popped up by eldoc-mode. I'm
using rope-get-calltip as eldoc-documentation-function. Due to syntax
errors, it failed all the time and displayed that message. To fix this,
I've modified the get_calltip function in rope/contrib/codeassist.py. Here
is the patch:
Now it just displays nothing if there is a syntax error, which I think is
reasonable for this purpose. Otherwise, it continuously shows up error
messages, which is very annoying.
Thanks,
Anton
On Tue, Aug 28, 2012 at 11:42 AM, Anton Beloglazov <
anton.belogla...@gmail.com> wrote:
> Thanks, Ali. Unfortunately, this has not fixed the problem. Here is a new
> screenshot: http://i.imgbox.com/abvW3Bjc.jpg
> Best regards,
> Anton
> On Tue, Aug 28, 2012 at 1:05 AM, Ali Gholami Rudi <aligr...@gmail.com>wrote:
>> Hi,
>> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
>> > Sorry for the delay. I've tested your patch: the error message has got
>> > indeed reduced into one line. However, the mini buffer still expands
>> into
>> > multiple lines for some reason. Here is a screenshot:
>> > http://i.imgbox.com/ady0ackX.jpg
>> > Do you know what could be the reason for such behavior?
>> Odd... Does the included patch make any difference.
> I've just found that this message is popped up by eldoc-mode. I'm
> using rope-get-calltip as eldoc-documentation-function. Due to syntax
> errors, it failed all the time and displayed that message. To fix this,
> I've modified the get_calltip function in rope/contrib/codeassist.py. Here
> is the patch:
> Now it just displays nothing if there is a syntax error, which I think is
> reasonable for this purpose. Otherwise, it continuously shows up error
> messages, which is very annoying.
> Thanks,
> Anton
> On Tue, Aug 28, 2012 at 11:42 AM, Anton Beloglazov <
> anton.belogla...@gmail.com> wrote:
>> On Tue, Aug 28, 2012 at 1:05 AM, Ali Gholami Rudi <aligr...@gmail.com>wrote:
>>> Hi,
>>> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
>>> > Sorry for the delay. I've tested your patch: the error message has got
>>> > indeed reduced into one line. However, the mini buffer still expands
>>> into
>>> > multiple lines for some reason. Here is a screenshot:
>>> > http://i.imgbox.com/ady0ackX.jpg
>>> > Do you know what could be the reason for such behavior?
>>> Odd... Does the included patch make any difference.
Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> I had to make a similar fix in the _code_completions function to suppress
> the error reporting during auto-completion. The updated patch is below:
I'm wondering if it is a good idea to make a distinction between
ropemode commands and functions; for instance between rope-show-doc
and rope-get-doc; the former is a command in ropemacs/ropevim, while
the latter is a function that can be used in external commands. If an
error happens when performing a command, I think the user expects an
error message (my fixsyntax.py patch makes one such error more compact,
so I think it would be still useful). But functions are invoked from
elisp/vimscript and instead of breaking the call chain by throwing
an exception, I think it is a better idea to return a special value.
This is what your patches did, but I think that could be improved.
At the moment both commands and functions are specified using the
local_command decorator in ropemode/interface.py. I suggest adding a
local_function decorator in ropemode/decorators.py whose only argument is
the value to return if an interrupt occurs, as in the included untested
patch. What do you think? Is the default return value of completions
and extended_completions acceptable?
Nice generalization! I've tested your patch, and with a couple of
modifications it works fine. I've added 'return' in the local_function
definition, and made get_calltip a local_function as well. Here are the
updated patches:
> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> > I had to make a similar fix in the _code_completions function to suppress
> > the error reporting during auto-completion. The updated patch is below:
> I'm wondering if it is a good idea to make a distinction between
> ropemode commands and functions; for instance between rope-show-doc
> and rope-get-doc; the former is a command in ropemacs/ropevim, while
> the latter is a function that can be used in external commands. If an
> error happens when performing a command, I think the user expects an
> error message (my fixsyntax.py patch makes one such error more compact,
> so I think it would be still useful). But functions are invoked from
> elisp/vimscript and instead of breaking the call chain by throwing
> an exception, I think it is a better idea to return a special value.
> This is what your patches did, but I think that could be improved.
> At the moment both commands and functions are specified using the
> local_command decorator in ropemode/interface.py. I suggest adding a
> local_function decorator in ropemode/decorators.py whose only argument is
> the value to return if an interrupt occurs, as in the included untested
> patch. What do you think? Is the default return value of completions
> and extended_completions acceptable?
Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> Nice generalization! I've tested your patch, and with a couple of
> modifications it works fine. I've added 'return' in the local_function
> definition, and made get_calltip a local_function as well. Here are the
> updated patches:
I've CC'ed Anton Gritsay, the maintainer. Anton, what do you think?
I think this patch and also my patch to make fixsyntax.py errors terser
(I've included the latter in this mail) look acceptable.
> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
>> Nice generalization! I've tested your patch, and with a couple of
>> modifications it works fine. I've added 'return' in the local_function
>> definition, and made get_calltip a local_function as well. Here are the
>> updated patches:
Anton, could you please explain me the semantic difference between
local function and local command? It is also not clear for me why did
you use singleton object for triggering "return on error" behaviour in
_exception_handler(). Could it not be just boolean function parameter
with default to False?
And one more thing: how do I test if it works as it should? What are
steps to reproduce the problem?
> I've CC'ed Anton Gritsay, the maintainer. Anton, what do you think?
> I think this patch and also my patch to make fixsyntax.py errors terser
> (I've included the latter in this mail) look acceptable.
The separation of local function and local command has been proposed by Ali
in one of the previous emails. The idea is that commands are supposed to be
directly executed by the user expecting to see an error message when
something goes wrong. On the other hand, functions are supposed to be used
programmatically inside other external commands, in which case it's more
convenient to just return a special value (specified as a parameter)
instead of throwing an exception.
An example of the latter case is rope-get-calltip function in Emacs, which
can be directly passed to Eldoc as eldoc-documentation-function. Throwing
an exception in case of a syntax error brakes Eldoc, which just expects to
get nil when there is no information available for displaying. This can be
reproduced as follows:
Then open a Python file, make a Python syntax error: currently, an
exception is shown in the echo area. After applying the patch, in case of a
syntax error nothing is displayed.
Another example is integration with the auto-complete mode, which I set up
as follows:
The test is similar, currently when there is a Python syntax error
auto-complete breaks and displays an exception in the echo area. After the
patch, nothing is displayed in the echo area in case of a Python syntax
error. This is desirable by the user (from my point of view), since such
messages just disturb the user, while there are other special means to
report syntax errors, such as flymake-mode.
Regarding the "return on error" behavior, that is the implementation
proposed by Ali, I've just adopted it. Perhaps, Ali could explain his
choice of a singleton object over a boolean variable. To me, it seems that
a boolean parameter would work just as well.
On Thu, Aug 30, 2012 at 9:31 AM, <an...@angri.ru> wrote:
> Hi Ali, Anton,
> 2012/8/29 Ali Gholami Rudi <aligr...@gmail.com>:
> > Hi,
> > Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> >> Nice generalization! I've tested your patch, and with a couple of
> >> modifications it works fine. I've added 'return' in the local_function
> >> definition, and made get_calltip a local_function as well. Here are the
> >> updated patches:
> Anton, could you please explain me the semantic difference between
> local function and local command? It is also not clear for me why did
> you use singleton object for triggering "return on error" behaviour in
> _exception_handler(). Could it not be just boolean function parameter
> with default to False?
> And one more thing: how do I test if it works as it should? What are
> steps to reproduce the problem?
> > I've CC'ed Anton Gritsay, the maintainer. Anton, what do you think?
> > I think this patch and also my patch to make fixsyntax.py errors terser
> > (I've included the latter in this mail) look acceptable.
Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> Regarding the "return on error" behavior, that is the implementation
> proposed by Ali, I've just adopted it. Perhaps, Ali could explain his
> choice of a singleton object over a boolean variable. To me, it seems that
> a boolean parameter would work just as well.
Actually the error_return parameter is the value to return on errors.
I added a similar parameter to local_command() mainly for implementing
local_function(). But then to retain the old behavior, I needed
to somehow tell local_command() to re-raise an exception instead of
returning a value. I could have added a new boolean parameter like
reraise_exceptions, which, when False, forced the value of the new
error_return parameter to be returned. This would have required adding
two new parameters to local_command(), one of which was dependent
on the other; i.e. error_return would have been meaningful only if
reraise_exceptions was False.
I decided to merge the arguments: when exceptions are caught, the value
passed as error_return should be returned, unless it is log_errors (maybe
reraise_errors is a better name). I added the log_errors singleton
because I couldn't tell if any other value (like None) is meant to
be returned on errors or is meant to request re-raising exceptions.
I thought this is the common practice in such cases, but maybe I'm among
the few who used to use this technique (or hack, probably).
I suggest either adding comments for this new parameter and the new
global variable or using the double parameter approach. Unless, of
course, someone has a cleaner solution.
Thanks for the explanation! In my opinion, the two parameter approach is
easier to understand since it's more explicit and doesn't require any
special values.
Thanks,
Anton
On Fri, Aug 31, 2012 at 12:22 AM, Ali Gholami Rudi <aligr...@gmail.com>wrote:
> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> > Regarding the "return on error" behavior, that is the implementation
> > proposed by Ali, I've just adopted it. Perhaps, Ali could explain his
> > choice of a singleton object over a boolean variable. To me, it seems
> that
> > a boolean parameter would work just as well.
> Actually the error_return parameter is the value to return on errors.
> I added a similar parameter to local_command() mainly for implementing
> local_function(). But then to retain the old behavior, I needed
> to somehow tell local_command() to re-raise an exception instead of
> returning a value. I could have added a new boolean parameter like
> reraise_exceptions, which, when False, forced the value of the new
> error_return parameter to be returned. This would have required adding
> two new parameters to local_command(), one of which was dependent
> on the other; i.e. error_return would have been meaningful only if
> reraise_exceptions was False.
> I decided to merge the arguments: when exceptions are caught, the value
> passed as error_return should be returned, unless it is log_errors (maybe
> reraise_errors is a better name). I added the log_errors singleton
> because I couldn't tell if any other value (like None) is meant to
> be returned on errors or is meant to request re-raising exceptions.
> I thought this is the common practice in such cases, but maybe I'm among
> the few who used to use this technique (or hack, probably).
> I suggest either adding comments for this new parameter and the new
> global variable or using the double parameter approach. Unless, of
> course, someone has a cleaner solution.
Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> Thanks for the explanation! In my opinion, the two parameter approach is
> easier to understand since it's more explicit and doesn't require any
> special values.
> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> > Thanks for the explanation! In my opinion, the two parameter approach is
> > easier to understand since it's more explicit and doesn't require any
> > special values.
> On Fri, Aug 31, 2012 at 7:57 PM, Ali Gholami Rudi <aligr...@gmail.com>wrote:
>> Hi Anton,
>> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
>> > Thanks for the explanation! In my opinion, the two parameter approach is
>> > easier to understand since it's more explicit and doesn't require any
>> > special values.
>> That's OK with me and please update your patch.
>> On Fri, Aug 31, 2012 at 7:57 PM, Ali Gholami Rudi <aligr...@gmail.com>wrote:
>>> Hi Anton,
>>> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
>>> > Thanks for the explanation! In my opinion, the two parameter approach
>>> is
>>> > easier to understand since it's more explicit and doesn't require any
>>> > special values.
>>> That's OK with me and please update your patch.
>>> On Fri, Aug 31, 2012 at 7:57 PM, Ali Gholami Rudi <aligr...@gmail.com>
>>> wrote:
>>>> Hi Anton,
>>>> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
>>>> > Thanks for the explanation! In my opinion, the two parameter approach
>>>> > is
>>>> > easier to understand since it's more explicit and doesn't require any
>>>> > special values.
>>>> That's OK with me and please update your patch.
> I'm sorry for the delay. I'm very short on free time these days, but
> I'll definitely take care of the patches until the middle of next
> week. Thanks!
> --
> Anton
> 2012/9/13 Anton Beloglazov <anton.belogla...@gmail.com>:
>> Hi Ali and Anton,
>> Is there any problem with accepting the patches?
>> Thanks,
>> Anton
>> On Sat, Sep 1, 2012 at 9:25 AM, Anton Beloglazov
>> <anton.belogla...@gmail.com> wrote:
>>> A side note: I'll be away for the next two weeks. If there are any issues,
>>> I'll only be able to look into them when I come back.
>>> Best regards,
>>> Anton
>>> On Sat, Sep 1, 2012 at 9:24 AM, Anton Beloglazov
>>> <anton.belogla...@gmail.com> wrote:
>>>> Hi Ali and Anton,
>>>> Here are the patches (only decorators.py has been updated: I've added a
>>>> raise_exceptions argument):
>>>> On Fri, Aug 31, 2012 at 7:57 PM, Ali Gholami Rudi <aligr...@gmail.com>
>>>> wrote:
>>>>> Hi Anton,
>>>>> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
>>>>> > Thanks for the explanation! In my opinion, the two parameter approach
>>>>> > is
>>>>> > easier to understand since it's more explicit and doesn't require any
>>>>> > special values.
>>>>> That's OK with me and please update your patch.
On Tue, Sep 18, 2012 at 5:46 AM, <an...@angri.ru> wrote:
> The patch is now in master. Please test and let me know if something
> is not quite right.
> Thanks, Anton and Ali!
> --
> Anton
> 2012/9/13 <an...@angri.ru>:
> > Hi Anton, hi Ali,
> > I'm sorry for the delay. I'm very short on free time these days, but
> > I'll definitely take care of the patches until the middle of next
> > week. Thanks!
> > --
> > Anton
> > 2012/9/13 Anton Beloglazov <anton.belogla...@gmail.com>:
> >> Hi Ali and Anton,
> >> Is there any problem with accepting the patches?
> >> Thanks,
> >> Anton
> >> On Sat, Sep 1, 2012 at 9:25 AM, Anton Beloglazov
> >> <anton.belogla...@gmail.com> wrote:
> >>> A side note: I'll be away for the next two weeks. If there are any
> issues,
> >>> I'll only be able to look into them when I come back.
> >>> Best regards,
> >>> Anton
> >>> On Sat, Sep 1, 2012 at 9:24 AM, Anton Beloglazov
> >>> <anton.belogla...@gmail.com> wrote:
> >>>> Hi Ali and Anton,
> >>>> Here are the patches (only decorators.py has been updated: I've added
> a
> >>>> raise_exceptions argument):
> >>>> On Fri, Aug 31, 2012 at 7:57 PM, Ali Gholami Rudi <aligr...@gmail.com
> >>>> wrote:
> >>>>> Hi Anton,
> >>>>> Anton Beloglazov <anton.belogla...@gmail.com> wrote:
> >>>>> > Thanks for the explanation! In my opinion, the two parameter
> approach
> >>>>> > is
> >>>>> > easier to understand since it's more explicit and doesn't require
> any
> >>>>> > special values.
> >>>>> That's OK with me and please update your patch.