Hi,
I believe )MORE should somehow be aligned with the display of other errors.
The theory seems to be that when an error occurs then a rather rigidly
formatted,
3-line error output is produced:
VALUE ERROR
a+5
^
Line 1 is the name of the error, line 2 the offending input and line 3
showing
one or two carets marking the token in line 2 that have caused the error.
Unfortunately line 1 is not very verbose about further details.
In this situation, )MORE may show more details about the error.
In theory, line 1 should show a + at the end when )MORE has more
information.
like in:
VALUE ERROR+
I haven't done that yet, because I was not using )MORE in the beginning.
I'll add that.
/// Jürgen
On 02/21/2014 03:47 AM, Elias Mårtenson wrote:
Jürgen,
I will put a check for )MORE availability in the end_input function
and display a notification in Emacs when it contains something. Would
this be the right approach?
Regards,
Elias
On 20 February 2014 23:44, Juergen Sauermann
<[email protected] <mailto:[email protected]>>
wrote:
Hi,
the normal 3-line error printout is documented by IBM and shall
remain as is for compatibility.
I will, however, put more information about errors in )MORE such
as file names, strerror() stings and the like.
Pleas feel free to indicate where the information related to
errors is not sufficient.
/// Jürgen
On 02/20/2014 12:16 PM, Elias Mårtenson wrote:
On 20 Feb 2014 18:57, "Kacper Gutowski" <[email protected]
<mailto:[email protected]>> wrote:
>
> On 2014-02-16 18:09:06, Juergen Sauermann wrote:
> > Ad 1) I changed the assertions Symbol.cc to short warnings
visible in )MORE.
>
> I wouldn't guess to check )MORE upon getting VALUE ERROR on shared
> variable, but I guess it's better than failed assertion.
Hmm, this makes me think about a new feature for the Emacs mode:
some kind of warning in the modeline when there is an unread
)MORE message.
Would this be useful? Do you get these kinds of messages often? I
rarely look for it.
> It appears to work correctly for cooperating users now.
Malicious user,
> however, can still easily destroy other users' coupling of
shared variables.
> I'm not going to push for changing it right now because I don't
see any way
> to exploit it beyond denial of service and I'm not using shared
variables
> for anything serious, but I think that it should be done
eventually.
I suppose some proper authentication and authorisation mechanism
is needed too. Then comes the question of encryption. Things like
Kerberos is easy to add and is powerful. However, it does require
infrastructure a lot of people don't have.
Regards,
Elias
