[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: SPAN display: inline/block?
From: "Thomas Schilling" <snuffeler () gmx ! net>
Date: 2001-11-22 17:28:26
[Download RAW message or body]
I noticed that Konqueror started a new block before a longer SPAN-element (i
used a bullet list inside). I'm not sure how a span with a block-element
inside should be rendered correctly but it wasn't the way I thought it would
be rendered. The SPAN element only changed the color.
Furthermore: { border: 1px 1px solid black; } doesn't work.
I've sent the doc as an attachment (the classes are: .unclear and .example)
["index.html" (text/html)]
<html>
<head>
<title>C++ Code Completion</title>
<style type="text/css">
<!--
a, a:active { color:#00675D; }
h1, h2, h3, a:hover { color:#00A99B; }
a:active, a:visited, a:hover { text-decoration:undeline; }
a:visited { color:003E38 }
h3 { font-size:1.2em; }
h2 { font-size:1.44em; }
h1 { font-size:1.728em; }
dt { font-weight:bold; margin-left:0}
dd { margin-left:4em }
.unclear { color:blue; } /* waiting for confirmation/correction */
.todo { color:red; }
.featnum { color:#00A99B; font-weight:bold; }
.example { background:#eeeeee; border:1px 1px solid black; padding:8px 8px; }
.example tt { color:blue; }
-->
</style>
</head>
<body link="#00A99B" vlink="#00463E">
<table border="0" align="center">
<tr><td><!--img src="cctitle.png" width="365" height="50"-->
<h1>C++ Code Completion</h1>
</td></tr>
<tr><td>
<dl>
<dt>Developers
<dd><a href="mailto:victor_roeder@gmx.de">Victor Röder</a>, <a \
href="mailto:daniel.engelschalt@htw-dresden.de">Daniel Engelschalt</a>, <a \
href="mailto:snuffeler@gmx.net">Thomas Schilling</a> <dt>Author (of this document)
<dd><a href="mailto:snuffeler@gmx.net">Thomas Schilling</a>
</dl>
<h2>Feature Overview</h2>
<table width="100%" border="0" cellSpacing="1" bgColor="#cccccc">
<tr bgColor="#dddddd">
<th>No.</th>
<th>Feature</th>
<th>Prio</th></tr>
<tr bgColor="#eeeeee">
<td><b>1</b></td>
<td><b>Member Completion</b></td>
<td>1</td>
</tr>
<tr bgColor="#ffffff">
<td>1.1</td>
<td>Complete variable's member names when "<tt>.</tt>" or \
"<tt>-></tt>" is typed.</td>
<td>1</td>
</tr>
<tr bgColor="#ffffff">
<td>1.2</td>
<td>Complete scope's member names when "<tt>::</tt>" is \
typed.</td> <td>1</td>
</tr>
<tr bgColor="#eeeeee">
<td><b>2</b></td>
<td><b>Argument Hinting</b></td>
<td>1</td>
</tr>
<tr bgColor="#ffffff">
<td>2.1</td>
<td>Hint function arguments.</td>
<td>1</td>
</tr>
<tr bgColor="#ffffff">
<td>2.2</td>
<td>Hint template arguments.</td>
<td>2</td>
</tr>
<tr bgColor="#eeeeee">
<td><b>3</b></td>
<td><b>Context based code completion</b></td>
<td>2</td>
</tr>
<tr bgColor="#ffffff">
<td>3.1</td>
<td>Show variable and function names available in current scope.</td>
<td>2</td>
</tr>
<tr bgColor="#ffffff">
<td>3.2</td>
<td>Show type names available in current scope.</td>
<td>2</td>
</tr>
<tr bgColor="#ffffff">
<td>3.3</td>
<td>Show class names when after "<tt>:</tt>" in class \
declaration.</td> <td>3</td>
</tr>
<tr bgColor="#ffffff">
<td>3.4</td>
<td>Show base class members when editing class body.</td>
<td>2</td>
</tr>
<tr bgColor="#eeeeee">
<td><b>4</b></td>
<td><b>Initialization Block Hinting</b></td>
<td>3</td>
</tr>
<tr bgColor="#ffffff">
<td>4.1</td>
<td>Show array position.</td>
<td>3</td>
</tr>
</table>
<h2>Detailed description</h2>
<h3>1 Member completion</h3>
<p><span class="featnum">1.1</span> <b>Variable member completion</b>
can only occur in code sections, i.e.,
in the body of any function, since "<TT>.</TT>" and \
"<TT>-></TT>"
(the markers for variable member completion) can be used only there. One
module of the parser (the <i>node parser</i>) analyses the part to the left
of the marker and returns it's result type. (It may be the result value
of a function or a typecast or it may be a single variable.) This has
to be either a struct or a class or a pointer or reference to such type,
respectively. The node parser is -- although it may not seem so -- a very
complex module. Therefore it is below described in more detail.</p>
<p>The returned type then has to be looked up in the class store and it's
members (including base class members and through "<TT>using</TT>"
included members) are returned to be filled in the code completion box.</p>
<p><span class="featnum">1.2</span> <b>Scope member completion</b> is a less \
complicated task. It can be
invoked anywhere in the code after "<TT>::</TT>" has been typed.
The left part of the marker will again be parsed by the node parser while
now it must be notified to evaluate for a type and not a variable and
it's type (otherwise it would be an illegal statement). When this is returned
the list again can be created through a quick look-up in the class store.</p>
<p><span class="featnum">1.3</span> <b>The completion box</b> itself has to be \
implemented by the interface
provider but I think it should have some capabilities that ,partly ,have to
be supported by the code completion part. For example it could highlight the
contents of the box (according to the editors code hilighting) and it should
hide inappropriate entries. Special functions (not implemented ones) should \
also be hilighted explicitly.</p>
<h3>2 Argument Hinting</h3>
<p><span class="featnum">2.1</span> <b>Hinting function arguments</b> can be \
performed via a tooltip showing the
function's arguments while the argument the cursor is resting in should be \
highlighted in
an appropriate way. This is part of the interface implementation but the
parser has to do <u>all</u> work before, i.e. it has to determine the \
appropriate
function (according to it's arguments) and it should also find the range of the
active argument to have clear responsibilities (although there may be
an independant parser sub-class for that purpose). Thus the string containing \
the
function declaration and the start and the end of the sub-string that is ment \
to
be hilighted have to be passed to the interface (or retrieved by it). It should
also be possible to return several strings if there are ambiguities. \
Furthermore the user
should be able to switch the shown function declaration (at it's best through
mouse <u>and</u> keyboard due to accessibility aspects). <span class="todo">
[add visual example]</span></p>
<p class="unclear">[? An interface for argument hinting has to be defined. It \
obtains
a list of strings and two values describing a substring of each string that \
should
be rendered more prominently since it is the currently edited argument.]</p>
<p>When you want to change a function's default argument beyond the first \
default
argument it can be useful to auto-complete an argument with it's default value \
when
it is skipped when the code is edited (i.e., nothing or nothing sensible was \
typed
between two commas). But then scopes of constants must be considered (e.g., a \
constant
can be used inside a class without a scope but in a function declaration it has \
to be preceded by one <span class="todo">[add example]</span>).</p>
<p>When implementing a function the whole argument block could be \
auto-completed.
Finding out if it actually is an implementation could be done by checking if \
the token before the function name is (exactly) it's return type.</p>
<p><span class="featnum">2.2</span> <b>Template argument hinting</b> works \
quite the same way except that it reacts on
"<tt><</tt>" and "<tt>></tt>" instead of \
"<tt>(</tt>"
and "<tt>)</tt>" and can have some other argument types. When a \
class-type is
expected a completion box could be shown listing all known classes.</p>
<h3>3 Contaxt Based Code Completion</h3>
<p>In principle a completion box <u>can</u> be useful everywhere in the code. \
For example
in the implementation of a class method it could list up the names of all class \
members
everytime you type some letters, or it could list you the names of possible \
base classes.
But when this happens too often it can be annoying. Thus there are some ideas \
to make this more comfortable:<ul>
<li>The list could appear only when a special combination of keys is pressed \
(e.g, Ctrl-Space).</li>
<li>The list could appear only when more than, say, four letters were \
typed.</li>
<li>The list could appear only when it has at least a given number of \
entries.</li> <li>The list could be turned off in special contexts.</li>
</ul>
Below are some possible contexts and the suggested corresponding list behavior \
are described.</p>
<p><span class="featnum">3.1</span> <b>Variable names in current scope</b> \
could be shown.
More exactly saying, all variable and function names visible in the current \
scope could be
shown. That includes global variables, members of base classes (if not private) \
or from
other namespaces included functions and variables and also all local variables. \
If a global
variable is hidden by a local one then both should be listed. The global one \
then has to be
preceded by the scope operator which will automatically be added when this \
variable was selected to be completed.</p>
<p>As described above this list may contain only entries of a special length \
and may appear only if at least a given number of letters (and numbers) was typed.
<p><span class="featnum">3.2</span> <b>Type names in current scope</b> could be \
listed up.
This, on principle, should be listed in the same list box as 3.1 and thus obeys \
the same rules.</p>
<h2>Implementation</h2>
<h3>1 The Node Parser</h3>
<p>The Node Parser has to evaluate the expression to the left of the marker \
token. It does
not need to completely evaluate the expression. It only has to evaluate the \
resulting expression's type.</p>
<p>This type can be determined by evaluating the expression according to the \
C++-rules.
Therefore the associativity and priority of operators, casts (implicit and \
explicit) and
the rules for choosing the right overloaded function/operator have to be \
considered.
All these rules are described in the C++ Standart and, hence, are not described \
here
in detail. Nevertheless they have to be implemented in the Node Parser.</p>
<p>The Node Parser evaluates only the current statement and this only up to the \
marker.
Any other statement or expression before or after is ignored. So the preceding \
statement
fragment has to be tokenized and evaluated. But only until the needed type is \
found. So,
i.e., since the markers are operators with very high priority only operators \
with higher
priority have to be evaluated first. That doesn't mean operators with lower \
priorities
don't need to be implemented. These can also get higher priorities when they \
are fenced.</p> <p>Here is some suggestion how evaluating could be done:
<ol>
<li>The string to analyse is retrieved: it starts after the last \
"<tt>;</tt>",
"<tt>{</tt>" or "<tt>{</tt>", and ends at the marker \
operator.</li> <li>This string is split into tokens.</li>
<li>Now the previous operator (so next to the marker operator) is checked on \
having a higher
priority than the marker operator. If so it is evaluated before. Doing this \
other operators
standing more to the left maybe must evaluated even before that operator and so \
forth. Fenced
operators always have a higher priority than all operators standing outside the \
fences.</li> </ol>
</p>
<p class="example">Here is an example:<br>
The term to evaluate (after step 1) is: <tt>x = a + b.c-></tt>. So we have 8 \
tokens: <tt>x</tt>, <tt>=</tt>, <tt>a</tt>, <tt>+</tt>,
<tt>b</tt>, <tt>.</tt>, <tt>c</tt> and <tt>-></tt>.
Here are the priorities for these operators: <tt>.</tt> = <tt>-></tt> >
<tt>+</tt> > <tt>=</tt>.<br>
So we have to do nothing here - do we? No! We have to because <tt>-></tt> is
left-associative, i.e. the left part has to be evaluated first. Thus <tt>.</tt> \
has
to be evaluated first. So the result of <tt>b.c</tt> is the type of <tt>c</tt> \
so, say, <tt>C*</tt>. So all members of <tt>C</tt> have to be returned.</p>
<p>When an error occurs during the evaluation process the Node Parser should \
return nothing.
Nevertheless this information could be of use to give some tips to the \
programmer. But this
may be implemented in any future version. (Besides it may be not sensible \
because that is a compiler task.)</p>
<p class="todo">[Add detailed method and sub-module list and description.]</p>
<h3>2 The Class Parser</h3>
<p>To achieve that the Node Parser can obtain the type of each identifer the \
class parser has
to be extended to parse source files. It has to (temporarily) store the type \
information for
each variable in the <span class="unclear">current scope or all scopes in the \
current file. Both
approaches have some difficulty: <ul><li>Parsing the current scope has to be \
done everytime the Code
Completion becomes active. This could mean some more processing time. \
Otherwise, the file is in
memory and only the current scope has to be reparsed. Hence tests should show \
performance.</li>
<li>Parsing the whole file means it has to be done only once. But when the code \
changes the parse
results have to be updated but only if a new declaration was added. So one \
sub-module/aspect of the
parser has to watch over <u>all</u> code changes. This would make the class \
store be updated more
frequently, i.e. everytime a new declaration occured it immediately appears in \
the class view. This
could be a nice feature but since it is not really necessary the choice for one \
of these approaches should be justified through other reasons.</li></ul></span></p>
<h2>Todo</h2>
<ul>
<li>Add method's return type to class store.</li>
<li></li>
</ul>
</td></tr>
</table>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic